7

Most services, programs, etc. have various password complexity checks. Without delving into the efficacy of such checks, I thought of one that might be interesting, but also potentially problematic check:

"The new password must be Y characters different from the last X passwords."

This would prevent people from using passwords like Password1!, Password2!, and so on. But if that's done, one cannot hash the previously used password - they would be at best encrypted... Right?

For a small Y and a fairly short password, you could probably still store the hash and bruteforce all Y letter variations of the new password, but this gets unfeasible as Y and the password length grows.

My original idea is this: since when you change the password you must provide your original password, hash the new password and store and the old one in encrypted form. Now it's reversible.

So assuming an active password is always hashed, is there a better way to do this? And also does having this in place increase or decrease the security of the application?

NullUserException
  • 83,810
  • 28
  • 209
  • 234
  • 1
    in my opinion, changing passwords regurlarly always compromises security because you cannot expect people to remember 2000 different passwords. In my experience they change it to something new, then log in and change it back to the old one quite fase. – Ben Sep 01 '11 at 03:20
  • I've never seen instances of preventing people from incrementing their password by one. However I have seen instants of checking users personal details and trying to guess passwords from it and against a list of most popular passwords. This being said, this question its better off in the security site I think. – Ali Sep 01 '11 at 03:20
  • 1
    Also id like to add that you should NEVER EVER store unhashed/salted passwords in your database – Ben Sep 01 '11 at 03:22
  • 2
    @Ali This is actually part of [Oracle's password complexity verification](http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/security.htm#CNCPT1566) – NullUserException Sep 01 '11 at 03:23
  • @Ben That's actually part of my question; if only *old* passwords are symmetrically encrypted, is that a problem? – NullUserException Sep 01 '11 at 03:24
  • Oh could keep a salted hash of each character of the password stored as a list in the database, this way when a new password is entered you can match each character without knowing what it is. Since the individual characters are salted a character will be different for 2 users with different salts. – Ali Sep 01 '11 at 03:26
  • 1
    @Ali That doesn't really help, since one could easily bruteforce the characters and reassemble the password. – NullUserException Sep 01 '11 at 03:30
  • offcourse you could just ask your user to enter their old and new password, that way you have both in plain text available – Ben Sep 01 '11 at 03:34
  • As a final suggestion, you can encrypt the single character hashes, or add padding to make the single characters longer or both if you like. You could even double or triple hash the single characters after padding them. – Ali Sep 01 '11 at 03:35
  • @Benjamin Yes, but how do you get their 2nd to last password? – NullUserException Sep 01 '11 at 03:37
  • ye that would be impossible. and it sounds rather unsecure to me to store those somewhere because people generally base their new password on their old ones even if they have to differ 3 chars. Isnt it just easier/safer to take xkcd's advice and just have a minimum lenght of 15 without numbers, capitals and stuff? and forget about the whole password changing? – Ben Sep 01 '11 at 03:41
  • I'm not the downvoter (upvoted, actually), but I did want to respond to one of your questions. Storing any password at all in reversable form is bad. Users reuse passwords all over the web. Whether that's good or bad, it's a fact. You don't want to expose their web passwords to some disgruntled employee on your side who can reverse the old passwords and then create problems for your user and for your company. –  Sep 01 '11 at 07:03
  • I cannot believe people are downvoting and/or trying to close this question. It is perfectly legitimate, and the fact that the answer is "Oracle is stupid" makes it extra awesome. – Nemo Sep 01 '11 at 15:09
  • @Willie: In his proposal, each user's old passwords are stored encrypted by that specific user's new password, not by a single key that a "disgruntled employee" could steal. If you further only perform the decryption on the client side, this is not much less secure than storing anything else encrypted by the user's current password. – Nemo Sep 01 '11 at 15:14
  • @Nemo I am mentioning this is an example. Oracle doesn't actually require the password to be 3 characters different from all previous passwords - just *the* previous - for which storing passwords in a recoverable format is not necessary. This is an extension to another requirement that your new password shouldn't be the same as your `N` previous passwords, which some other applications require. – NullUserException Sep 01 '11 at 18:51

3 Answers3

2

I tried to put this in a comment, but I think this is important enough to put in an answer.

The scheme proposed by OP is not necessarily a violation of CWE-257. The proposal does not allow a system administrator (say) to recover the old passwords.

The proposal is to use the new password as the encryption key for all of the old passwords. If you can live with the "new password verification" living on the client and not the server, then this is no less secure than encrypting anything else using the password.

So the "change password" gadget would be client-side code. The server would send the encrypted list of N earlier passwords, which the client could decrypt with the user's current password and then re-encrypt with the user's new password. At no time does the server have enough information to determine any of the passwords, whether old or new. Only the client has this information, but it has that in any case... The difference being that an attacker who learned your current password could also learn your old passwords. Since learning your current password is already a disaster, this does not strike me as all that much worse.

True, this does not guard against the "attack" of an employee writing their own password change utility to get around the password restrictions, since the validation is not done on the server side. But in no way is this a violation of CWE-257, in my opinion.

It is actually a reasonably clever idea.

Nemo
  • 70,042
  • 10
  • 116
  • 153
  • I really disagree. By analyzing the pattern of past passwords the most recent one becomes much less secure. A hamming distance cuttoff of 4 bytes or so reduces the complexity to a few thousand guesses. I think cwe-257 is very applicable when attacking this system. – rook Sep 01 '11 at 19:06
  • @Rook: I think you are missing the point, unless I am missing yours. In this proposed scheme, _there is no way for an attacker to get the old passwords unless they already have the new password_, because the old passwords are only ever stored encrypted by the new password. – Nemo Sep 01 '11 at 23:43
  • @Nemo No, if you store passwords in a very insure fashion you should assume that they are plain text. After all what is keeping the attacker from reading the key from a text file? In fact this statement of yours goes against "Defense in depth" in every way. – rook Sep 02 '11 at 02:07
  • @Rook: You have completely misunderstood the actual proposed scheme here. (That is, you are assuming it is something else.) There is no "key" in any "file", not at any time. In fact, there is no single "key" at all. Please re-read the OP's description and mine carefully, because your responses have nothing to do with the actual proposal. – Nemo Sep 02 '11 at 02:40
  • @Rook: Did you downvote my answer? (For the record, I did not downvote yours...) – Nemo Sep 02 '11 at 04:54
  • @Nemo No i think you have an interesting solution to this bland and pointless problem. – rook Sep 03 '11 at 10:29
  • @Nemo: This is a fascinating approach; I like it. The only caveat is that I don't approve of your theory of sending the old passwords to the client (even in encrypted form). Two issues: 1) Trusting the client to audit password choices (you propose a malicious server-side password changing tool... why is the client immune?) and 2) Password changes aren't the only time the server sees the password; Sending the encrypted old passwords to the client doesn't add any protection. – Slartibartfast Sep 04 '11 at 06:15
1

The Oracle requirement you reference says that password n must differ sufficiently from password n-1, not that password n must differ from all previous passwords. Usually to change a password you make the user enter the current password as part of that. So you have everything you need to implement the requirement, and you don't need to store passwords in a reversable fashion (encryption, brute forcing, whatever).

I understand that this doesn't directly address the requirement as originally posed (differ from last X passwords), but my feeling is that it's a bogus requirement. Your requirement would require reversable passwords (the mechanism doesn't matter) and most experts will agree that that's incorrect. I believe you've simply misinterpreted the Oracle requirement, if that's indeed what's driving the question.

EDIT:

OK, I just thought of a way to implement what you're asking for without reversable passwords. I still think you're misinterpreting the Oracle requirement, and I wouldn't actually do what I'm about to describe myself, but it will meet the requirement without reversable passwords.

  1. Pick a reserved character that's not allowed to appear in a real password. For the sake of discussion, suppose it's a backslash.
  2. Enumerate all possible ways of substituting at most Y backslashes into the password, hashing the result each time.
  3. Maintain only the most recent X sets of hashes thus generated.
  4. When the user picks a new password, repeat the procedure on the tendered password and compare its individual hashes against the individual recent hashes.

Goofy, but that should meet the requirement.

0

Encrypting passwords is a clear violation of CWE-257 and there for should never be done. However in the case of an expired password, the user has just logged in, there for keep the plain text of this password. Then force the user to change the password and calcualte the hamming distance between the two. Once the user provides a password that is different enough, hash this new password and throw away the plain text.

EDIT: You could keep the salt+hash's of all of the old passwords to make sure the user doesn't pick a password he has in the past. But enforcing that the password is N letters different from all passwords weakens the system as a whole and is expensive as it would require o(n) comparisons.

rook
  • 66,304
  • 38
  • 162
  • 239
  • I thought so too, but you would still be hashing all *active* passwords. In a way, you could see the old passwords as any other data... Or couldn't you? – NullUserException Sep 01 '11 at 04:17
  • @NullUserException I'm not sure what you mean. If the attacker was root on the system then he could attach a debugger and see the plain text passwords in memory. But usually an attacker uses sql injection to obtain password hashes, and this system is secure against this common attack. Or are you referring to session sate? – rook Sep 01 '11 at 04:22
  • 1
    What I mean by active password is just the password currently in use, and these would always be hashed. Symmetric encryption would only be used on older (ie: expired) passwords. Note that I am only talking about passwords (hashed or encrypted) being stolen from the database. – NullUserException Sep 01 '11 at 04:40
  • @NullUserException hashed passwords being stolen from the database is always a problem. But did you read cwe-257? Encrypting the passwords makes the problem much much worse, and its not needed to solve your problem. The user gives you the plain text at the same time it needs to be changed. – rook Sep 01 '11 at 14:53
  • O(N) is actually OK for something that doesn't run that often. In fact, I'd be willing to take anything with polynomial time complexity if it actually strengthens the system. – NullUserException Sep 01 '11 at 18:49
  • And yes, I read CWE-257. You would be surprised to find out how often this is violated. I literally *just* found out my new apartment complex' software, which stores my bank account information, has recoverable passwords. Who knows how secure the rest of the data is. – NullUserException Sep 01 '11 at 18:53
  • @NullUserException ok but the negative security impact **not okay**. I think that by doing this you are making the system **far less secure**, and the CWE system agrees with me. – rook Sep 01 '11 at 18:53
  • You seem to be missing my point. Any password stored in a reversible format would be an inactive password, and by design, the user wouldn't be allowed to reuse that password. – NullUserException Sep 01 '11 at 18:58
  • @NullUserException I still think this is a horrific mistake, on paper you can say that. But if the hamming distance cutoff is 4 bytes then the attacker only has to make a few thousand guesses to break the most recent password. By analyzing the pattern of past passwords the most recent password will be made much less secure. I hope I have conveyed how much of a security disaster this is. – rook Sep 01 '11 at 19:00
  • Why do you keep repeating this "violation of CWE-257" nonsense? I dug thorough the Internet and you seem to be the only person on the planet who thinks CWE has any authority in such a way that something like this constitutes a "violation." CWE is not [PCI](https://www.pcisecuritystandards.org/) or FISMA. -1 for nonsense. – quantumSoup Sep 02 '11 at 01:42
  • @quantumSoup if you violate a CWE you'll have CVE issued for you insecure software. I'm sorry but CVE's are the authority of vulnerabilities in software. Ever hear of a CVE? – rook Sep 02 '11 at 01:58
  • @quantumSoup seriously that is such a inexcusable mistake, you should stay away from security tags because you are clearly lost, this isn't "yahoo answers". – rook Sep 02 '11 at 02:00
  • @Rook Google "CWE compliance" with the quotes. 112 results, as good as as none. "PCI Compliance" has 16.5 million. No one who actually knows what they are talking about thinks CWE has any authority dictating what should or should not be done. Find me one person who says there is something called a "CWE-257 violation" – quantumSoup Sep 02 '11 at 02:22
  • @quantumSoup wtf is cwe compliance? If you violate a CWE you will not be PCI compliant and i know because i am a CISSP. – rook Sep 02 '11 at 02:45