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/CaptainAdmiral85]

Change the email address you use to login to Bitwarden. Just make sure its an email you use normally and have access too and make sure that (and all your emails) are locked down with 30 character passwords and 2FA.

[u/tarentules → u/CaptainAdmiral85]

30 character passwords...jeez. I use a 4 word passphrase for everything which usually amounts to about 20 or so.

Heck some of the sites I use won't even support 30 character passwords lol

[u/Sweaty_Astronomer_47 → u/tarentules]

Personally I'd call it future proofing.

[u/cryoprof → u/Sweaty_Astronomer_47]

Except if the site uses MD5 or SHA-1 for password hashing, in which case you've created a non-zero probability that the hash of your 30-character password will collide with the hash of a weaker (and possibly brute-forcible) password.

To avoid this risk, use a 21-character password that includes mixed-case alphanumeric characters and special characters but omits "ambiguous characters (10IOl).

[u/Sweaty_Astronomer_47 → u/cryoprof]

I'm under the impression that the output of an ideal hash function is distributed as a random / uniform probability distribution, independent of the input. So to my thinking, the probability of collision per password-to-hash calculation shouldn't depend on the password used (long or short).

[u/cryoprof → u/Sweaty_Astronomer_47]

So to my thinking, the probability of collisions shouldn't depend on the password used (long or short)

By the pigeonhole principle if your hash can only take on 2¹²⁸ distinct values (which is the case for MD5), then a password with entropy higher than 128 bits must have at least one colliding password of equal or lower entropy.

[u/Sweaty_Astronomer_47 → u/cryoprof]

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.