Q. How Do I Use My Vault?If you haven't already, enter a strong master password you will not forget, and TAB or click to the next (username) field. There is NO WAY to recover this password. If you forget it you absolutely will not be able to recover the contents of your vault.
As you type in your master password, the start of a hashed version of it is displayed to the right of the field - this is useful to help you know when you've entered it correctly as you'll recognise the characters when you've done it a few times.
When the password has been entered and the vault decrypted the top left padlock will show that it's open, and the number of items inside.
Once you have entered the correct master password you can view existing items by starting to type in the 'identifier' field. Matching items will display beneath. Click on one to load it up, or click on the X on the right to delete it from your vault.
For every item in the vault, a strong auto-generated password is created using the MIT licenced 'SaltThePass' algorithm. You can simply ignore this and use the vault to store your own in the comment or note fields. Or select zero as the length and put the password in the suffix field if you want to be able to use the COPY button to copy the password to your clipboard.
To add a new item, type in your choice of identifier. For example for a Google account password, you might type in 'google' as the identifier. Next enter the username of the account in the username field. As soon as you click or tab out of the username field, if this is a new item it will be created in your vault. Pick a length for the password. If you want to add special characters onto the password, do so in the suffix field. To see the generated password, click on the 'eye' button. As you type in the identifer, username salt and suffix fields, the password will change. For the same values though, it will always be the same. If you decide to change the password you can do so by simply entering something new in the 'salt' field - your generated password will change completely, even with a small change to the salt.
If you type in an identifier and a username which are identical to an existing one in your vault, and proceed to change any other details, and then save your vault, THIS WILL OVERWRITE THAT ITEM IN YOUR VAULT WITH THE NEW DETAILS.
If you see the upload to cloud button turn red then there are unsaved changes. Click on it to commit those changes to the vault on the aeKee server.
For your peace of mind we recommend periodically cloning your vault to another slot as a data backup. Our server uses RAID 10 SSD storage, and all data is backed up daily, offsite (to an AWS S3 vault) - but still, belt and braces hey! It also protects you against accidental item deletion.Q. What is all this for?aeKee is an ultra-secure vault in which you can store plain-text notes, and that generates strong passwords for all of your accounts. It also allows you to safely share secure information with a third party, whether or not they have an aeKee account.
aeKee utilises the same OpenSource javascript libraries LastPass (and many others) do, which implement the same encryption algorithms governments want banned from public use, because they can't break them.Q. How secure is it?We've created aeKee from the ground up such that should our server be compromised (all files accessed) or all traffic between your browser and our server be recorded, your information will still be completely secure.
All traffic beween our server and your browser is end-to-end encrypted - you can check the details of this by clicking on the padlock in your browser. Unlike many, we do not use a third party middle-man service such as CloudFlare which (little known) actually breaks end-to-end encryption.
All aeKee application files on our server are constantly monitored for changes. In the event of an unexpected change we will immediately lock down the site until the cause has been identified.
The aeKee web app uses a very tight Content-Security-Policy to ensure, if you use a good modern browser, there is no chance of anyone employing any form of XSS (or similar) attack.
We do not know your email address. We only store a one-way-hashed version of it for comparison when you log in. The same goes for your aeKee account password. All access logs where recorded in a way which can be associated with your vault data are recorded encrypted in a way we cannot decrypt them without your email address and aeKee account password, which we do not know.
We never receive, hashed, encrypted or otherwise, your vault master passwords.
All of Your data is stored encrypted or one-way-hashed. Specific details on everything we store, and we secure them in different ways now follows:
Your login credentials When you register and log in, your email address and account password are transmit (posted) to us over an SSL connection, the data portion of which is not logged, then salted and one-way hashed using the latest PHP7.1 password hashing algorithm and stored on our server in a caged file system using CloudLinux and CageFS. Even if someone gained access to the data we store, they would not be able to do anything with it - it has been one way hashed. Here's an example data block for an account's credentials: ipbHk0P39W3D1iP2J1r6vdvFxY9olQN8is4eLlidb09PGtWx1ZLNvc1ed87756b1f75dcb91d549c531d52c216831da24b2e3e079244e9d374f04e2f20e4aac1790f8727934328231ba00bze919osbMqYOsgrGvd6XoqOO8P3D0KTC2gFYjhUOzD8nlyrMCGbPGty We do not store your email address or password in a reversible way.
Your email address and password are used to encrypt your 2fa secret (there's an encrypted secret in the block of characters above) - this is done reversibly such that when you log in we can decrypt your 2fa secret in order to determine if the 2fa digits you enter correspond correctly with the ones Google Authenticator says they should.
Your vault(s)
Your vault data is stored on our server encrypted. All encryption and decryption of your vault is done by JavaScript in your browser. Our server never sees your master vault password(s) encrypted, hashed or otherwise, at all. The encryption process starts with generating two keys from your master vault password, KeyE and KeyM, using PBKDF2 and a variable number of iterations around 9000 (which takes a large amout of computing power, confounding possible brute force attack attempts). A strong random initialisation vector, called an IV, is generated. The data is then padded using PKCS#7 to match the AES block size and encrypted using SHA256 in CBC mode using the IV and key KeyE. The result of this operation is then concatenated with the IV and hashed using the HMAC algorithm also using SHA256 but this time with KeyM. The concatenation of HMAC + EncryptedData + IV form your vault. The encryption process provides you with guaranteed confidentiality. The HMAC process provides you with guaranteed data integrity.
Here's an example of a vault's data, with very little in it: Whd7rF6hzwgOQDz1TgcJtAr8LTyZSh1p0sXpxQDBnPoLTAp0uwBDHVciCKrqfAU9U6/tQTAQed0BLoLz4NEGLZtX97yBAN1xAaX6GnM3Q+QF2O9M1Jz90gTyQj4JNsAt1Rs7h0/1r61GtargElsPVID+kwnzoj4N3TJAAV+9omImoSWMFsfxSw2vR7dNTkXA=abeca7302a422620f744a452e8b769d43dd5f1f8d315dff38d3cbbc77e3826015
Access Logs A record of your logins and failed logins is kept however this data is encrypted on the server side using a salt and your account login credentials. We cannot decrypt these logs. Here's an example record of a login event. It includes the remote IP address, the time, and browser details: 772e32a46e4504dcb13508e43b118900c7b3e7c4bef79419379f2cf34ffaf8a47d84fc05142bfe7923e3385268a0ac7f55c8ebbdf7b30633c655e28144abf87ef81f20ec2ef1adf0026c28c350d2bc248de8bc7ecb373e5ae7ccd737ecaa05e9f60c4ea80ea9b0e79ae525ab0e837efa84e67b71f17caedefe90f6b5e6186e98ade81d37f45975bc9398cd4f0a15e7e7472588133e5d3443e694b91cc93e272d0266c6479809a0d492b2b1e9f3edc216. Only you can decrypt this and see the details.
Shared Notes Notes are encrypted (in the same way vaults are) in the browser then uploaded and stored on our server when ‘sent’. The specified recipient receives an email with a link, and a plain-text comment from the sender. If the recipient knows the correct password, they are able to decrypt and view the message. The moment the recipient clicks on the link, the server copy of the message is destroyed so it can never be seen again.
Because messages can only be retrieved once, your recipient can be certain nobody else has seen the message, encrypted or otherwise.
Because we do not know your email address, we cannot notify you when a message has been viewed.
Here’s an example – this example is unique in that, for the purposes of this demonstration, the server does not destroy its local copy.
Server Files Our server is as secure as we can possibly make it. We work very very hard to achieve this and it would be foolhardy to go into public technical detail. Rest assured we've taken every normal measure, and a lot of additional ones too. Regardless, even the best servers get compromised from time to time so we've built this entire application with the insistance that should all data on our server be made public, there is no risk to our users' confidentiality or integrity. Additionally, all of the application files on the server are scanned routinely (we use SHA3-512 hashes) and compared to the known release versions - any differences detected are immediately highlighted to us so that we can take instant remedial action.
Q. How Does Sharing Work?Secure notes can be shared with any recipient - recipients do not need an aeKee account.
Your note is encrypted in your browser and is decrypted in the recipient's. Between the two it remains encrypted at all times and there is no current known way to reverse that encryption without knowing the encryption key. We use PBKDF2 to convert your password into a strong, brute-force proof, key.
When notes are retrieved, the server copy is destroyed. Because messages can only be retrieved once, your recipient can be certain nobody else has seen the message, encrypted or otherwise.
The recipient may keep the note displayed in their browser for as long as they wish but attempts to re-access the note will fail.
Recipients are emailed a unique link for each note. Share your chosen passphrase with them by some means other than email - they will need it to decrypt the note.
We never record or store recipients' email addressess, we never record or store yours. All server data other than vaults and notes are stored one-way hashed. Vaults and notes are stored using 'encrypt and MAC' for absolute integrity and total confidentiality.Q. Why Do I Need More Than One Vault?You can use one vault for your passwords - or one for your clients' passwords one for you own, or one for keeping a record of your thoughts - or anything at all. We do recommend using at least one vault slot as a backup for your most important vault. Remember you can use vault alpha to generate passwords for your other vaults if you wish. Perhaps put 'vaultD' as the identifier and 'me' as the username, to generate the password for vault delta - for example.Q. What If Your Sever Is Down?If you can remember your master password, identifier, username, salt, suffix and password length, you can use the SaltThePass website or mobile app as a backup. Simply enter them in that order in any of the fields on SaltThePass and your password will be re-created. For example if your master password is 'test', identifier is 'ident', username is 'user' salt is 'salt' suffix is blank, and length is 10, enter 'test' as the master password and then in the domain field enter: 'identusersalt' (the username and salt, concatenated) - and modify the length to show 10 characters - that is your password.
SaltThePass was developed by Nic Jansma and the source code is available for use under the MIT licence.Q. Can I Use aeKee Offline?We've now launched a trimmed down encrypt/decrypt system using almost the same exact algorithm aeKee uses - which can be used offline.
If you've exported an aeKee vault, encrypted, and you recall the passphrase you used for the exported data, and the data has a 30 character line of characters, followed by a carriage return, then more data, and you paste the lot into the text field in 'aeKee offline' and enter the correct passphrase - you can decrypt your vault data. The result will be a rather odd looking JSON file but with a little effort (and optional help from us, if available) you can recover all of your data and passwords this way.
Another great use of this offline system is for creating encrypted notes, entirely offline - to keep offline. Say you have a private key that absolutely MUST NOT get into someone else's hands - you can boot up a PC from (say) an Ubuntu installation disk, put aeKee's offline system on a USB stick and open aekee.html in the browser in Ubuntu - create an encrypted note with the private key in it, and save it to the USB stick. You now have secure information stored indefinitely - created yet accessible with zero risk of compromise (provided nobody was looking over your shoulder at the time).
All files in this system are open source and you can view them and contribute to their development on GitHub:
https://github.com/aekee/aeKee Q. Why & How Do I Export?Exporting a vault to one with the same master password effectively creates a duplicate backup. This protects you from accidentally deleting something you wished you hadn't in your primary vault - and creates a snapshot of a vault at a certain point, if that's useful to you.
Exporting a vault to one with a different master password instantaneously changes all of the auto-generated passwords within it - all other information will remain unchanged. This is a great way to force yourself to change password on all of your online accounts.
You can only export a vault to another if there is a spare slot available. And you cannot export a vault over the top of an existing one.
You can use the export system to export and download a copy of your vault, encrypted or plain-text.Q. How Do I Download/Export a Vault?In the export system, select either DOWNLOAD encrypted or DOWNLOAD plain-text as your destination, then click EXPORT.
If you export in plain-text, be extremely vigilent with the saved data!
OK: SOURCE HASH VERIFIED This page code modified: 2017-05-24T08:44:54+00:00
Modifications valid to: 2024-01-18T09:43:32+00:00