I work for a bank and security is a major concern. We are currently using a cname on Adobe's collection servers (e.g. stats.bank.com) in order to have Adobe serve first party cookies on the bank.com domain. Our security council now says we shouldn't provide Adobe with a new SSL cert for stats.bank.com because it is too risky and if stats.bank.com is compromised and someone attacks our customers then we our liable due to it being our brand and all the cookie data is exposed as well as leaving customers open to malware attacks. So we have the following options:
Bring reporting in-house
Set up a filtering proxy operating as “stats.bank.com” that front-ends the relevant Adobe service
Go back to Adobe's 3rd Party solution 2o7.net namespace
Use a different 3rd party namespace on adobe's servers (e.g. stats.bk.com)
Here are our thoughts:
1) Too expensive
2) We thought it was a good solution but then the cost came up. It seems like it would be very costly to build that type of infrastructure due to the volume of calls.
3) Adobe's 3rd party namespace blocked too much.
4) Seems to maybe be a solution but still concerned about 3rd party being blocked.
I was wondering if anyone has had to deal with these type of security concerns and what the solution was. Also what are the drawbacks of solution #4 in particular?
There is no personally identifiable or personal information at all in Adobe's tracking cookie.
Before I say anything else, based on what you have said, let me just say that I think your security council is either misinformed about Adobe's tracking cookie or else blowing things unrealistically out of proportion.
The visitor id (s_vi) cookie is just that: a cookie that contains a visitor id value. Here is an example of what the cookie value looks like:
[CS]v1|2A933F6C05079103-6000110EA000D3F3[CE]
The value has nothing to do with a visitor's personal information or data or anything like that. It is a randomly generated value that sticks to the visitor for as long as the cookie persists.
Cookies that are created for any custom coding you do are NOT the same thing
See, this is where I think some people may be confused. Here is a common scenario to explain: member id tracking. A visitor when they first come to your site is anonymous. They login to your site and now your site knows who they are.
From a tracking perspective, it is common to have a prop and/or eVar that reflects this. So on pages/hits where you don't know the visitor, you wouldn't pop anything, or maybe you'd pop some default "anonymous" or "unknown" or "logged out" value. Then when the visitor logs in, you pop the prop/eVar with a value that your site recognizes as a member or account id.
Maybe this id is their email address. Maybe it's a randomly generated value. Maybe it's a username. Point is, it's something to uniquely identify the visitor within your own site's system.
So let's say you write code where upon login, you pop prop1 with the value and then you decide to make use of Adobe's getAndPersist plugin. This plugin basically takes a value and puts it into a cookie and then retrieves the value each time the plugin is called. The idea here is that you only have to do the work to come up with the value from your end one time and then Omniture will persist it from there. This is particularly useful for when you want a value to pop for each page/hit but may not have easy access to replicate or scope the logic to all areas of your site, particularly across subdomains.
So now you have a cookie set by Adobe Analytics code from this. This has nothing to do with the s_vi cookie at all.
Firstly, it is something you explicitly set, even if it is just to get the ball rolling. Secondly, the value is not stored in the s_vi cookie; it is stored in a separate, 1st party cookie.
Even if you have FPC tracking, it is still set in a separate cookie. The actual cookie name depends on what plugin you are using (or using Adobe's s.c_w cookie write function yourself), and also whether or not you are using the combined cookie plugin (in which case it will be put in s_sess or s_pers, depending on what you set the expiration to be)
Now.. if you do have FPC implemented, you can obviously overwrite that cookie with your own value. And you can obviously make that value whatever you want it to be, including something personal to the visitor. But that's not Adobe's doing; that's your doing.
The overall point here is that whether you make the visitor tracking 1st party or 3rd party, that's a completely separate cookie that has nothing to do with personal data.
You may have custom coding that contains personal data and you may put that data into cookies, even using Adobe Analytics functions, but that is not the same thing. It will always be first party cookies (impossible for js to write 3rd party cookies), and the cookies will always be separate.
Nonetheless, the s_vi visitor id may be used to indirectly get personal data
I'm sure the next thing heard will be something along the lines of "But it doesn't matter, it's a unique id for the visitor, and it's in Adobe, and so is this other data, and you can use the visitor id to find the data within Adobe!"
And this is true. However...
Firstly, in order for there be personally identifiable data to be found within Adobe Analytics, you have to explicitly put it there. For example, you have to set stuff like:
s.prop1='jon doe'; // name
s.prop2='4321 1111 1111 1111'; // credit card #
s.prop3='04/2020'; // exp date
s.prop4='123'; // security number
I don't think I should have to tell you that this is a supremely bad idea, but point is, this isn't Adobe collecting that info, it is you doing it. And it's not in the s_vi visitor id cookie, nor can it ever be (again, unless you have fpc imp and decide to explicitly overwrite the cookie with those values..).
So that data, along with the visitor id, goes off to Adobe servers. So there's the next road block: getting access to the data within Adobe. The bad guy would have to have a Adobe Analytics user account under your company, and it would have to have proper permissions to gain access to that data.
And even then, Adobe doesn't actually expose the visitor id value in the reports. So in order to get the data associated with a certain visitor id, you need access to data warehouse, or to be listed as a supported user and request raw hit logs from ClientCare.
I guess the overall point here is that all by itself, that visitor id isn't really the dangerous thing. It's not the personal data, and being able to make use of it to find specific data associated with it would involve acts of extreme foolishness about storing personal data on Adobe servers in the first place, as well as gaining access to said servers/interfaces.
All that aside..
Okay, so maybe you don't care about all of that stuff above. Or maybe none of that convinced your security council to budge. You're moving away from Adobe FPC imp and that's all there is to it. So let's talk about the options you listed and your concerns about them.
Bring reporting in-house
You said this is "too expensive." You know, I gotta be honest here.. this is a bit laughable, coming from a bank! But seriously..
Perhaps you thought it too expensive from a building-from-the-ground-up-from scratch perspective? If this is the case, have you considered options for ones that have already been built, that you can put on your own server and customize or build off of from there?
Webtrends offers this. Frankly, I loathe Webtrends as a tracking solution, but it does offer ability to put it on your own server (last I heard, anyways). Also, Piwik is a really good open source solution.
Filtering proxy
I'm not quite sure what you mean by this. This sounds a lot like FPC tracking.. except having a means to scrub all requests of personal data before it goes to Adobe? Well if that is the case, I'd go back to the point about sending personal data to Adobe in the first place. But okay, maybe you aren't doing that, but want to have an extra measure of precaution just in case; fair enough.
So maybe you setup a service on your end that sends all requests to stats.bank.com and it scrubs stuff and maybe even has a mapping of values (like visitor id). In principle, this isn't really a complex script, so again I have to wonder why cost is an issue, especially coming from a bank.. but whatever..
Sticking with Adobe's 3rd party cookie implementation
If you want to go back to 3rd party cookie tracking using a domain owned by Adobe, instead of using the default 2o7.net domain, I suggest you consider their new(er) 3rd party cookie implementation for Regional Data Collection.
Rolling your own 3rd party cookie implementation
As far as I am aware, Adobe does not offer any kind of service involving you specifying a domain name for them to purchase/own and collect data from as a 3rd party implementation.
The closest service to this is the first party cookie tracking. So, you if you have www.bank.com, normally you'd specify something like stats.bank.com (something on the root domain) and that's FPC tracking.
However, you can tell Adobe to use for example stats.someotherdomain.com (assuming you own and control it) and they can implement FPC tracking for that domain. Then, when you implement tracking on www.bank.com, that effectively becomes 3rd party cookie tracking.
The caveat though is that you still own that domain, so I can only assume that on some level, you will still be liable for it (I'm not a lawyer). However, maybe this will be enough to appease your security council, worth bringing it up to them.
I add that, under the Adobe General Terms of Service, "customer agrees not to collect, process, or store any Sensitive Personal Data using the on-demand or managed services." Hence, if you are collecting any data that can be traced back to an individual -- e.g., email address or phone number -- you are violating the TOS. Therefore, the response to security concerns can be, "Exposing customer PII is a violation of our terms of service and so we don't do it."
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
As I continue to build more and more websites and web applications I am often asked to store user's passwords in a way that they can be retrieved if/when the user has an issue (either to email a forgotten password link, walk them through over the phone, etc.) When I can I fight bitterly against this practice and I do a lot of ‘extra’ programming to make password resets and administrative assistance possible without storing their actual password.
When I can’t fight it (or can’t win) then I always encode the password in some way so that it, at least, isn’t stored as plaintext in the database—though I am aware that if my DB gets hacked it wouldn't take much for the culprit to crack the passwords, so that makes me uncomfortable.
In a perfect world folks would update passwords frequently and not duplicate them across many different sites—unfortunately I know MANY people that have the same work/home/email/bank password, and have even freely given it to me when they need assistance. I don’t want to be the one responsible for their financial demise if my DB security procedures fail for some reason.
Morally and ethically I feel responsible for protecting what can be, for some users, their livelihood even if they are treating it with much less respect.
I am certain that there are many avenues to approach and arguments to be made for salting hashes and different encoding options, but is there a single ‘best practice’ when you have to store them? In almost all cases I am using PHP and MySQL if that makes any difference in the way I should handle the specifics.
Additional Information for Bounty
I want to clarify that I know this is not something you want to have to do and that in most cases refusal to do so is best. I am, however, not looking for a lecture on the merits of taking this approach I am looking for the best steps to take if you do take this approach.
In a note below I made the point that websites geared largely toward the elderly, mentally challenged, or very young can become confusing for people when they are asked to perform a secure password recovery routine. Though we may find it simple and mundane in those cases some users need the extra assistance of either having a service tech help them into the system or having it emailed/displayed directly to them.
In such systems the attrition rate from these demographics could hobble the application if users were not given this level of access assistance, so please answer with such a setup in mind.
Thanks to Everyone
This has been a fun question with lots of debate and I have enjoyed it. In the end I selected an answer that both retains password security (I will not have to keep plain text or recoverable passwords), but also makes it possible for the user base I specified to log into a system without the major drawbacks I have found from normal password recovery.
As always there were about 5 answers that I would like to have marked as correct for different reasons, but I had to choose the best one--all the rest got a +1. Thanks everyone!
Also, thanks to everyone in the Stack community who voted for this question and/or marked it as a favorite. I take hitting 100 up votes as a compliment and hope that this discussion has helped someone else with the same concern that I had.
How about taking another approach or angle at this problem? Ask why the password is required to be in plaintext: if it's so that the user can retrieve the password, then strictly speaking you don't really need to retrieve the password they set (they don't remember what it is anyway), you need to be able to give them a password they can use.
Think about it: if the user needs to retrieve the password, it's because they've forgotten it. In which case a new password is just as good as the old one. But, one of the drawbacks of common password reset mechanisms used today is that the generated passwords produced in a reset operation are generally a bunch of random characters, so they're difficult for the user to simply type in correctly unless they copy-n-paste. That can be a problem for less savvy computer users.
One way around that problem is to provide auto-generated passwords that are more or less natural language text. While natural language strings might not have the entropy that a string of random characters of the same length has, there's nothing that says your auto-generated password needs to have only 8 (or 10 or 12) characters. Get a high-entropy auto-generated passphrase by stringing together several random words (leave a space between them, so they're still recognizable and typeable by anyone who can read). Six random words of varying length are probably easier to type correctly and with confidence than 10 random characters, and they can have a higher entropy as well. For example, the entropy of a 10 character password drawn randomly from uppercase, lowercase, digits and 10 punctuation symbols (for a total of 72 valid symbols) would have an entropy of 61.7 bits. Using a dictionary of 7776 words (as Diceware uses) which could be randomly selected for a six word passphrase, the passphrase would have an entropy of 77.4 bits. See the Diceware FAQ for more info.
a passphrase with about 77 bits of entropy: "admit prose flare table acute flair"
a password with about 74 bits of entropy: "K:&$R^tt~qkD"
I know I'd prefer typing the phrase, and with copy-n-paste, the phrase is no less easy to use that the password either, so no loss there. Of course if your website (or whatever the protected asset is) doesn't need 77 bits of entropy for an auto-generated passphrase, generate fewer words (which I'm sure your users would appreciate).
I understand the arguments that there are password protected assets that really don't have a high level of value, so the breach of a password might not be the end of the world. For example, I probably wouldn't care if 80% of the passwords I use on various websites was breached: all that could happen is a someone spamming or posting under my name for a while. That wouldn't be great, but it's not like they'd be breaking into my bank account. However, given the fact that many people use the same password for their web forum sites as they do for their bank accounts (and probably national security databases), I think it would be best to handle even those 'low-value' passwords as non-recoverable.
Imagine someone has commissioned a large building to be built - a bar, let's say - and the following conversation takes place:
Architect: For a building of this size and capacity, you will need fire exits here, here, and here.
Client: No, that's too complicated and expensive to maintain, I don't want any side doors or back doors.
Architect: Sir, fire exits are not optional, they are required as per the city's fire code.
Client: I'm not paying you to argue. Just do what I asked.
Does the architect then ask how to ethically build this building without fire exits?
In the building and engineering industry, the conversation is most likely to end like this:
Architect: This building cannot be built without fire exits. You can go to any other licensed professional and he will tell you the same thing. I'm leaving now; call me back when you are ready to cooperate.
Computer programming may not be a licensed profession, but people often seem to wonder why our profession doesn't get the same respect as a civil or mechanical engineer - well, look no further. Those professions, when handed garbage (or outright dangerous) requirements, will simply refuse. They know it is not an excuse to say, "well, I did my best, but he insisted, and I've gotta do what he says." They could lose their license for that excuse.
I don't know whether or not you or your clients are part of any publicly-traded company, but storing passwords in any recoverable form would cause you to to fail several different types of security audits. The issue is not how difficult it would be for some "hacker" who got access to your database to recover the passwords. The vast majority of security threats are internal. What you need to protect against is some disgruntled employee walking off with all the passwords and selling them to the highest bidder. Using asymmetrical encryption and storing the private key in a separate database does absolutely nothing to prevent this scenario; there's always going to be someone with access to the private database, and that's a serious security risk.
There is no ethical or responsible way to store passwords in a recoverable form. Period.
You could encrypt the password + a salt with a public key. For logins just check if the stored value equals the value calculated from the user input + salt. If there comes a time, when the password needs to be restored in plaintext, you can decrypt manually or semi-automatically with the private key. The private key may be stored elsewhere and may additionally be encrypted symmetrically (which will need a human interaction to decrypt the password then).
I think this is actually kind of similar to the way the Windows Recovery Agent works.
Passwords are stored encrypted
People can login without decrypting to plaintext
Passwords can be recovered to plaintext, but only with a private key, that can be stored outside the system (in a bank safe, if you want to).
Don't give up. The weapon you can use to convince your clients is non-repudiability. If you can reconstruct user passwords via any mechanism, you have given their clients a legal non-repudiation mechanism and they can repudiate any transaction that depends on that password, because there is no way the supplier can prove that they didn't reconstruct the password and put the transaction through themselves. If passwords are correctly stored as digests rather than ciphertext, this is impossible, ergo either the end-client executed the transaction himself or breached his duty of care w.r.t. the password. In either case that leaves the liability squarely with him. I've worked on cases where that would amount to hundreds of millions of dollars. Not something you want to get wrong.
You can not ethically store passwords for later plaintext retrieval. It's as simple as that. Even Jon Skeet can not ethically store passwords for later plaintext retrieval. If your users can retrieve passwords in plain text somehow or other, then potentially so too can a hacker who finds a security vulnerability in your code. And that's not just one user's password being compromised, but all of them.
If your clients have a problem with that, tell them that storing passwords recoverably is against the law. Here in the UK at any rate, the Data Protection Act 1998 (in particular, Schedule 1, Part II, Paragraph 9) requires data controllers to use the appropriate technical measures to keep personal data secure, taking into account, among other things, the harm that might be caused if the data were compromised -- which might be considerable for users who share passwords among sites. If they still have trouble grokking the fact that it's a problem, point them to some real-world examples, such as this one.
The simplest way to allow users to recover a login is to e-mail them a one-time link that logs them in automatically and takes them straight to a page where they can choose a new password. Create a prototype and show it in action to them.
Here are a couple of blog posts I wrote on the subject:
http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/
Update: we are now starting to see lawsuits and prosecutions against companies that fail to secure their users' passwords properly. Example: LinkedIn slapped with $5 million class action lawsuit; Sony fined £250,000 over PlayStation data hack. If I recall correctly, LinkedIn was actually encrypting its users' passwords, but the encryption it was using was too weak to be effective.
After reading this part:
In a note below I made the point that
websites geared largely toward the
elderly, mentally challenged, or very
young can become confusing for people
when they are asked to perform a
secure password recovery routine.
Though we may find it simple and
mundane in those cases some users need
the extra assistance of either having
a service tech help them into the
system or having it emailed/displayed
directly to them.
In such systems the attrition rate
from these demographics could hobble
the application if users were not
given this level of access assistance,
so please answer with such a setup in
mind.
I'm left wondering if any of these requirements mandate a retrievable password system. For instance:
Aunt Mabel calls up and says "Your internet program isn't working, I don't know my password". "OK" says the customer service drone "let me check a few details and then I'll give you a new password. When you next log in it will ask you if you want to keep that password or change it to something you can remember more easily."
Then the system is set up to know when a password reset has happened and display a "would you like to keep the new password or choose a new one" message.
How is this worse for the less PC-literate than being told their old password? And while the customer service person can get up to mischief, the database itself is much more secure in case it is breached.
Comment what's bad on my suggestion and I'll suggest a solution that actually does what you initially wanted.
Michael Brooks has been rather vocal about CWE-257 - the fact that whatever method you use, you (the administrator) can still recover the password. So how about these options:
Encrypt the password with someone else's public key - some external authority. That way you can't reconstruct it personally, and the user will have to go to that external authority and ask to have their password recovered.
Encrypt the password using a key generated from a second passphrase. Do this encryption client-side and never transmit it in the clear to the server. Then, to recover, do the decryption client-side again by re-generating the key from their input. Admittedly, this approach is basically using a second password, but you can always tell them to write it down, or use the old security-question approach.
I think 1. is the better choice, because it enables you to designate someone within the client's company to hold the private key. Make sure they generate the key themselves, and store it with instructions in a safe etc. You could even add security by electing to only encrypt and supply certain characters from the password to the internal third party so they would have to crack the password to guess it. Supplying these characters to the user, they will probably remember what it was!
There's been a lot of discussion of security concerns for the user in response to this question, but I'd like to add a mentioning of benefits. So far, I've not seen one legitimate benefit mentioned for having a recoverable password stored on the system. Consider this:
Does the user benefit from having their password emailed to them? No. They receive more benefit from a one-time-use password reset link, which would hopefully allow them to choose a password they will remember.
Does the user benefit from having their password displayed on screen? No, for the same reason as above; they should choose a new password.
Does the user benefit from having a support person speak the password to the user? No; again, if the support person deems the user's request for their password as properly authenticated, it's more to the user's benefit to be given a new password and the opportunity to change it. Plus, phone support is more costly than automated password resets, so the company also doesn't benefit.
It seems the only ones that can benefit from recoverable passwords are those with malicious intent or supporters of poor APIs that require third-party password exchange (please don't use said APIs ever!). Perhaps you can win your argument by truthfully stating to your clients that the company gains no benefits and only liabilities by storing recoverable passwords.
Reading between the lines of these types of requests, you'll see that your clients probably don't understand or actually even care at all about how passwords are managed. What they really want is an authentication system that isn't so hard for their users. So in addition to telling them how they don't actually want recoverable passwords, you should offer them ways to make the authentication process less painful, especially if you don't need the heavy security levels of, say, a bank:
Allow the user to use their email address for their user name. I've seen countless cases where the user forgets their user name, but few forget their email address.
Offer OpenID and let a third-party pay for the costs of user forgetfulness.
Ease off on the password restrictions. I'm sure we've all been incredibly annoyed when some web site doesn't allow your preferred password because of useless requirements like "you can't use special characters" or "your password is too long" or "your password must start with a letter." Also, if ease of use is a larger concern than password strength, you could loosen even the non-stupid requirements by allowing shorter passwords or not requiring a mix of character classes. With loosened restrictions, users will be more likely to use a password they won't forget.
Don't expire passwords.
Allow the user to reuse an old password.
Allow the user to choose their own password reset question.
But if you, for some reason (and please tell us the reason) really, really, really need to be able to have a recoverable password, you could shield the user from potentially compromising their other online accounts by giving them a non-password-based authentication system. Because people are already familiar with username/password systems and they are a well-exercised solution, this would be a last resort, but there's surely plenty of creative alternatives to passwords:
Let the user choose a numeric pin, preferably not 4-digit, and preferably only if brute-force attempts are protected against.
Have the user choose a question with a short answer that only they know the answer to, will never change, they will always remember, and they don't mind other people finding out.
Have the user enter a user name and then draw an easy-to-remember shape with sufficient permutations to protect against guessing (see this nifty photo of how the G1 does this for unlocking the phone).
For a children's web site, you could auto-generate a fuzzy creature based on the user name (sort of like an identicon) and ask the user to give the creature a secret name. They can then be prompted to enter the creature's secret name to log in.
Pursuant to the comment I made on the question:
One important point has been very glossed over by nearly everyone... My initial reaction was very similar to #Michael Brooks, till I realized, like #stefanw, that the issue here is broken requirements, but these are what they are.
But then, it occured to me that that might not even be the case! The missing point here, is the unspoken value of the application's assets. Simply speaking, for a low value system, a fully secure authentication mechanism, with all the process involved, would be overkill, and the wrong security choice.
Obviously, for a bank, the "best practices" are a must, and there is no way to ethically violate CWE-257. But it's easy to think of low value systems where it's just not worth it (but a simple password is still required).
It's important to remember, true security expertise is in finding appropriate tradeoffs, NOT in dogmatically spouting the "Best Practices" that anyone can read online.
As such, I suggest another solution:
Depending on the value of the system, and ONLY IF the system is appropriately low-value with no "expensive" asset (the identity itself, included), AND there are valid business requirements that make proper process impossible (or sufficiently difficult/expensive), AND the client is made aware of all the caveats...
Then it could be appropriate to simply allow reversible encryption, with no special hoops to jump through.
I am stopping just short of saying not to bother with encryption at all, because it is very simple/cheap to implement (even considering passible key management), and it DOES provide SOME protection (more than the cost of implementing it). Also, its worth looking at how to provide the user with the original password, whether via email, displaying on the screen, etc.
Since the assumption here is that the value of the stolen password (even in aggregate) is quite low, any of these solutions can be valid.
Since there is a lively discussion going on, actually SEVERAL lively discussions, in the different posts and seperate comment threads, I will add some clarifications, and respond to some of the very good points that have been raised elsewhere here.
To start, I think it's clear to everyone here that allowing the user's original password to be retrieved, is Bad Practice, and generally Not A Good Idea. That is not at all under dispute...
Further, I will emphasize that in many, nay MOST, situations - it's really wrong, even foul, nasty, AND ugly.
However, the crux of the question is around the principle, IS there any situation where it might not be necessary to forbid this, and if so, how to do so in the most correct manner appropriate to the situation.
Now, as #Thomas, #sfussenegger and few others mentioned, the only proper way to answer that question, is to do a thorough risk analysis of any given (or hypothetical) situation, to understand what's at stake, how much it's worth to protect, and what other mitigations are in play to afford that protection.
No, it is NOT a buzzword, this is one of the basic, most important tools for a real-live security professional. Best practices are good up to a point (usually as guidelines for the inexperienced and the hacks), after that point thoughtful risk analysis takes over.
Y'know, it's funny - I always considered myself one of the security fanatics, and somehow I'm on the opposite side of those so-called "Security Experts"... Well, truth is - because I'm a fanatic, and an actual real-life security expert - I do not believe in spouting "Best Practice" dogma (or CWEs) WITHOUT that all-important risk analysis.
"Beware the security zealot who is quick to apply everything in their tool belt without knowing what the actual issue is they are defending against. More security doesn’t necessarily equate to good security."
Risk analysis, and true security fanatics, would point to a smarter, value/risk -based tradeoff, based on risk, potential loss, possible threats, complementary mitigations, etc. Any "Security Expert" that cannot point to sound risk analysis as the basis for their recommendations, or support logical tradeoffs, but would instead prefer to spout dogma and CWEs without even understanding how to perform a risk analysis, are naught but Security Hacks, and their Expertise is not worth the toilet paper they printed it on.
Indeed, that is how we get the ridiculousness that is Airport Security.
But before we talk about the appropriate tradeoffs to make in THIS SITUATION, let's take a look at the apparent risks (apparent, because we don't have all the background information on this situation, we are all hypothesizing - since the question is what hypothetical situation might there be...)
Let's assume a LOW-VALUE system, yet not so trival that it's public access - the system owner wants to prevent casual impersonation, yet "high" security is not as paramount as ease of use. (Yes, it is a legitimate tradeoff to ACCEPT the risk that any proficient script-kiddie can hack the site... Wait, isn't APT in vogue now...?)
Just for example, let's say I'm arranging a simple site for a large family gathering, allowing everyone to brainstorm on where we want to go on our camping trip this year. I'm less worried about some anonymous hacker, or even Cousin Fred squeezing in repeated suggestions to go back to Lake Wantanamanabikiliki, as I am about Aunt Erma not being able to logon when she needs to. Now, Aunt Erma, being a nuclear physicist, isn't very good at remembering passwords, or even with using computers at all... So I want to remove all friction possible for her. Again, I'm NOT worried about hacks, I just dont want silly mistakes of wrong login - I want to know who is coming, and what they want.
Anyway.
So what are our main risks here, if we symmetrically encrypt passwords, instead of using a one-way hash?
Impersonating users? No, I've already accepted that risk, not interesting.
Evil administrator? Well, maybe... But again, I dont care if someone can impersonate another user, INTERNAL or no... and anyway a malicious admin is gonna get your password no matter what - if your admin's gone bad, its game over anyway.
Another issue that's been raised, is the identity is actually shared between several systems. Ah! This is a very interesting risk, that requires a closer look.
Let me start by asserting that it's not the actual identity thats shared, rather the proof, or the authentication credential. Okay, since a shared password will effectively allow me entrance to another system (say, my bank account, or gmail), this is effectively the same identity, so it's just semantics... Except that it's not. Identity is managed seperately by each system, in this scenario (though there might be third party id systems, such as OAuth - still, its seperate from the identity in this system - more on this later).
As such, the core point of risk here, is that the user will willingly input his (same) password into several different systems - and now, I (the admin) or any other hacker of my site will have access to Aunt Erma's passwords for the nuclear missile site.
Hmmm.
Does anything here seem off to you?
It should.
Let's start with the fact that protecting the nuclear missiles system is not my responsibility, I'm just building a frakkin family outing site (for MY family). So whose responsibility IS it? Umm... How about the nuclear missiles system? Duh.
Second, If I wanted to steal someone's password (someone who is known to repeatedly use the same password between secure sites, and not-so-secure ones) - why would I bother hacking your site? Or struggling with your symmetric encryption? Goshdarnitall, I can just put up my own simple website, have users sign up to receive VERY IMPORTANT NEWS about whatever they want... Puffo Presto, I "stole" their passwords.
Yes, user education always does come back to bite us in the hienie, doesn't it?
And there's nothing you can do about that... Even if you WERE to hash their passwords on your site, and do everything else the TSA can think of, you added protection to their password NOT ONE WHIT, if they're going to keep promiscuously sticking their passwords into every site they bump into. Don't EVEN bother trying.
Put another way, You don't own their passwords, so stop trying to act like you do.
So, my Dear Security Experts, as an old lady used to ask for Wendy's, "WHERE's the risk?"
Another few points, in answer to some issues raised above:
CWE is not a law, or regulation, or even a standard. It is a collection of common weaknesses, i.e. the inverse of "Best Practices".
The issue of shared identity is an actual problem, but misunderstood (or misrepresented) by the naysayers here. It is an issue of sharing the identity in and of itself(!), NOT about cracking the passwords on low-value systems. If you're sharing a password between a low-value and a high-value system, the problem is already there!
By the by, the previous point would actually point AGAINST using OAuth and the like for both these low-value systems, and the high-value banking systems.
I know it was just an example, but (sadly) the FBI systems are not really the most secured around. Not quite like your cat's blog's servers, but nor do they surpass some of the more secure banks.
Split knowledge, or dual control, of encryption keys do NOT happen just in the military, in fact PCI-DSS now requires this from basically all merchants, so its not really so far out there anymore (IF the value justifies it).
To all those who are complaining that questions like these are what makes the developer profession look so bad: it is answers like those, that make the security profession look even worse. Again, business-focused risk analysis is what is required, otherwise you make yourself useless. In addition to being wrong.
I guess this is why it's not a good idea to just take a regular developer and drop more security responsibilities on him, without training to think differently, and to look for the correct tradeoffs. No offense, to those of you here, I'm all for it - but more training is in order.
Whew. What a long post...
But to answer your original question, #Shane:
Explain to the customer the proper way to do things.
If he still insists, explain some more, insist, argue. Throw a tantrum, if needed.
Explain the BUSINESS RISK to him. Details are good, figures are better, a live demo is usually best.
IF HE STILL insists, AND presents valid business reasons - it's time for you to do a judgement call:
Is this site low-to-no-value? Is it really a valid business case? Is it good enough for you? Are there no other risks you can consider, that would outweigh valid business reasons? (And of course, is the client NOT a malicious site, but thats duh).
If so, just go right ahead. It's not worth the effort, friction, and lost usage (in this hypothetical situation) to put the necessary process in place. Any other decision (again, in this situation) is a bad tradeoff.
So, bottom line, and an actual answer - encrypt it with a simple symmetrical algorithm, protect the encryption key with strong ACLs and preferably DPAPI or the like, document it and have the client (someone senior enough to make that decision) sign off on it.
How about a halfway house?
Store the passwords with a strong encryption, and don't enable resets.
Instead of resetting passwords, allow sending a one-time password (that has to be changed as soon as the first logon occurs). Let the user then change to whatever password they want (the previous one, if they choose).
You can "sell" this as a secure mechanism for resetting passwords.
The only way to allow a user to retrieve their original password, is to encrypt it with the user's own public key. Only that user can then decrypt their password.
So the steps would be:
User registers on your site (over SSL of course) without yet setting a password. Log them in automatically or provide a temporary password.
You offer to store their public PGP key for future password retrieval.
They upload their public PGP key.
You ask them to set a new password.
They submit their password.
You hash the password using the best password hashing algorithm available (e.g. bcrypt). Use this when validating the next log-in.
You encrypt the password with the public key, and store that separately.
Should the user then ask for their password, you respond with the encrypted (not hashed) password. If the user does not wish to be able to retrieve their password in future (they would only be able to reset it to a service-generated one), steps 3 and 7 can be skipped.
I think the real question you should ask yourself is: 'How can I be better at convincing people?'
I have the same issue. And at the same way I always think that someone hack my system it's not a matter of "if" but of "when".
So, when I must to do a website that need to store a recoverable confidential information, like a credit card or a password, what I do it's:
encrypt with: openssl_encrypt(string $data , string $method , string $password)
PHP manual.
data arg:
the sensitive information (e.g. the user password)
serialize if necessary, e.g. if the information is a array of data like multiple sensitive information
password arg: use a information that only the user know like:
the user license plate
social security number
user phone number
the user mother name
a random string sended by email and/or by sms at register time
method arg:
choose one cipher method, like "aes-256-cbc"
NEVER store the information used in the "password" argument at database (or whatever place in the system)
When necessary to retrive this data just use the "openssl_decrypt()" function and ask the user for the answer. E.g.: "To receive your password answer the question: What's your cellphone number?"
PS 1: never use as a password a data stored in database. If you need to store the user cellphone number, then never use this information to encode the data. Always use a information that only the user know or that it's hard to someone non-relative know.
PS 2: for credit card information, like "one click buying", what I do is use the login password. This password is hashed in database (sha1, md5, etc), but at login time I store the plain-text password in session or in a non-persistent (i.e. at memory) secure cookie. This plain password never stay in database, indeed it's always stay in memory, destroyed at end of section. When the user click at "one click buying" button the system use this password. If the user was logged in with a service like facebook, twitter, etc, then I prompt the password again at buying time (ok, it's not a fully "on click") or then use some data of the service that user used to login (like the facebook id).
Securing credentials is not a binary operation: secure/not secure. Security is all about risk assessment and is measured on a continuum. Security fanatics hate to think this way, but the ugly truth is that nothing is perfectly secure. Hashed passwords with stringent password requirements, DNA samples, and retina scans are more secure but at a cost of development and user experience. Plaintext passwords are far less secure but are cheaper to implement (but should be avoided). At end of the day, it comes down to a cost/benefit analysis of a breach. You implement security based on the value of the data being secured and its time-value.
What is the cost of someone's password getting out into the wild? What is the cost of impersonation in the given system? To the FBI computers, the cost could be enormous. To Bob's one-off five-page website, the cost could be negligible. A professional provides options to their customers and, when it comes to security, lays out the advantages and risks of any implementation. This is doubly so if the client requests something that could put them at risk because of failing to heed industry standards. If a client specifically requests two-way encryption, I would ensure you document your objections but that should not stop you from implementing in the best way you know. At the end of the day, it is the client's money. Yes, you should push for using one-way hashes but to say that is absolutely the only choice and anything else is unethical is utter nonsense.
If you are storing passwords with two-way encryption, security all comes down to key management. Windows provides mechanisms to restrict access to certificates private keys to administrative accounts and with passwords. If you are hosting on other platform's, you would need to see what options you have available on those. As others have suggested, you can use asymmetric encryption.
There is no law (neither the Data Protection Act in the UK) of which I'm aware that states specifically that passwords must be stored using one-way hashes. The only requirement in any of these laws is simply that reasonable steps are taken for security. If access to the database is restricted, even plaintext passwords can qualify legally under such a restriction.
However, this does bring to light one more aspect: legal precedence. If legal precedence suggests that you must use one-way hashes given the industry in which your system is being built, then that is entirely different. That is the ammunition you use to convince your customer. Barring that, the best suggestion to provide a reasonable risk assessment, document your objections and implement the system in the most secure way you can given customer's requirements.
Make the answer to the user's security question a part of the encryption key, and don't store the security question answer as plain text (hash that instead)
I implement multiple-factor authentication systems for a living, so for me it is natural to think that you can either reset or reconstruct the password, while temporarily using one less factor to authenticate the user for just the reset/recreation workflow. Particularly the use of OTPs (one-time passwords) as some of the additional factors, mitigates much of the risk if the time window is short for the suggested workflow. We've implemented software OTP generators for smartphones (that most users already carry with themselves all day) with great success. Before complains of a commercial plug appear, what I'm saying is that we can lower the risks inherent of keeping passwords easily retrievable or resettable when they aren't the only factor used to authenticate an user. I concede that for the password reuse among sites scenarios the situation is still not pretty, as the user will insist to have the original password because he/she wants to open up the other sites too, but you can try to deliver the reconstructed password in the safest possible way (htpps and discreet appearance on the html).
Sorry, but as long as you have some way to decode their password, there's no way it's going to be secure. Fight it bitterly, and if you lose, CYA.
Just came across this interesting and heated discussion.
What surprised me most though was, how little attention was payed to the following basic question:
Q1. What are the actual reasons the user insists on having access to plain text stored password? Why is it of so much value?
The information that users are elder or young does not really answer that question. But how a business decision can be made without proper understanding customer's concern?
Now why it matters?
Because if the real cause of customers' request is the system that is painfully hard to use, then maybe addressing the exact cause would solve the actual problem?
As I don't have this information and cannot speak to those customers, I can only guess: It is about usability, see above.
Another question I have seen asked:
Q2. If user does not remember the password in first place, why does the old password matter?
And here is possible answer.
If you have cat called "miaumiau" and used her name as password but forgot you did, would you prefer to be reminded what it was or rather being sent something like "#zy*RW(ew"?
Another possible reason is that the user considers it a hard work to come up with a new password! So having the old password sent back gives the illusion of saving her from that painful work again.
I am just trying to understand the reason. But whatever the reason is, it is the reason not the cause that has to be addressed.
As user, I want things simple! I don't want to work hard!
If I log in to a news site to read newspapers, I want to type 1111 as password and be through!!!
I know it is insecure but what do I care about someone getting access to my "account"? Yes, he can read the news too!
Does the site store my "private" information?
The news I read today?
Then it is the site's problem, not mine!
Does the site show private information to authenticated user?
Then don't show it in first place!
This is just to demonstrate user's attitude to the problem.
So to summarize, I don't feel it is a problem of how to "securely" store plain text passwords (which we know is impossible) but rather how to address customers actual concern.
Handling lost/forgotten passwords:
Nobody should ever be able to recover passwords.
If users forgot their passwords, they must at least know their user names or email addresses.
Upon request, generate a GUID in the Users table and sent an email containing a link containing the guid as a parameter to the user's email address.
The page behind the link verifies that the parameter guid really exists (probably with some timeout logic), and asks the user for a new password.
If you need to have hotline help users, add some roles to your grants model and allow the hotline role to temporarily login as identified user. Log all such hotline logins. For example, Bugzilla offers such an impersonation feature to admins.
What about emailing the plaintext password upon registration, before getting it encrypted and lost? I've seen a lot of websites do it, and getting that password from the user's email is more secure than leaving it around on your server/comp.
If you can't just reject the requirement to store recoverable passwords, how about this as your counter-argument.
We can either properly hash passwords and build a reset mechanism for the users, or we can remove all personally identifiable information from the system. You can use an email address to set up user preferences, but that's about it. Use a cookie to automatically pull preferences on future visits and throw the data away after a reasonable period.
The one option that is often overlooked with password policy is whether a password is really even needed. If the only thing your password policy does is cause customer service calls, maybe you can get rid of it.
Do the users really need to recover (e.g. be told) what the password they forgot was, or do they simply need to be able to get onto the system? If what they really want is a password to logon, why not have a routine that simply changes the old password (whatever it is) to a new password that the support person can give to the person that lost his password?
I have worked with systems that do exactly this. The support person has no way of knowing what the current password is, but can reset it to a new value. Of course all such resets should be logged somewhere and good practice would be to generate an email to the user telling him that the password has been reset.
Another possibility is to have two simultaneous passwords permitting access to an account. One is the "normal" password that the user manages and the other is like a skeleton/master key that is known by the support staff only and is the same for all users. That way when a user has a problem the support person can login to the account with the master key and help the user change his password to whatever. Needless to say, all logins with the master key should be logged by the system as well. As an extra measure, whenever the master key is used you could validate the support persons credentials as well.
-EDIT- In response to the comments about not having a master key: I agree that it is bad just as I believe it is bad to allow anyone other than the user to have access to the user's account. If you look at the question, the whole premise is that the customer mandated a highly compromised security environment.
A master key need not be as bad as would first seem. I used to work at a defense plant where they perceived the need for the mainframe computer operator to have "special access" on certain occasions. They simply put the special password in a sealed envelope and taped it to the operator's desk. To use the password (which the operator did not know) he had to open the envelope. At each change of shift one of the jobs of the shift supervisor was to see if the envelope had been opened and if so immediately have the password changed (by another department) and the new password was put in a new envelope and the process started all over again. The operator would be questioned as to why he had opened it and the incident would be documented for the record.
While this is not a procedure that I would design, it did work and provided for excellent accountability. Everything was logged and reviewed, plus all the operators had DOD secret clearances and we never had any abuses.
Because of the review and oversight, all the operators knew that if they misused the privilege of opening the envelope they were subject to immediate dismissal and possible criminal prosecution.
So I guess the real answer is if one wants to do things right one hires people they can trust, do background checks and exercise proper management oversight and accountability.
But then again if this poor fellow's client had good management they wouldn't have asked for such a security comprimised solution in the first place, now would they?
From the little that I understand about this subject, I believe that if you are building a website with a signon/password, then you should not even see the plaintext password on your server at all. The password should be hashed, and probably salted, before it even leaves the client.
If you never see the plaintext password, then the question of retrieval doesn't arise.
Also, I gather (from the web) that (allegedly) some algorithms such as MD5 are no longer considered secure. I have no way of judging that myself, but it is something to consider.
open a DB on a standalone server and give an encrypted remote connection to each web server that requires this feature.
it does not have to be a relational DB, it can be a file system with FTP access, using folders and files instead of tables and rows.
give the web servers write-only permissions if you can.
Store the non-retrievable encryption of the password in the site's DB (let's call it "pass-a") like normal people do :)
on each new user (or password change) store a plain copy of the password in the remote DB. use the server's id, the user's ID and "pass-a" as a composite key for this password. you can even use a bi-directional encryption on the password to sleep better at night.
now in order for someone to get both the password and it's context (site id + user id + "pass-a"), he has to:
hack the website's DB to get a ("pass-a", user id ) pair or pairs.
get the website's id from some config file
find and hack into the remote passwords DB.
you can control the accessibility of the password retrieval service (expose it only as a secured web service, allow only certain amount of passwords retrievals per day, do it manually, etc.), and even charge extra for this "special security arrangement".
The passwords retrieval DB server is pretty hidden as it does not serve many functions and can be better secured (you can tailor permissions, processes and services tightly).
all in all, you make the work harder for the hacker. the chance of a security breach on any single server is still the same, but meaningful data (a match of account and password) will be hard to assemble.
Another option you may not have considered is allowing actions via email. It is a bit cumbersome, but I implemented this for a client that needed users "outside" their system to view (read only) certain parts of the system. For example:
Once a user is registered, they have full access (like a regular
website). Registration must include an email.
If data or an action is needed and the user doesn't
remember their password, they can still perform the action by
clicking on a special "email me for permission" button, right next to the regular "submit" button.
The request is then sent out to the email with a hyperlink asking if they want the action to be performed. This is similar to a password reset email link, but instead of resetting the password it performs the one-time action.
The user then clicks "Yes", and it confirms that the data should be shown, or the action should be performed, data revealed, etc.
As you mentioned in the comments, this won't work if the email is compromised, but it does address #joachim 's comment about not wanting to reset the password. Eventually, they would have to use the password reset, but they could do that at a more convenient time, or with assistance of an administrator or friend, as needed.
A twist to this solution would be to send the action request to a third party trusted administrator. This would work best in cases with the elderly, mentally challenged, very young or otherwise confused users. Of course this requires a trusted administrator for these people to support their actions.
Salt-and-hash the user's password as normal. When logging the user in, allow both the user's password (after salting/hashing), but also allow what the user literally entered to match too.
This allows the user to enter their secret password, but also allows them to enter the salted/hashed version of their password, which is what someone would read from the database.
Basically, make the salted/hashed password be also a "plain-text" password.