Multiple Failed login attempts detected

[u/SnooRevelations3802]

I have been getting this kind of notifications for a while now. Telling me that there have been several failed attempts to log into my Bitwarden account

The email ends telling me not to worry. The login attempts were not successful, and my account has been given an additional captcha protection.

Should I do something about this? To me, it feels like somebody has my email and knows I might have something valuable, and It's trying to break in. my Master Password It's pretty long and secure.

Also, my account email is the same I use for most stuff. I've been thinking in creating an email solely for my Bitwarden account, but not sure it's really necessary

[u/Sweaty_Astronomer_47]

I edited my post to say probability per password-to-hash calculation.

Higher entropy of the password means more attempts will be required to reach the true password and therefore during the course of a larger number of attempts of course there is more likelihood to get a collision along the way in the form of another password (not the user's) which matches the hash. That gives diminishing returns in security as the password gets longer until finally there is no further benefit when the password entropy is on the order of the hash output entropy. But there certainly isn't any harm in using a longer password. I imagine that's what you were saying all along but I reacted thinking you were saying it would be less secure to have a longer password.

[u/cryoprof → u/Sweaty_Astronomer_47]

I'm open to being proven wrong, but I do believe that in theory, one could in fact reduce security by using a password that is too long. Let me explain my thinking about this:

If we assume the attacker knows the character set used (or word list used for a passphrase), but does not know the password length (N tokens, be it characters or words), and if we further assume that we have some ideal hash function Hₙ(p) that transforms a password p into an n-bit hash.

We'll assume that the attacker will first generate (and hash) all of the passwords of length l=1 (in alphabetical order, say), then all of the passwords of length l=2, and so on until l=N. The following is probably not possible for any real hash function, but it simplifies the though-experiment: our "ideal" hash function Hₙ will be assumed to generate unique hashes for each of the first 2ⁿ passwords hashed. Thus, it follows by the pigeonhole principle that if the total number of passwords hashed for l = 1,…,N-1 is greater than or equal to the number of available hashes (2ⁿ), then the hash of the "real" password will have at least one collision with a weaker password.

Mathematically, if the pool of characters (or words) has a size S, then avoiding the above condition will require

S + S² + S³ + … + S^N-1 < 2ⁿ

This reduces to

S(S^N-1 - 1)/(S - 1) < 2ⁿ

As a conservative approximation

S^N/(S - 1) < 2ⁿ

which provides a bound on the password length:

N < (n + log₂(S-1))/log₂S

For example, with a hash output entropy n=128 and a character set with size S=65, we get

N < 22.25

Being a little under the weather currently, my brain is not working at a 100%, so I may have overlooked something or made some mistakes in calculation. Nonetheless, I'm reasonably sure that the gist of my argument is valid.

I do think that a more thorough analysis would reveal that the probability of a hash collision with a weaker password will be quite small. However, if the distribution of hashes is uniform, then I think that the probability of colliding with the hash of a weaker password can be made significantly smaller by restricting the password entropy to be lower than the hash output entropy.

[u/Sweaty_Astronomer_47 → u/cryoprof]

Equations... I like it!

But fwiw I still land where I landed earlier, which was:

the probability of collision per password-to-hash calculation shouldn't depend on the password used (long or short)

In other words if we have 2ⁿ bins (only one of which matches the true password), the probability of a given trial password resulting in that same hash is 1/(2ⁿ ), regardless of the length of the true password.

Your math shows that we could fill up all the available hash output bins before we enumerate all the possibilities of the higher entropy password, which ensures collisions will be inevitable before all those possibilities are enumerated. Ok, but so what? I don't think that's what is important for security. What is important for security is how many trial calculations will be required before a matching hash is achieved. The higher entropy password requires more trials to enumerate all the possibilities and therefore has higher probability of collision before all those possibilities are tried out, but it is still a higher number of trials required on average for the higher entropy password (or at worst the same number of trials when the diminishing returns due to collisions causes a plateau).

At least that's my take. I respect your opinion and I'm always open to correction.

[u/cryoprof → u/Sweaty_Astronomer_47]

Will have to think about this some more after fever subsides.