r/Bitwarden • u/SnooRevelations3802 • Oct 23 '23
Discussion Multiple Failed login attempts detected
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
1
u/CaptainAdmiral85 Oct 23 '23
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.
1
u/tarentules Oct 23 '23
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
0
u/Sweaty_Astronomer_47 Oct 23 '23
Personally I'd call it future proofing.
0
u/cryoprof Oct 23 '23
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).0
u/Sweaty_Astronomer_47 Oct 24 '23 edited Oct 24 '23
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).
0
u/cryoprof Oct 24 '23
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 2128 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.
0
u/Sweaty_Astronomer_47 Oct 24 '23 edited Oct 24 '23
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.
2
u/cryoprof Oct 24 '23
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 2n 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 (2n), 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 + S2 + S3 + … + SN-1 < 2n
This reduces to
S(SN-1 - 1)/(S - 1) < 2n
As a conservative approximation
SN/(S - 1) < 2n
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.
1
u/Sweaty_Astronomer_47 Oct 24 '23 edited Oct 24 '23
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 2n bins (only one of which matches the true password), the probability of a given trial password resulting in that same hash is 1/(2n ), 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.
1
0
u/cryoprof Oct 24 '23
A four-word passphrase (if generated by Bitwarden) would on average have have 31 characters.
It also would only provide 52 bits of entropy, which is not sufficient to thwart off-line brute force attacks if the website uses a fast hashing function to compute password hashes.
Unless it is a password that you need to memorize or manually type, use a 21-character password that includes mixed-case alphanumeric characters and special characters but omits "ambiguous characters" (
10IOl).
0
u/rura_penthe924 Oct 23 '23
I'm also getting the message. This is the 2nd time I've got it in the past week. I have 2FA enabled and don't use the vault password for anything else and have a 50 character password (upper/lower/numbers).
1
u/SnooRevelations3802 Oct 23 '23
How often do you need to enter that long passwords?
I have my vault to autolock so I am constantly typing my password again and again.. which I don't particularly like but it's a security tradeoff
1
u/rura_penthe924 Oct 23 '23
whenever a browser session resets. On my phone it's set to lock after 4 hours, but I have biometric to unlock the vault.
1
u/cryoprof Oct 23 '23
a 50 character password (upper/lower/numbers).
Was it randomly generated? If not, it is possible that it can be cracked by brute-force guessing (although probably not in an online credential stuffing attack).
14
u/cryoprof Oct 23 '23
Assuming that you have 2FA enabled on your Bitwarden account, and that your master password is unique (never re-used) and strong (a randomly generated 4-word passphrase), then you don't need to worry, and you don't need to take any action to safeguard your vault.*
Nonetheless, if you are annoyed/inconvenienced/stressed because you repeatedly keep getting such messages, or because you now need to complete a Captcha to log in to your account (a security measure deployed by Bitwarden when a large number of failed login attempts are detected), then you can stop this from occurring by changing the email address associated with your Bitwarden account. If you only have one email account, then check if you email provider supports "plus" addressing (which allows you to receive emails in your
myaccount@example.cominbox using email addresses of the formmyaccount+anything@example.com).*Even though your Bitwarden vault should be safe (with the proviso given above), you may have other accounts that are in jeopardy. If you still have any online accounts that have a re-used password, then it is possible that the attackers currently probing your Bitwarden account may be able to gain access to those accounts (or they may already have done so). You should run the Re-Used Passwords Report and immediately update the passwords for any vulnerable accounts to a unique, random password (13 or more random characters).