initial1
Quick, before we go on: what was your first thought when you saw the title of this post?
Let me start with
Excercise 1
(There’ll be more ๐ ) comment this blog by letting me know how many customers you know that are using “initial1” as the default initial password for SAP systems. Additional LIKEs will be given for other trivial ones you may have come across (like “welcome”, “password” or the day of the week).
Before I continue with this blog I would like you to head over to WIRED to read Mat Honan’s post on his cloud security desaster:
http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/
Scary, isn’t it? The Twitters have been going wild yesterday – tales of “epic hacking”, “iCloud exploit” and “security flaws” were told, when in the end it comes down to humans trying to be helpful.
The root cause for this case was a bad password reset process at Apple. When somebody called Apple and asked for help getting back into their account because they couldn’t remember their password, all that Apple asked for were the last 4 digits of your credit card (which the hackers got through a bad procedure at Amazon – they let you add a bogus credit card number AND a new email address AND send you the last 4 digits of all your credit cards to that new address) plus your billing address (which is probably available through WHOIS, Facebook or a plethora of other services).
(Both Apple and Amazon have changed their security policies in the meantime)
All that, of course, is necessary because more and more services rely on passwords, and passwords (at least if they’re good) are hard to remember. If you fail to remember them you need a procedure to be able to reset them, which suddenly is the weakest link in your online security chain.
A similar bad example are all the sites that send you your password in clear text (if you know some I suggest you delete your account there IMMEDIATELY until they fix that).
Just as bad is the “3 questions” meme – if you have entered your mother’s maiden name as a password reset question anywhere you’re in trouble. Stuff like that or your first school, street or pets name can be easily found on social networks and cannot be considered secure. If the question to reset your password contains your favourite colour you’re basically replacing your complex 16 character password by “blue”.
If password reset questions is all they’ve got make sure to invent complex answers to those questions (like “mothers maiden name?” – “dfl%R3SSx4”) and write them down in your favourite password manager. If you want to mess with support stuff you can try “I really can’t remember” as an answer as well ๐
Excercise 2
To get back to SAP systems – find out what the procedure to reset a password in your companies or customers SAP landscape is. Think of ways this could go wrong, and if you find some, report them to the responsible security manager (if finding that person is a struggle you get extra points for discovering an additional vulnerability).
If it’s done well the password reset procedure has a method of making sure you are who you say you are. I have been at countless customers where you’d call help desk and tell them a user ID, and their response would be “I’ll reset it to initial1, have nice day” (hence the title of this blog). In my 6 years of SAP security consulting I met one customer who really did it right, you had to walk over to the IT guy and show your badge, and he’d hand you a sticky with a complex initial password. It doesn’t have to be that strict, but anything that doesn’t require any kind of identification is likely to create issues.
Excercise 3
While the vulnerability in the case above was in the password reset procedure, the bigger threat is password re-use. If one site’s password database is leaked and you’re re-using that password on other web sites your accounts on those sites are immediately compromised as well.
As using a different long complex password on every site is hard I can understand you haven’t done it everywhere yet. Using a password manager like KeePass, 1Password or LastPass is a really good idea. LastPass has something called the Lastpass Security Challenge which lets you analyze your passwords for weak ones or re-use.
Whatever you’re using, please go and re-assess your passwords for strength and uniqueness. Go make a list of those sites, create a daily calendar entry and change two of those to better ones every day.
As expected, it doesn’t really get better in the cloud. I know we all want to make it easy for users, but you should really aim at making sure security is taken seriously. If possible, rely on something better than passwords – certificate based authentication, tokens, anything that adds a second factor (something you know + something you have).
Excercise 4
If you are a GMail user (which may put you into a high risk group in the context of this blog) please go there and activate Two Factor Authentication NOW. It’s a lot easier than it sounds (Matt Cuts has a blog with good explanation) and it’s a great experience that shows how easy it is to dramatically enhance security for an online account without compromising usability.
While you’re at it you may also check which applications have access to your GMail account and make sure they’re all still needed (same for Facebook and Twitter).
I’m afraid password security issues will be with us for quite some time. It’s well worth thinking about those issues regularly, it’s far too easy to get into the flow and let things deteriorate. We’re all adding new sites with passwords and links to other sites on a daily basis which may decrease our online security. This needs to be a constant habit, not a one-time activity.
Final Excercise
Add a monthly recurring calendar appointment to check your state of password security and application permissions.
It’s worth the effort.
I hope that blog will help you stay secure. If you have come across some good (or bad) practices around password security in the SAP environment I’d be happy if you could share them in the comments. We’re all happy to learn, even if it’s from other peoples mistakes.
Related posts:
Hi Frank,
really nice blog. It seems like this year will be year of password. Last one was mainly about anonymous and hacktivism. This year we've already seen many passwords dumps from major sites such as Linkedin. Hopefully, it will lead to better solution such as 2-factor auth. BTW this blog describes interesting attack and shows how hard it is to implement safe password reset function.
Speaking of solutions, when is SAP going to provide 2-factor auth for Netweaver platform? It seems like SAP has all what is needed. SUP and Afaria for managing mobile device that could be used as second factor. I guess ability to enable 2-factor auth for subset of users (by user group) would be great. I believe there is already functionality for defining various password policies for different groups of users.
Cheers
Hi Martin,
there is an interesting third party solution (which I personally also use for LastPass and Google):
http://www.yubico.com/yubico-brings-simple-and-strong-two-factor-authentication-to-sap-netweaver-
Frank.
Hi,
thanks for the pointer. Looks interesting but you need to carry USB token with you and it's only for ABAP AS. Solution that would leverage SUP to distribute one time passwords for logon to SAP might be attractive for customers that already have SUP deployed in their landscape. I think that ability to turn on second factor jsut for particular groups of users is crucial. For example you can't expect that every warehouse employee will have mobile device but users with high privileges such as admins have mobile device that is supported by SUP.
Cheers
Great Idea!
Now go an develop it ๐
Hi Frank,
actually I spent some time analyzing this and the problem is in ABAP AS. I spoke with colleagues who have good knowledge of SUP and it should be pretty easy to implement it in SUP. I wanted to use user exit SUSR0001 to display a pop up that will ask user to enter one time token received on her mobile device. There are two issues: debugger and Crete new session option. Debugger could be disabled by authorizations but I can't find anything how to disable option to create new session from popup window ๐ I also though about this and the system should not authenticate user before entering password and one time token. Hence using this user exit is not a good idea because user is already authenticated (hence issues with debugger). The proper solution would require modifying SAP GUI protocol to accept additional field on logon screen. I think nobody from SAP wants to touch this old legacy protocol :-). I guess the easiest way for implementing 2-factor auth is enhancing NW SSO solution.
Cheers,
Martin
Hi Frank,
will there also be likes for "Best password postit hiding places" like
- under the keyboard
- right on the border of the tft-screen
- on the laptop if you open it.
๐ Nice blog about an important topic! Thanks!
Yeah, there are more bad practices, I wanted to start with this one ๐ (like sharing accounts, giving passwords to other people etc...)
Thanks for the comment!
Well, I always try to avoid initial1 - I use Initial1 because this one contains a uppercase letter to confuse any attacker (just kidding ๐
If you use a quite short time period ( let's say just 1 day) for profile parameter login/password_max_idle_initial and especially if you set a new password while talking with the person requesting it, than I would accept such simple initial passwords.
But when you are using mail etc. to pass the new password to the user than I recommend to use the password generation button in transaction SU01 which produces passwords like this one by default: XGctHAXtp3F\5kLy)5gejvftgbjXcLNr$Rev8N#S
Does this looks too ugly? Than set some restrictions in table PRGN_CUST using transaction SM30 to produce a nicer result (see note 915488 ):
GEN_PSW_MAX_LENGTH
GEN_PSW_MAX_DIGITS
GEN_PSW_MAX_LETTERS
GEN_PSW_MAX_SPECIALS
--
Frank Buchholz
Hmmm... I think you should consider switching to Initi@l1 eventually...
๐
Many customers are advised by their auditors to limit the password validity period to 90 days. Correspondingly, you will often find that even the auditor user ID's have passwords which are a concatenation of the season (6 characters) and the year (2 digit format). Currently = Summer12.
I have encountered the prevailing weather conditions as well a few times, but after asking for a few resets from the helpdesk this can also be found and worked out with the help of some useful meteorological tracking websites...
Adding a special character (or even better is 2 specials because the first is likely to be "$" and easy to eyeball from relatively far away.. ๐ has IMO a big impact on the password quality and guessable likelihood / speed of producing a collision with the real password or it's hash. Second to deleting (deactivating) the password if it is no longer needed.
Cheers,
Julius
Hi Frank K - This was a good blog - thank you for putting this out there.
And Frank B - thank you for the information about table PRGN_CUST.
Thanks Frank for sharing it. It was a nice blog from security perspective.
Also if we are creating new accuonts for the users in production and giving all of them the same password, is also bad practice. I ahev seen in some of the projects security people give the same initial passwords to everyone in production system.