Passwords are Deterministic and Therefore NOT SECURE

[sarciszewski]

From the Readme:

A simple tool that allows users to have strong unique passwords for each website, without the need to store them either locally or with an online service.

Because a deterministic SHA-512-based approach is utilized by Passera, two users who use the same password, when using Passera, will also generate the same exact password.

PoC:

1. Enter githubPasswd123
2. Enable special characters
3. Get the same output as on the readme (dpu7{Lrby(vQLd8m).

While it is debatable that the outputs are secure against a naive attacker, with the knowledge that two users with the same input will receive the same output, they are certainly not unique.

When an attacker who is aware of the existence of this tool enters this threat model, the security of the entire app comes into question.

Recommendations:

• Implement a nonce/salt for each user; e.g. an SHA-256 hash of their email address (or other appropriate identity selector) -- this won't stop targeted brute forcing, but it will prevent mapping plaintext inputs to deterministic outputs. This also does not require local or remote storage to work properly.

Further reading: http://www.cryptofails.com/

[rpdillon]

All hashes are deterministic -- that's what makes them hashes. Using cryptographic hashing to generate passwords is a well known technique (see http://passwordmaker.org/ and https://www.pwdhash.com/). The use of a 'identity selector' doesn't change anything - it will simply be folded into the input. Such a case is not a nonce, since nonces are, by definition, one time use tokens, and typically used to prevent replay attacks. It could be viewed as a salt, but salting passwords is primarily to prevent rainbow table attacks, and hinges on the randomness of the salt value, which in this case is not random, since you're suggesting basing it on the user's identity.

The security of Passera is proportional to the strength of the input password - the changes you suggest don't change that.

[sarciszewski]

Such a case is not a nonce, since nonces are, by definition, one time use tokens,

Okay, there's no need to be pedantic here.

The use of a 'identity selector' doesn't change anything - it will simply be folded into the input.

No, it changes everything.

Typical use case for an average user who uses this app:

1. Type in a weak password (i.e. one of the Top 10000)
2. Get a "stronger" password from Passera
3. False sense of security achieved

All an attacker needs to do is:

1. Use this browser extension
2. Build a dictionary of the Top 10000 passwords
3. Add this wordlist to their directory of wordlists

Let's assume the identity selector is a random 256 bit value stored by the browser extension in a file, rather than a hash of their email address. This completely defeats the attack I outlined above. Attackers would need access to their filesystem, and if they can achieve that, they might as well just install a keylogger.

If you wanted a medium ground, then you could use a BLAKE2b hash of their email address/username/other identity selector to serve as a deterministic salt. Then attackers would need to recompute each email:password pair -- this is peanuts for targeted attacks, but defeats the "just precompute an additional wordlist" step outlined above for attacking all of the things. It's still an improvement.

The use of a 'identity selector' doesn't change anything

I disagree.

[mwgg]

If Passera used email addresses as salt, or any common things like login/URL combinations, that wouldn't help much since an attacker would likely know those things when targeting a specific individual. Passera leaves it completely up to the user to create their passphrase as secure as they wish by combining any number of such selectors, instead of a predefined algorithm of how such salts would be added to the hash.

[sarciszewski]

On your README file you state:

Passwords, produced by Passera are impossible to brute-force, since it would take an extremely long time (as opposed to using combinations of real words and sentences as passwords)

Yet, this is not necessarily true. If the output of Passera is completely deterministic, this property is true IF AND ONLY IF the original password was secure to begin with, thus making the utility gained from this tool approximately zero.

[rpdillon]

Consider the case of the a single user with a corpus of passwords, each associated with a single service accessed over the internet. Considering the entire set of passwords as a whole, a desirable trait of the set is that no password should appear in the set more than once. The reason for this should be apparent, but has become acute in the past few years due to rampant breaches of password databases, and a lack of transparency by services about how passwords are handled in transit and at rest.

The value of password hashing in this context stems from a desire to have a the set of passwords belonging to a single user have this property. Indeed, it is a good fit for a cryptographic hashing algorithm, such as that used by Passera (SHA-256). Cryptographic hashes have a few properties, but the two that are most interesting for this use case are that good cryptographic hash functions (1) have good avalanche behavior and (2) there is no statistical relationship between the content of the input and the hash value. I often think of (2) as being the property that, given sequential input, the output of the hash function is distributed evenly and unpredictably across the hash space, i.e. it appears random.

The value of password hashing tools (Passera, PasswordMaker, pwdhash) should be made clear in the README. Here it is: given a single, strong, master password, password hashing tools provide a collection of strong, unique passwords (one for each service a user needs to access), that, given a breach of one or several of the services password databases, will not reveal to attackers the original, strong, master password. Passera provides this functionality without requiring that those passwords be stored or synced across the user's devices.

Password hashing tools do not magically make weak passwords strong. This should be made clear in the README. My problem with this ticket is that it attempts to make Passera good at something that Passera will never be good at: given a weak master password, no scheme will make Passera return strong passwords; we can merely make them less weak. Instead of seeking a technical solution to this problem, I think it is more appropriate to simply tell users that a strong password is a prerequisite for correct use of Passera (as with all other password hashing tools).

[mwgg]

I completely agree that resulting passwords are only as secure as the initial passphrase and users should be aware of this. I've added a paragraph to the README making an extra point on this issue.

[sarciszewski]

I completely agree that resulting passwords are only as secure as the initial passphrase and users should be aware of this.

Then any statements that even smell like this one ought to be nixed completely from the readme:

Passwords, produced by Passera are impossible to brute-force, since it would take an extremely long time (as opposed to using combinations of real words and sentences as passwords)

You can't reliably guarantee that if the input password is 123456 and an attacker is wise to the existence of Passera. To wit, I'm going to generate a bunch of wordlists for crackstation.net tonight for the Top 10k passwords run through Passera. With and without special characters. For every acceptable output length from 4..64.