4

NOTE: This question is a subpart of the original question on aWallet Password Manager posted on Cryptography.StackExchange. As suggested by @SEJPM, I'm posting it here since the topic of the question is better suited for InformationSecurity.StackExchange.


After reading a lot of articles on ramping up the security of my web accounts, I started using aWallet Password Manager for Android to backup my passwords. I like it for following reasons:

  • I'm able to have fairly good-entropy passwords: I'm able to throw in a mixup of lowercase & UPPERCASE alphabets, digits, special characters (including spaces) and have reasonably long passwords (10+ characters)
  • Saving my passwords securely allows me to have distinct passwords for each web account which would otherwise be impossible. This would avert a cascading effect (giving away credentials of all accounts) that would be created if one of my accounts, whose login credentials I share with several accounts, gets compromised.

Needless to say, that 2nd point is debatable because having all credentials stored at a single place introduces a single-point of failure and poses an equal risk of the chain-reaction mentioned earlier.


Given my limited knowledge of cryptography and doubts around privacy (given recent incidents of online thefts), I want to testify the security of aWallet Password Manager before storing my Banking / Card details in it. Here's what they claim on their Google PlayStore page:

SECURITY FEATURES

• All data is encrypted, including Entry names, Category definitions and the data itself.

• Encrypts data using AES and Blowfish algorithms with key sizes of 256, 192 and 128 bits.

• When the data file is decrypted, up to all combinations of algorithm, key size and cipher mode of operation (CBC, CFB, OFB and ECB) are tried with the Master password to unlock the data file. This makes brute force attacks longer. The app itself does not store any hint to the actual cipher, key size or cipher mode of operation.

• Uses a randomly generated 'salt' combined with the Master password. Salt helps to protect from off-line dictionary attacks.

• The key to open the data file is created by combining your master password with the 512-bit 'salt'. The result is hashed 1000 times by SHA-256. Repetitive hashing makes a brute force attack more difficult.

While none of these points make a lot of sense to me, the little bit that I know about Cryptography tells me that [please correct me if I'm wrong] repeating an encryption technique multiple times doesn't Mathematically improve the security; it may only give one a false impression of added security.


And because of this inconsistency, I started doubting the validity of their other claims. My questions are:-

  1. Is there a tool / technique that I could use to attempt to decrypt the data.crypt file used by aWallet app so as to test it's security?
  2. aWallet doesn't offer any cloud storage of their own and allows us to (optionally) backup the data.crypt file onto Google Drive or Dropbox. How safe would that be given that I use 2-Factor-Authentication for my Google account?
  3. In general, is it safe to store login credentials or banking details or both in a password manager?
  • 2
    Is the repetitive hashing that made you suspicious? That is not the same as repetitive encryption, and it is indeed standard practice. See this. – Anders Apr 9 '18 at 8:04
  • Is it safe to store login credentials or banking details or both in a password manager It doesn't have to be perfect security, it has to be better than creating your own password and remembering it. – Kevin Voorn Apr 9 '18 at 12:54
  • 2
    "all combinations of algorithm, key size and cipher mode of operation (CBC, CFB, OFB and ECB) are tried" This sounds idiotic...why not use a proper key derivation function? The fact that they apparently allow you to use ECB is a huge red flag (and if they don't allow you to use ECB then trying to decrypt with it doesn't do anything to slow down the attacker anyway) – AndrolGenhald Apr 9 '18 at 13:17
  • 3
    I'd like to point anybody who wants to comment on the cryptographic details of this "password manager" to the linked post on Crypto.SE, where these issues are evaulated and discussed. – SEJPM Apr 9 '18 at 15:56
2

Please note: This post actually answers the question(s) in the question and doesn't comment (much) on the security of aWallet. I suggest you visit the Crypto.SE version of this question for a review of the cryptographic details.

Is there a tool / technique that I could use to attempt to decrypt the data.crypt file used by aWallet app so as to test it's security?

A quick search turned up nothing, so I suppose that this password manager isn't big enough / hasn't seen enough research to have made somebody else to write a tool to attack this password manager.

aWallet doesn't offer any cloud storage of their own and allows us to (optionally) backup the data.crypt file onto Google Drive or Dropbox. How safe would that be given that I use 2-Factor-Authentication for my Google account?

This very much depends.
Assuming aWallet's security measures are actually good and you use a strong password and / or a local key file, then uploading the encrypted password database to a cloud service doesn't hurt security, as your password and / or keyfile still protect the passwords. Of course the added authentication and access control of these cloud services means that chances are only you and the provider have access and it's usually in the provider's best interest to not leak user files.

In general, is it safe to store login credentials or banking details or both in a password manager?

Yes, very much so, if the password manager is decent.
Using a password manager allows you to easily have unique, strong passwords per website, meaning a compromise of your password database or your local client is required. As we have already established, a compromise of the backup is prevented by the strong password, so this leaves the client compromise as the vector to learn the password. But as soon as your client is compromised, all bets are off anyways, because the attacker could just sniff your keyboard or monitor / intercept your network data! So all in all you little to lose and much to gain by using (good) passowrd managers.

Whether aWallet is a good password manager is a different question though (and answered on Crypto.SE).

2

aWallet specifically: don't use it. The creator obviously doesn't know what they are doing. I'll just pick out one concern (there are several that will probably be more obvious to People Smarter Than Me): it could encrypt your database in ECB mode (sometimes, but not always).

ECB mode is notably not secure because the same plaintext always encrypts to the same cypher text. Therefore, ECB mode "does not hide data patterns well...it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all".

Password managers in general: use one. But pick a well-known one with good reputation like 1Password, LastPass, KeePass, Dashlane, etc. Or at least use one created or recommended by a well-known security company or security researcher if you don't know where else to look. A good password manager with competent encryption (not aWallet apparently) is perfectly safe to keep on cloud storage, provided your master password is strong.


Edit: OK I can't resist picking a few other points that jump out at me to scream "stay away":

  • Regarding transforming the master password to an encryption key: "The result is hashed 1000 times by SHA-256." This is laughably insufficient. Done properly they would at a minimum use PBKDF with 10,000 rounds or more rather than a custom-made hash loop of only 1000. Even that would be barely sufficient, and would compare poorly to properly implemented password managers. Hundreds of thousands or more rounds would be more like it. Or abandon SHA-based password hashing and use something like bcrypt or argon2. This software cannot compare to modern tools.
  • "Supports auto destruction of the data file after a predefined number of unsuccessful unlocks have been tried." This doesn't affect an attacker at all. The only person this can hurt is the legitimate user. An attacker will make a copy of the database or use modified software to remove the guess limit. You on the other hand can accidentally lose all your passwords, never to be seen again, by accidentally having capslock turned on, or a dead key, or something like that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.