aWallet Password Manager

Question

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 repeating a Cipher 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.

---

Could you elaborate their claims / point me to some source where I can get an overview of the concepts to eradicate my suspicion; so as to prove or disprove the level of security offered by aWallet Password Manager?

---

EDIT-1: As per suggestions by @SEJPM, I've edited the question to remove it's off-topic sub-parts. The remaining part of the original question can be found here.

Answer 1

Elaborate their claims / point me to some source where I can get an overview of the concepts to eradicate my suspicion

This answer will focus on this part of the question: elaborating on the listed claims.

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

As long as that doesn't impede functionality such as retrieving information from the database then it should be fine.

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

I am hoping/presuming this means it provides the option of these key sizes, and not that it uses AES-256, AES-192, and AES-128 to encrypt each block of data. That would be a very bad sign if it did, not for cryptographic vulnerability reasons, but more so because it would imply the author doesn't understand what they're doing.

There is no benefit from using Blowfish. Even the author of Blowfish thinks that people should stop using Blowfish.

There might be complications due to Blowfish having a small block size, but without knowing exactly what is being done such as what order the ciphers are applied in, it's hard to know.

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.

This is simply a waste of the users time and the devices battery, assuming that the cipher, key size, and mode of operation are secure. This is not a good sign, and is trying to provide security by obscurity.

If there are only 4 modes of operation - none of which provide authentication - and they are selected at random, then guessing the mode of operation provides a maximum of 2 bits of security.

If there are only two cipher choices - AES and Blowfish - and it is randomly selected for each cryptogram, then it provides an additional 1 bit of security.

If there are only 3 key sizes - 128, 192, and 256 bits - and it is randomly selected for each cryptogram, then it provides an additional 1.5 bits of security.

Assuming these are all invoked with random choices for each cryptogram, then it provides a maximum of 4.5 bits of extra security.

The correct way to slow down brute force would be to use a significant number of iterations with the key derivation function that is applied to the password.

Note that using ECB mode at all is a big red flag.

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

This is good. However, using a 512-bit salt is twice as large as it needs to be.

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.

1000 iterations of SHA-256 is not sufficient, and provides only a meager improvement in security. The design of SHA-256 does nothing to prevent an attacker from using GPUs/FPGAs/ASICs to compute obscene numbers of password guesses per second (on the order of billions).

Ideally, an actual key derivation function such as PBKDF2, scrypt, or Argon2 would be used with a much larger iteration count (100,000-1,000,000) and set to consume as much memory as is possible/tolerable in order to drive up the cost of custom hardware and reduce an attackers advantage as much as possible.

Maybe users don't want to burn up battery with 100,000 iterations - However, in that case the iteration count should be configurable with a reasonably secure default. 1,000 iterations of SHA-256 is not a reasonably secure default.

Lack of Authentication

The descriptions do not mention anything about authenticated encryption. The lack of authentication implies that an adversary can modify ciphertexts and the user will have no way of detecting the modification.

Not providing authenticated encryption is a huge red flag.

Conclusion

All these points considered imply that the author of the software in question does not fully understand what they are doing. You should strongly consider finding an app that is more heavily vetted and was written by more knowledgeable people. Some of the flaws are quite serious that could lead to compromise of users data in the real world.