Stephen, Except using DAPI (which you know the "issues") you are pretty much in a situation where any solution you pick can be reverse engineered by someone with enough access level.
The "next best" way of doing it is to encrypt using a X.509 certificate. Generate a certificate with a private key, register the certificate in the Service Account of the account running your website and only give read write for the PrivateKey to the user running your website or service. Your service/website can then safely encrypt/decrypt passwords on request. You then REALLY want to do the followings: 1. Audit EVERY request to see a password in clear-text by an Admin so in case something does go wrong and someone is using someone else's password there is a clear trace that the person HAD access to the password. I would turn that Audit to the level where you also SIGN every audited line in the database and/or add an encrypted version of the audited message that can again, only be decrypted with your certificate. This would allow you to prove that someone accessed someone elses password and if they try to clear/change their trace you'd have a proof they tried that. 2. Make sure when you register the certificate the key is not exportable (so someone else can't take the key and decrypt your db). 3. Lock the hell out of that machine and any access to the certificate or the password required to use the certificate or the password of the service/web user running your service. You really want to be 99.9999% sure that someone can't make a small test app that loads the cert and decrypts all your password. 4. Leave as many traces of the "Request for clear password by XXX" as possible to make it (close to) impossible for someone to get the passwords without leaving a trace :) 5. Make it clear in the application where the users enter/create passwords that their passwords COULD be exposed or visible to administrators. I would never enter a password in such a scenario or I would use a dumb password (123..9) as I would know it's not secure. I know I'm a bit freaked out by this and frankly, I would NEVER allow this in any of my projects. The dangers and risks are massive (why in the world would anyone ever need to know someone else's password)???? You see every day massive data leaks of passwords from big companies and this is exactly how they happen, because some d** a**** manager decides that "view password" is a valid use case. So again, there should NEVER be a real reason to see the password or someone else :) Maybe propose an alternative (e.g. the way Credit Cards work). If they want to "see" the password to help the users "remember then" (dumb reason) then keep the password hashed+salt so irreversible but keep a "password hint" that you generate automatically and you only include the first and the last character so if my password is "MyCoolPassword123" you'd keep in the "hint" column "M*****3". That should be enough for most scenarios for people to "See" the password and help them remember it. Regards, Corneliu. PS>> If you need some help in convincing managers that exposing passwords is a bad bad bad thing just give me a call and I"m happy to talk to them. Or just ask them how they will deal with an administrator that will "accidentally" expose that the password of your CEO as the name of his mistress? (been there, saw that) On Fri, Mar 22, 2013 at 2:56 PM, Stephen Price <[email protected]>wrote: > Thanks all. I found the CryptoStream class and an example of its use... > Unfortunately that raised the question of "Ok, so now where do we store our > key in the app, so that no one can pull it out and use it, except for the > app." > At which point the answer was, why didn't you research this before > suggesting it? Ok, lets go back to plain text passwords. > I did suggest password hashes, but they are one way and the requirement is > that an Admin can read them. I think I lost. > > Not real impressed with teh ProtectedData class encrypting it per > machine/user. I didn't realise until another developer tried to use it and > the penny dropped. Encrypted egg on my face. doh! Last time I did this > stuff was years ago and I think I was dealing with the Cryptography > namespace. I remember a key and an iv (salt right?) but not sure how we > kept the key safe. > I imagine if the key was to be put into an XML file that is encrypted > (here we go again!!) then the assembly would need to be signed to keep it > safe? > > Good link that Thomas, thanks. Might forward it to the boss so he sees how > simple encryption is. (NOT) > > > On Fri, Mar 22, 2013 at 10:50 AM, Jason Roberts <[email protected]>wrote: > >> Hi, yeah sounds like a key to the encryption / decryption is probably >> what you want assuming there are multiple boxes and/or you want option to >> scale out. I think you can just use the stuff in the Cryptography >> namespace. Just bear in mind that securing the keys will be important. But >> it would be better to use a one way hash (salted) and just let admins reset >> the password, more secure, and possible audit problems?? But don't know the >> specific requirements though. >> ------------------------------ >> From: Stephen Price >> Sent: 22/03/2013 10:06 AM >> >> To: ozDotNet >> Subject: Encryption >> >> Hey all, >> >> http://msdn.microsoft.com/en-us/library/ms229741.aspx >> >> "...which allows you to encrypt data using information from the current >> user account or computer. " >> >> I'm using ProtectedData to encrypt and decrypt passwords so they can be >> stored in database encrypted, but they want to be able to see what the >> password is for administrators. It all works great except when a user logs >> in (using a custom principal, not the user who did the encryption.. ie the >> Admin) and it doesn't work as the user is different, or the machine is >> different. >> >> I'm looking for a way to encrypt and decrypt at an app level rather than >> user/machine level. Don't mind if keys are involved. Anyone done this and >> is there a framework class somewhere for that? >> >> cheers, >> Stephen >> > >
