password policy
-
If they have enough hashing capacity (trivial if SHA*, needs a cluster if using a slow hash), they could mutate your new password making every possible 1 character addition/subtraction/substitution and see if any of them match the old hash.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
True. But unlikely.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
That's an idea: we should assemble a CP password.txt file, for general use in the MoronicKneeJerkPasswordPolicy domain. It would save us the trouble of creating our own. [edit] If you think 90 days is bad, I worked at one place that had a holiday-booking webapp where they required a new password every 30 days. How often do you book holidays, for Arbuthnot's sake! Essentially, every time you opened the app, you had to change your password. [/edit] [edit2] Holiday = vacation, to blasted colonials. [/edit2]
I wanna be a eunuchs developer! Pass me a bread knife!
-
Well, we don't need to re-enter the old password and assuming it does not save it in clear text, how is it comparing the old (encrypted) password to the new (encrypted) one? example: OLD password text: god_123 encryped: &#HDSW NEW password text: god_124 encrypted: )#@^Y@ it should not save the text version and it should not be able to compare the encrypted version, right? [EDIT]We are "logged in" though, (LDAP), but I'm assuming, equally, the password is not saved in memory either...[/EDIT]
V.
(MQOTD rules and previous solutions)
what about comparing it before encrypting and saving? :rolleyes: :rolleyes:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
Who says it's hashed? There are more than 0 IT departments on this world who have no friggin' idea what they're doing.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
It could perform such from the other way round. E.g. take the new password, generate a set of permutations by changing one or two characters in it, compute the hashes for each and check if such hash equals the original password. Of course, this can become a lot more complicated - especially if starting to compare more than just one character being optional. Thus such calc could take a lot of time. Not to mention, it "should" be done client-side else you're sending a plaintext / encrypted password to the server - which then does these calcs. The whole idea of a one-way hash is so you never have the actual password outside your own client machine. Alternatively, another idea which may be even better ... Pre-calculate hashes for all the "bad-list" passwords (i.e. those stuff where passwords are leaked and compared to just how many people use them). Then whenever a user enters a new password, compare its hash to the table of pre calculated hashes. Again, it may become a bit more computationally intense once you have to throw salting into the mix, unless a salt can be applied to a hash at a later stage instead of to the password before calculating the hash (again algorithm dependent). But I think this way should avoid most of the major issues, while using much less computations than the permutation idea.
-
Well, we don't need to re-enter the old password and assuming it does not save it in clear text, how is it comparing the old (encrypted) password to the new (encrypted) one? example: OLD password text: god_123 encryped: &#HDSW NEW password text: god_124 encrypted: )#@^Y@ it should not save the text version and it should not be able to compare the encrypted version, right? [EDIT]We are "logged in" though, (LDAP), but I'm assuming, equally, the password is not saved in memory either...[/EDIT]
V.
(MQOTD rules and previous solutions)
Keep a count of chars and hash those. When you input the new password, count the chars and then compare the hashes. Example: god_123 = 1g1o1_111213 . Obviously it's a terrible idea to keep it in plain text, thus you hash it. Once you type the new password, match hash against hash. Done.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
Thats an old technology, the Soundex code. Its a type of hashing to see if two words sound alike when spoken. It was a common way to look up names that may have been misspelled when first entered into a database.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
You are looking at it from the wrong perspective. If someone steals a password database with hashes in it and crack them, they aren't going to try hashes that are similar. They are going to try altering the known good passwords slightly. If my password was stolen in September and they manage to crack it to find that it was "pass0916" then obviously "pass1016" would be a very likely guess for someone trying to breach my account this month. That is why similarity of source matters over similarity of hash.
-
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
You work for the government, don't you? :)
-
You work for the government, don't you? :)
-
Well, we don't need to re-enter the old password and assuming it does not save it in clear text, how is it comparing the old (encrypted) password to the new (encrypted) one? example: OLD password text: god_123 encryped: &#HDSW NEW password text: god_124 encrypted: )#@^Y@ it should not save the text version and it should not be able to compare the encrypted version, right? [EDIT]We are "logged in" though, (LDAP), but I'm assuming, equally, the password is not saved in memory either...[/EDIT]
V.
(MQOTD rules and previous solutions)
The passwords don't need to be stored plaintext in order to check for similar passwords. The password checker could create several variations of your proposed password, hash them and compare to your previous password hashes. For example, if the last character is a number, all digits [0-9] could be tried at that position.
-
V. wrote:
how is it comparing the old (encrypted) password to the new (encrypted) one?
It decrypts it first, encryption is two-way. So it takes "&#HDSW" from the database as your old password and decrypts it to "god_123". It then compares that to the new password you've entered.
-
I think this could go alongside Godwin's Law - the longer an on-line debate about passwords continues, the probability of someone linking to xkcd 936 approaches certainty. Won't somebody think of the horses (and staples)?
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
-
In Active Directory, there is a GPO that you can activate to force passwords storage in plain text. I cannot imagine any situation where that would be suitable, though. On the other hand, the security breach concerning passwords must not be observed only through their storage on the servers; humans themselves may represent a non negligeable risk when it comes to password security (writing them down on a sticky note, always following the same pattern, references to family, friends, pets, etc.).
Loneliness and cheeseburgers are a dangerous mix.
I have a little black A6 notebook, one of the ubiquitous ones with hard covers and a red spine, and I am ceasing the practice of using only a few passwords, and setting a new one for each account. Then every new user-password pair is written into that book. My passwords, except on their systems, can only be found in one place, and nowhere online. And if I buy the farm, friends and family can look up needed passwords in that book, without having to subscribe anywhere online, or know any other password. I think that book has one of the highest levels of all password storage security strategies that exist. Oh yes, and I never say them out aloud as I write them, in case someone, somewhere, somehow, is listening in on me.
Follow my adventures with .NET Core at my new blog, Erisia Information Services.