• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Bear Bibeault
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • salvin francis
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
Bartenders:
  • Jj Roberts
  • Carey Brown
  • Scott Selikoff

how NOT to store login credentials

 
Ranch Hand
Posts: 52
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ...
 
Saloon Keeper
Posts: 12734
277
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 1087
19
Mac OS X IntelliJ IDE Oracle Spring VI Editor Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 52
2
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Marshal
Posts: 3409
493
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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".


 
ice is for people that are not already cool. Chill with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic