how NOT to store login credentials

[Matthew Bendford]

Well, some of you may know it, some of you may not, but there's this one software company, rather big, started in germany, called "S A P". As on my daily basis I have to work with some of their tools (the one I use is pretty much THE industry standard in the field I'm working in - there're only very few not using it, but as to my knowledge that's most likely due to high license fees smaller new-in-the-club business struggle with to pay for) - and sure have my personalized login credentials for it. This week, my password overstayed its welcome in the "still valid" lobby and I got prompted for a change ...
Ok, I guess many here agree that keep changing passwords on a regular basis actually leads to easier passwords (that's actually proven by some studies) and to avoidable support tickets in the IT departments dealing with "I forgot my password"-tickets ... but ok ... someone the industry still doesn'T has changed on that topic - and maybe never will ... just imagine Capt. Picard on one of his famous self-destruct sequences - and the computer actually replies: "Your authorization has become invalid - please reset a new one." ... *sigh*
Anyway - I'm getting off topic here.
So, it came to my mind: "Well, over the years I developed a rather good ruleset about secure passphrases that I can remember" and typed in a new one. No, I did not made the mistake to just change the 3 at the end into a 4 - but actually did set a different one. To my surprise it got rejected with some message I've not yet encountered: "Your new password has to be different in more than 3 digits." - well, WHAT? It's a rather different password hardly even matching 3 spots - let alone enough to be only different in 3 or less ones - what the ... ?
Just out of curiosity I did on purpose what one should avoid: re-use my password but only changed on digit in it: same message. Changed a second one, a third one, and finally, after just chaging four digits it got accepted.
I still was curious and fired up the change dialog again - and typed in a way different phrase - but made sure it actually did match up exact 3 digits and random spots - and I got the error again.

Conclusion: Yes, for what ever reason, SAP seem to store passwords in PLAIN. Otherwise it would be impossible to detect if a passphrases matches another one on a specific number of digits, even with simple hash algos like md5 or sha1. So, how does a fortune500 company get away with storing user passwords in plain text, no even using a random salt - let alone proper hashing functions - but still generate millions of net growth each year? With THAT knowledge for me it's just a matter of time the next big database leak appears on the net - maybe this time a SAP user database? Or even worse: customer records? I'm just shocked ...

[Stephan van Hulst]

Sooo can't your company file a complaint?

At any rate, you should be able to request all current passwords they have of you as it falls under GDPR.

[Peter Rooke]

How do you know that they are not stored with some sort of encryption?  Agreed it's better to use a hash function.  I'm not familiar with SAP but I'll sort of expect them to comply to some sort of security standard.  

[Matthew Bendford]

Peter Rooke wrote:How do you know that they are not stored with some sort of encryption?  Agreed it's better to use a hash function.  I'm not familiar with SAP but I'll sort of expect them to comply to some sort of security standard.  

Because it does not matter if you store something in plain or encrypt it but save the key used along with it. The dialog was able not just to make assumptions but could actually tell the difference between my old password and my new password. Even using heuristics that's quite a stunt to pull of when using proper hashing functions. So, either way they store it plain or encrypted - the system is able to reconstruct my original password - which should not be possible by the proper use of one-way functions.

As for filing a complaint: I did so the very first day I learned that I pretty much only have two passwords: one for logging into my account and all programs - and the second one for SAP. So my guess is that the IT department either just don't care - or cause they face the issue that they can't connect the SAP to the main ActiveDirectory user database cause that at least use some sort of hashing.
They even were so lazy to name the domain just a single letter. Just from looking at it tells me the either really have no clue what they're doning - it that case I could at least forgive them - or they don't care on purpose.

Anyway - I'm not just shocked they have implemented it this way, but also relaying that information specific back to the user - which isn't could security practice either.

[Ron McLeod]

Matthew Bendford wrote:This week, my password overstayed its welcome in the "still valid" lobby and I got prompted for a change ...

NIST revised their guidelines on periodically changing passwords. The current NIST 800-63 requirements states:

"[password] Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)",

with the FAQ explaining:

"Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time".