Single randomly generated passphrase for both identity and authentication

Question

There are questions about using a password only to identify and authenticate a user, rather than an email address or username plus password:

• Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?
• Why have username AND password?
• Difference between authentication and identification [Crypto and Security perspective]
• Should usernames be kept secret?
• Revisting the Username Hash

All of those, however, involved public usernames and/or user-set passwords with the potential to reset them. What about random passwords/passphrases that cannot be reset? DuckDuckGo’s Cloud Save made me wonder about this, since it uses the same random passphrases for both identity and authentication, with no email address or username involved.

Let’s say that we are building a service that stores data about its users.

• If the service randomly generates a passphrase/password (e.g., five random words from a dictionary of 2000 words) for each new user,
• and every user’s identity is private,
• and we don’t have to support resetting forgotten passwords (e.g., because we use user passphrases to encrypt all of the user’s stored data with SHA-512 with PBKDF2 or whatever),
• then what risks are there from using only that random passphrase, rather than also requiring an email address or username to identify the user?
• (If the new passphrase collides with another user’s during new-user creation, then the service would silently generate another random passphrase and use that instead.)

There is a clear benefit to this: the user would only ever have to type in that passphrase on login, rather than both an email/username and passphrase.

As far as risks go, if an attacker knew that a specific person was a user of our service, the attacker would have to attempt to brute-force the user’s passphrase…which is supposed to be difficult to do in the first place anyway.

However, I can see a risk that the attacker might incidentally happen upon another user’s passphrase while they’re trying to brute-force the first user’s passphrase, gaining access to the other user. But isn’t this a similarly tiny chance anyway? I can see how it would depend on how many users there are registered in the service—if there are a quintillion user accounts, then it’s going to be easier incidentally getting someone’s account by brute-forcing. I don’t know how to calculate this, though.

But that still doesn’t affect the difficulty in breaking encrypted user data if the attacker gains access to the data; its strength would depend on the passphrase and encryption only whether or not an email/username is used for identity.

• Are there any other risks to using random passphrases for both identity and authentication / data encryption, without emails/usernames?

• How could one calculate the probability that an attacker will find any user’s passphrase after T tries, given N existing user passphrases and D total theoretical possible passphrases?

Answer 1

The risks would include the one you mentioned:

the attacker might incidentally happen upon another user’s passphrase while they’re trying to brute-force the first user’s passphrase, gaining access to the other user

For each user that is added to your service, the attacker gets a "free" guess during their attack. In your scenario of an attacker only going for a single user then this doesn't matter - but in the case where an attacker just needs access to one account, every password guess they try is automatically tested against each user account. This works in both an online and offline scenario (the latter might be possible if an attacker gets access to any password hashes that are stored - it's not clear if you're using these or not).

Another drawbacks is that automatic lockout or request throttling of repeated guesses against a particular user is not possible. This is the primary mitigation against password guessing attacks.

if there are a quintillion user accounts, then it’s going to be easier incidentally getting someone’s account by brute-forcing. I don’t know how to calculate this, though.

Quintillion = 1,000,000,000,000,000,000
(World population 7,400,000,000)

Number of permutations = 2000^5 = 32,000,000,000,000,000

Chances that a guessed password (if the wordlist and method is known) 
matches an existing one of the quintillion accounts = 3.2%

Chances if everyone in the world has one account = 
2000^5 / 7,400,000,000 = ~1 in 4.3 million

In order to make these calculations meaningful you would need to know the approximate size of your user base. I doubt it will be as high as in the examples above, but with a quintillion an attacker only needs 32 guesses on average.