<rant>Well, some of you may have noticed that the site was down for a bit today. I hate to say it but the site got hacked. I wish the root problem was due to a bad password I used, a keyboard logger or something at least a little bit complex. It turns out that my web host, Media Temple, had their user database stolen and guess what… the user login passwords were stored in the clear. (Might be time for a new host…) So it wasn’t so much as hacking as it was just logging in and changing files. My site wasn’t the only one to get hit, many hundreds of sites of the same web host experienced the exact same problem.
So, this is always a good time to reiterate that one should never store passwords in a format that is either clear text or easily reversible. And for goodness sake, lock down your databases to restrict their network access. How does this affect users of Sun IDM? Well, in the past I have written about how the encrypted data in Sun Identity Manager can easily be reversed. I don’t think this is a good way to store data such as passwords. Many other systems, including the majority of other Sun products, use a one-way hash to safely store data.
Sun IDM does let you use different encryption keys rather than the default key. Most customers do not realize this and are using the default encryption key. If you ask me this just muddies the waters. The key is likely still available to someone with enough access to grab the repository database. (It has been a while since I’ve had a look at where the key is even stored. It may actually be stored in the database itself!)
There is absolutely no reason that the encrypted data in Sun IDM needs to be reversible. Actually there is one and I cringe to think what is is… the resource adapter/connector configurations needs to have the resource administrator passwords in a cleartext or reversible form so it can issue updates on the resource. (That is Sun IDM needs to have credentials that it can read to login to a resource to make updates.)
Crap! Is there any way out? I suppose the best you can do is keep the number of cleartext/reversible passwords to a minimum and the user name / password pairs that are clear text should have their access restricted to very limited IP ranges.</rant>
Loading ...
5 Comments
How exactly is one going to provision a new account on a new resource for an existing user, and preserve the password, without having the password stored with reversible encryption?
Or are you suggesting that every time a user receives a new account, they should have to change their password?
That is a good point. If the password isn’t readable in some form it wouldn’t be possible to provision a new account with the same password. I’m still opposed to having all of my 75,000 of my users’ passwords available to be read (directly or derived). If the IDM repo gets nabbed, read, downloaded, whatever then my user’s Exchange accounts, terminal, PeopleSoft accounts etc are all vulnerable. I simply cannot afford the scope of risk involved.
I don’t even use IDM as a login module. I do pass-through authentication to an LDAP server which does store passwords in a safe format. IDM isn’t even part of the login module group so when a user changes his password in IDM the Lighthouse resource password is not updated.
So, yes, what that means is when a user is provisioned into a new resource then they either have to change their password through IDM to make all resource passwords in sync. However, usually that isn’t necessary, we use single-sign on which in turn uses the LDAP resource’s password, which is safely hashed. But that’s not something that happens every day. It’s rare that a user has an account provisioned more than once a year.
We’ve sacrificed the convenience of instant provisioning for security. 95% of the time single sign on hides that inconvenience, but not always.
We’ve had a customer requirement to NOT push the IdM user password to resource accounts and we modified the provisioning workflow to be able to do that. IdM will by default recycle/push user’s password for all resource accounts, if the IdM account exists (thus we are updating and not creating at least from the workflow point of view).
But there is another scenario, where you “need” the password: when you need to distribute the password (to user’s manager, to help desk people, etc.). Sure, this is not really secure, but you user has to login to IdM or Windows somehow… The first password must be known.
In my case when we have a new account where the password must be set to the user can login for the first time, we have an workflow that is run by a manager (or someone with enough admin access to reset a user’s password) that generates a random one. So the password is known only at the time that is is being set at. The original IDM generated password (the one IDM created when the account was provisioned) is never used. We also flag the password as expired so when the user logs in they are forced to change it immediately.
If the manager fails to write down the password or remember what was generated and displayed on the screen before the user object got checked in then he would need to reset the password again to a new random value.
Yes, this works unless you are using Lotus Domino, where the initial password is used for the “ID” file, which contains the private key, and thus must be known. Identity Manager can’t change the Lotus Domino user password without knowing the current password, so the initial must be known.
For all other resources you can reset password if the initial password is forgotten (lost) by the user or the manager.