So the hackers have to steal the password file and steal or work out the encryption algorithm too, and do all this without anybody noticing they have done so or the owner will lock up the system or force change all the passwords. We are told to make our passwords longer and that would make the hackers’ lives more difficult. Hmmm.
The whole point of a cryptographic hash function is to turn a piece of plain text of variable length into a fixed size bit string.
All information about the original text and its length is effectively lost.
If matters little if the original password was 4 characters long or 40 characters long, unless a hacker has some clue as to the size and properties of the original password.
The keyspace of your typical 4 digit Pin is tiny. Yet commonly used. And considered acceptably secure. Why? Limited guess attempts.
Which is fine if nobody has downloaded your database of a million account passwords. If they have, they can then sort the hashes into ‘most common’ and brute force based upon published articles about most commonly used passwords.
In other words, hashing does not remove all information about the original password.
This is why you need to salt before you hash.
Actually it does. What you refer to is hash collisions, where a particular password will, as it must, end up with the same hash value. Otherwise the password could never be validated.
This was realised to be a problem, and since the 1970’s an additional randomly generated bit string was added, called a salt, to the password, before hashing.
As with the userid, the salt is stored in plain text.
So get hold of a userid/password file, and if the hash function is doing its job, there should be close to zero probability of any hashes being the same for any sorting to be used as an attack method.
1 Like
There were definitely assumptions in what I wrote. In particular, I left “fully compromised” open to interpretation. Fully compromised could include
- password file copied away and subject to successful brute force offline attack
- password validation code is “instrumented” so that any password that is actually used for the purposes of login is copied away in plain text
The illustrated password is not really strong enough to survive offline attack. But it’s better than most actual user passwords that I see. 
It is also worth noting that if this technique is widely used by a given user then sooner or later the user will sign up to a web site that is not a “serious website” - since you have no transparency whatsoever whether the web site is horribly naive or partially OK or state-of-the-art. The compromise of the non-serious web sites will then in fact put at risk even those web sites that are state-of-the-art (since the variable part of the password is way too short).
This user won’t be low-hanging fruit - and that’s good. Low-hanging fruit will be the first pass, where all the stupid passwords will be discovered using dictionary attack.
Random observation: Most hackers will have a clue - because the web site will publish and enforce the length restriction and/or the character subset restriction, if any.
There are some sites out there that persist in telling a user what the password should contain. Like at least 8 characters, at least 1 capital, numeric, and special character.
Which is just an invitation for a password like Password1$
Better are sites that let you use any string of chars you want up to at least 40 and compute a password strength based on length, characters, and dictionary search to advise that your password entered to set up an account is good, or crap.
1 Like
Just when everyone thought they had it figured out, here ‘we’ go again.
Trapped in the Googleverse where your public key is stored. And you need a second Internet connected device to provide the verification. No thanks.
1 Like
Couldn’t agree more, @Gregr - and the security police are beginning to change their password recommendations - at last.
From https://www.bleepingcomputer.com/news/security/a-password20231-password-may-not-be-as-complex-as-you-think/, with my emphasis:
… In some ways, past best practices for password policies may have made password cracking easier. …
… NIST [National Institute of Standards and Technology, US Department of Commerce] and other organizations have recommended changes to current password policies, as noted in the 2020 updated NIST 800-63b guidelines. Considering years of learning from password breaches and user behavior, the following general recommendations have been made.
- Do away with regular password change requirements unless a user requests one or if a breached password has been found.
- Eliminate password complexity requirements; focus on overall password length (12 characters, for example).
- Mandate screening of new passwords against commonly used dictionary terms, including custom word lists and previously compromised passwords.
Surely the second and third recommendations could easily be adopted by any website that creates user accounts.
It’s good to see that regular password changing is now deprecated - at last! Most of us who’ve been involved in delivering and supporting IT services always argued against this; it’s not an effective security measure, and in fact makes things worse, because users forced by their IT system policies to change their passwords regularly are more likely to choose the first weak password they think of, so they can remember it. And IT support staff tend to be inundated after each forced change with requests to reset passwords for people who’ve forgotten the new one, or absent-mindedly entered the old one several times and got locked out. 
7 Likes
Fortunately, using centralised authenticating methods in the business world like LDAP and Kerberos made logins much easier. Just one or two passwords for users to remember.
Except for the implementation. You can use the Apple one, or the Microsoft one, or the Google one. One of those companies has your back, unless they come up with a way to transfer passkeys between them (which they have said is not a priority).
It is possible to go with identity management that does not rely upon anyone else to certify that you are in fact you. If SQRL were picked up by these companies, rather than them developing their own ‘standards’, I might go with that. Of course, it means that if I lose access to my identity then there is no mother to cry to - but some of us would actually like that.
I suspect that the theory was if you didn’t change your password you were no longer using the account and it could be deleted. Of course, that’s using a screwdriver when you need an Allen key.
Wouldn’t think so. Logins are logged by all systems I have used. Not changes of passwords necessarily.
1 Like
I can think of a financial management system I administered in the mid-'90s that did not log logins (although the server might have logged connections).
What application programs log or do not log is up to them I suppose. In IT support I deal with the systems level.
It was common way back last century for application programs to have their own internal user validation, but these days operating system services would be used for security.
My theory has always been … if your credentials have been compromised (copied or otherwise obtained) and you never have to change your password, and never do so, then a malicious party can continue to use your credentials forever.
Now that isn’t absolutely correct because any half-decent entity has some kind of surveillance for irregular logins (e.g. time of day or e.g. geographical location or …) - so that use of the credentials by the malicious party might be detected by IT even if it is never detected by the actual user. Even so, forced change of password is one tool in the kit.
But I agree about the downsides of forcing users to change password.
While that is generally true … a requirement to change the password asks a slightly different question i.e. do you still need this account? rather than: are you still using this account?
An entity can do it either way, depending on their requirements. The more stringent entity would use the latter: logins are logged and if the account is not used for X days then it is automatically disabled (or deleted), no questions asked.
1 Like
If your login and password becomes known by another entity, and forced password change is in place, then an unfortunate situation can occur.
The entity, who knows the password, then changes it to a new one when forced to. You are locked out of your account since you no longer know the new password that the entity was forced to provide.
On the other hand, if there is no forced password change, then if you suspect issues, you can login and change the password yourself. Which will stop the other entity logging in since they no longer know the new password.
What if it requires 2 factor ID to authenticate?
For how long might a bad actor have account access before being asked at login to update the password? Assuming you have not logged in in the interim and changed it locking them out.
Assuming you are locked out does that not give the game away? IE you contact the account provider directly and they lock the account. At least that’s what CC, banks etc provide as a service. Of course by then it could be too late anyway. Better to know sooner rather than later!
Of course one can log in if one suspects suspicious activity and change the PW, regardless of whether a forced PW change is in place.
Yes, this is what will happen. However if the legitimate user does occasionally use this account then this will at least bring to both the user’s attention and IT’s attention that there is a problem - and could trigger a wider investigation e.g. examination of logs to see what actions the malicious user using the copied credentials had carried out. I would rather that the period of time for malicious activity is bounded by the password change time interval.
There is a risk that the legitimate user never uses the account and the malicious user keeps the account active by changing the password every X days. You need other processes to cover that risk.
We partially cover that risk by sending out password change notifications via email, where the email is a completely different system and account, as compared with the underlying account - so that it is at least not guaranteed that if one is compromised then both are compromised. (If the user fails to act on the email then the underlying account will get disabled.)
We have other systems in place - but I’m not going to pretend to you that any system is perfect, particularly where humans are involved.
Indeed. There have been cases come to light where
a) the bad actor had account access for many years before being discovered, or
b) the bad actor had account access for so long that investigation was unable to say how long the bad actor had account access other than that it was a long time.
Then that takes care of the problem. Every time one logs in, whether it is once an hour, or once a year, a new one time code is required. The 2FA system will generate the code so there is nothing to remember or be compromised.
If that one time code only has a lifetime of a few minutes, then it is pretty secure.
May as well get rid of the traditional password as a pointless waste of time.
1 Like
