I am not a network guy at a cellular company, but IMO it would make more sense to use a more local gateway for outgoing connections rather than potentially routing things all the way across the country. These days people keep their number but move all over the country. It would be insane to have to route things back home every time.
Checking geo IP services on my phone usually put me in roughly the same metro area that I'm physically in despite my area code belonging to a city hundreds of miles away. That said, I just tried a lookup on the cellular network on Maxmind and it thought I was in the next state over (a couple hundred miles off).
IP geolocation services usually aren't as great as what people think. My residential home IP had probably previously belonged to some Canadian ISP as things that would base their defaults off a detected geo IP lookup would think I was in some small town in Quebec despite living a thousand miles away. IP addresses change hands, people connect through all kinds of proxies and CGNAT gateways, location databases get old.
I'm not basing it on my phone number that's for central NC and from 10 years ago, I'm going off of the geoip and the fact that I get tons of ads or sites defaulting to Atlanta for weather or local store searches if I don't allow them more device based location data.
it's the latter, not the former. once you're compromised, passwords, changed or not, are no longer an obstacle at all.
password rotation does not increase security.
If you're infiltrating a company, most people's accounts certainly don't give you the level of access required to bypass the need for passwords entirely. You'd have to be specifically hacking a sysadmin's account or something.
There are very many different levels of "compromised" and they're not all the same.
That being said, I agree with the overall premise that password rotation is outdated.
Unix-like OS in 80s-90s truncated passwords to 8 bytes, hashed in MD5 and stored them to regular file `/etc/passwd`. And in those era it was estimated to take six months to few centuries to brute force a password, therefore it was recommended to maximally complicate the password within 8 letters in length, and change it every one half the brute forcing time, or three months. Supposedly everything made sense in that timeframe in that context.
In the era when password hashes were still readable to everyone in /etc/passwd (this was later fixed by storing the passwords instead in a shadow file called /etc/shadow which can only be read by root), it was not MD5, but "crypt" (a DES variant). AFAIK, the MD5 and newer password hashing schemes don't truncate the password to 8 bytes, only traditional "crypt" did that.
https://inbox.vuxu.org/tuhs/87bluxpqy0.fsf@vuxu.org/
https://fossbytes.com/unix-co-founder-ken-thompsons-bsd-pass...
[1] https://github.com/dspinellis/unix-history-repo/tree/BSD-3-S...
We were required to change passwords once a month, and not re-use any of our last 6 passwords.
It has always seemed like a totally pointless exercise.
I can see potential value for service accounts, as long as you have automation in place to change them where needed - but for user accounts, it's complete madness.
Or, the current plaintext password is compared to the new plaintext password (normally a password change requires the current password) so you can do more sophisticated similarity checks, but only compared to the current passord, not any older ones.
The purpose of preventing similar passwords isn't to prevent a user from defeating themselves, it's to prevent an adversary from defeating the user.
Now you can rightfully argue that blocking similar passwords isn't an effective measure against an adversary, and this article kind of suggests that... but it is possible to implement such a system.
I think the idea is that most users will just choose another password if you tell them the one they entered is too similar to their previous password.
But my opinion is that ensuring creative passwords with an unclear similarity rule will only result in creative bypasses of that rule.
A better focus is on plugging the hole where the password was stolen. If it’s not plugged the password will simply be stolen again.
The reason rotating passwords is pointless is because people always end up changing their password to some easy to guess variation of the original password. If you prevent that from happening, the new password won't be guessable if you have the old one.
basepassword-2021
which they will change next year to
basepassword-2022
Because password hashing makes it impossible to retrieve the original password, there is no way to guard against people just using a basepassword and appending some type of counter to it.
Thus if there really is a breach where the plaintext password is recovered by an attacker it is trivial to find out what this year's version is.
So all you end up doing is needlessly irritating your users, for not much security.
Multifactor Authentication is a much better solution for the issues of unknown breaches.
Sure there is. In your update logic, decrement any numbers and check the hash against the existing password. Alternatively, require the existing password in the same form and you don't have to check against hashes, since you have the plaintext password right there.
People will either keep trying new strategies to embed counters in their passwords (maybe increment a letter, or multiple a number by 10), or they’ll just write the password on a post-it they keep on their laptop.
Either way you’ve now got a whole load of complicated code that makes it harder to people to create genuinely strong and memorable passwords, and no additional security.
Because it had a fairly short password cycle, I'm sure most users ended up with something like "password1!TwentyFour" then "password1!TwentyFive".
Me: I just changed my password 51 times when it was time. I'm not sure what point I was proving, but I was proud of myself.
Of course, it's also possible they stored the clear text password, I have no real way of knowing.
This is impractical if you're following good password storage practices. Assume the user's new password is 16 characters long, and that only the 95 printable characters are allowed in passwords. Then to test that the Levenshtein distances between it and the user's last 5 passwords are all greater than 1, the server would have to compute (5 * (1 + 95 * 17 + 16 + 94 * 16)) = 15,680 different hashes, which will take quite a while if you picked a secure iteration count for your password hashing function. And even if you did this, it still couldn't detect mypassword100100 -> mypassword101101 -> mypassword102102, etc. (Making sure the Levenshtein distances are greater than 2 would require checking millions of hashes.)
Presumably, you will also have a forgot password flow that allows you to change your password without entering the old one.
People will make things easy for themselves. Coming up with good passwords is hard. Having to rotate passwords just seems like a lot of busywork and people will make it as easy for themselves as possible.
SomePasswordABC SomePasswordDEF SomePasswordGHI
...
Or
My1Password! My2Password! My3Password!
...
Or
MyPasswordUno MyPasswordDue MyPasswordTre
Almost all the implementations require the old password when you change it to the new password, so it's trivial to check if they are too similar.
def changePassword(login, cleartextOld, cleartextNew):
if too_similar(cleartextOld, cleartextNew):
return new Error("too similar")
hashOld = hash(cleartextOld)
hashNew = hash(cleartextNew)
if authorized(login, hashOld):
setPassword(login, hashNew)
return new Ok();
If you're afraid of sending cleartext passwords - do the too_similar check on the client side. The users that can write their own client to bypass client-side checks are exactly the users you don't need to worry about.That's why, to encourage users to assume last month's password was compromised, when my users change their password the old password is automatically posted to twitter
/s
> Thus if there really is a breach where the plaintext password is recovered by an attacker it is trivial to find out what this year's version is.
These are contradictory statements.
People (including me) _hate_ memorizing things and would probably write an assigned password down, but isn't it better to expose passwords to nosy coworkers than to the whole internet, as is so often the case with weak or reused passwords?
We do that. We generate long random-character passwords (both for e-mail, web sites, and other accounts), and we don’t provide any online way for users to change them. If the users need to change a password, they have to contact us to do it (which is reasonable, since a big part of our value proposition is our responsive support). We only very occasionally even get such requests, and even more seldom get requests from users to set their own passwords. So far, everybody has been perfectly satisfied when hearing “No, users don’t set their own passwords. We can generate a new one for you any time you like.”.
This policy has been in effect since before my time, and I have worked here for more than 10 years. During this time, there was one user who really wanted something more memorizable for a specific account, so I set a correcthorsebatterystaple-style password on that account only. One other user had trouble adding the password to their password manager, and I had to help them do that. Otherwise, no problems.
Then the system could reject these on the next password change without storage of the original plaintext password.
The focus should be on preventing a security breach, not what to do after its happened.