ChatGPT解决这个技术问题 Extra ChatGPT

How should I ethically approach user password storage for later plaintext retrieval?

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.

I think he knows that it is not good. He's still looking for the best solution under the stated requirements.
At the end of the day all you will be doing is carefully implementing an avoidable vulnerability.
@Michael Brooks - I want you to know that I am absolutely in agreement with CWE-257 and would love to just quote that verbatim each and every time I am asked to make passwords recoverable as plaintext. However, in reality, clients and users are rarely interested in NIST regulations and just want me to do it anyway. 90% of the time I can convince them otherwise but in that 10% of time when I can't I am trying to determine the best course of action--in those cases CWE-257 is ashes in my hand (unfortunately).
@AviD: The "low value" of the system has absolutely no bearing on this issue because people reuse their passwords. Why can't people understand this simple fact? If you crack the passwords on some "low value" system, you will likely have several valid passwords for other "high value" systems.
Another point has also been glossed over, which I just mentioned in the comment stream to my answer: How do you know that the person asking for these requirements is trustworthy? What if the "usability" excuse is just a façade masking a real intent to steal the passwords at some point in the future? Your naiveté may have just cost customers and shareholders millions. How many times must security experts repeat this before it finally sinks in: The most common and most serious security threats are always INTERNAL.

w
wallyk

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.


+1 for passphrases, which presently seem to offer the best balance of password strength and user recall.
Also you can make a full sentence e.g. The is . The green cat is jumping wildly. have lists for the categories. with 1024 choices for each you have 40 bits of entropy.
+1 for considering password reuse as a critical issue for avoiding it
"Think about it - if the user needs to retrieve the password, it's because they've forgotten it" -- not necessarily true! I often want to get my password because I'm on the laptop, and I KNOW my machine back home has my password stored, or it's written down somewhere safe, and I don't want to break that by getting issued with a new one.
The highest-scoring question on the new IT Security SE site deals with the validity of this entropy calculation. (Well, technically, it deals with the xkcd that @Pieter linked.)
A
Aaronaught

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.


@Aaronaught - I think that is a fair and valid point, but let me twist that on you. You are working on a project for a company as an employee and your boss says 'this is a requirement of our system' (for whatever reason). Do you walk off the job full of righteous indignation? I know that there is an obligation when I am in full control to be responsible--but if a company chooses to risk failure of audits or liability then is it my duty to sacrifice my job to prove a point, or do I seek the BEST and SAFEST way to do what they say? Just playing devil's advocate..
I am not a lawyer, but consider this. If your supervisor orders you to do something against the interests of the company, such as by exposing them to an easily avoided liability, is it your job to obey or to politely refuse? Yes, they're your boss, but they have a boss of their own, even if it's the investors. If you don't go over their heads, whose head is going to roll when your security hole is exploited? Just something to consider.
Developers are always trying to say how our jobs are so much harder than others because we get garbage requirements that change all the time. Well, this is a perfect example of why; our profession desperately needs a backbone. Our profession desperately needs to be able to say "no, this is not an acceptable requirement, this is not something that I can develop in good faith, you may be my client/employer but I have professional responsibilities toward your customers and the public, and if you want this done then you'll have to look elsewhere."
@sfussenegger: You don't need to know the background. It's unacceptable. You're assuming that the client is 100% trustworthy - what if he's asking for this requirement specifically so he can make off with the passwords later? Security is one of the few items in development that are carved in stone. There are some things you just don't do, and storing recoverable passwords is ten of them.
OK, let's do a risk assessment, right here and now. "If you store passwords in a recoverable form, you are creating a non-trivial risk of passwords being stolen. It is also likely that at least some users will use the same passwords for their e-mail and bank accounts. If passwords are stolen and bank accounts are drained, it will probably make headlines, no one will ever do business with you again, and you will likely be sued out of existence." Can we cut the crap now? The fact that you brought the word "Nazis" into this clearly shows that you have no sense of reason.
s
stefanw

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


-1 passwords should never be "encrypted" It is a violation of CWE-257 cwe.mitre.org/data/definitions/257.html
1. The question stated that the password should be recoverable to plaintext, so this is a requirement. 2. I'm using asymmetric encryption here and not symmetric encryption. The key to decrypt is not necessary for daily operations and can be kept in a bank safe. The argumentation in the link is valid, but does not apply to this situation.
True, but could you agree that given the requirements this is the most responsible way of doing it? You can hit me all day with your CWE-257, it's not going to change the interesting problem of safely storing and working with credentials and being able to recovering them to their original form if required.
Windows Recovery Agent is also a poor example here, as it deals with actual encryption, not password management. An encryption key is not the same as a password; the rules and practices surrounding each are completely different. Encryption and authentication are not the same. Encryption is for privacy - a key is used to protect data. Authentication is for identity, where the key is the data (it is one factor in the authentication process). So I repeat, encryption and authentication are not the same. You cannot validly apply the principles of one to the other.
+1 Where's the point in obsessively insisting on CWE-257? It's a weakness (CWE), not a vulnerability (CVE). Comparing recoverable passwords with buffer overflows is comparing apples and oranges. Simply make sure the client understands the problem (let him sign something that says so - otherwise he might not remember anything if in question) and go ahead. Additionally, required security measures depend on the value of the system and potential risk of an attack. If a successful attacker could only cancel some newsletter subscriptions, there's no reason to argue about any issues.
u
user207421

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.


Webserver logs don't count in a court? Or in this case they would be assumed as faked as well?
@Vinko Vrsalovic, Web server logs SHOULDNT count in court, in order to do so you need to prove non-repudiation, proof of authenticity, chain of evidence, etc etc. which webserver logs are clearly not.
Exactly. The supplier has to prove that only the client could have performed that transaction. A web server log doesn't do that.
Not all passwords are actually needed for "transactions", so to speak. Say the website is for developing a webpage bookmarking list. In this case the limit of liability (which is usually called out in the T&C's when registering to the website) is zero, because there is no financial transaction. If the website has no actions affecting others then at most, data is lost to the hacked user. The company is protected by the T&C's.
@Sablefoste On that website. If the user uses the same password elsewhere you're creating a risk of leaking his private credentials. If you never engage in the practice you can't cause the problem.
j
jammycakes

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.


@jimmycakes - This is a good thing to do on a low security system, but if you are storing any data of high value then you have to assume that the persons email is already compromised and that sending them a direct login link compromises your system. +1 for answering my question with a feasible alternative, but pointing out a flaw in the logic as a whole. I don't want Payppal sending a direct login link EVER. It may sound paranoid but I always assume my email account is corrupt--it keeps me honest. ;)
Absolutely -- I'd expect my bank to at the very least give me a phone call and verify my identity before letting me reset (not recover) my password. What I've outlined here is the absolute minimum standard of password security that I would expect from any website, anywhere.
Ignoring the bank or paypal who wouldn't have the restriction you set anyway; If you assume their email is compromised, how is any online method possible? If you email a generated password, how is that any more secure?
I'm not talking about obtaining a single individual's password, I'm talking about obtaining multiple passwords from a database. If a system stores passwords recoverably to plain text, a hacker can potentially write a script to extract all the passwords from your database.
I'm wondering about sending link/password in email, going through network in plain form through unknown network nodes...
M
Mr. Boy

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.


@john - I think that is a perfectly viable solution. Prepare to get flamed over internal threats though! You know, if I were to do this with an intermediate password reset (tech sets the password manually as a temporary mesaure and tells Mabel to type 1234 as her password) then it would probably work well on a system not containing important data. If it were a high security environment though we then have a problem where cust service can set the CEO's password to 1234 and log in directly. There is no perfect solution but this one works in a lot of instances. (+1)
I just noticed this answer. @Shane, I don't understand why you predicted flaming over "internal threats." The ability to change a password is not a notable weakness; the problem is the ability to discover a password that's likely to be used for other services - her e-mail, her bank, her online shopping sites that have her CC information stored. That weakness is not manifested here; if Bob resets Mabel's password and tells it to her over the phone, that doesn't give him access to any of her other accounts. I would, however, force rather than "suggest" a password reset on login.
@Aaronaught - I do see your point, but what I am thinking of are times where even the customer service folks are locked out of certain areas of a system (such as payroll, accounting, etc) and allowing them to directly set a password is a security issue in and of itself. I do see your point though that the type of system I asked this question about differs largely from an internal accounting system. We could probably have an entirely different discussion about proprietary internal systems and password security therein.
@Shane: Then the question makes even less sense. I assumed that you wanted someone to read them a password over the phone. If you wanted to e-mail users their passwords through some automated self-service system then you might as well dispense with the password entirely because it's being "protected" with something much weaker. Maybe you need to be a lot more specific about exactly what kind of usability scenarios you're trying to support. Maybe that analysis will subsequently show you that recoverable passwords are not even necessary.
The code provided by the support person doesn't literally have to be the new password. It can just be a one-time code which unlocks the password-reset function.
P
Phil H

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!


And, of course, you could use any secret-splitting technique to require multiple someones from your company for decryption. But none of that fulfills the original requirements of being able to mail a user their passwords or have some run-off-the-mill first-level phone supporter walk them through logging in.
J
Jacob

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.


I responded to the comments here, down in my response, since it was quite lengthy - i think its important to review the analysis and the discussion of issues raised. stackoverflow.com/questions/2283937/…
Does the user benefit from having their password displayed on screen? In my opinion - definitely yes! Every time I get obscure password from internet provided, I thank Apple I can make it visible so I don't have to retype it 100 times in pain. I can imagine how disable person would feel.
Why is displaying an obscure password better than letting you choose a new password you can remember?
@Jacob: More entropy?
A
AviD

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.


Passwords shared between your low-value site with "no" expensive assets and Facebook/GMail/your bank are an expensive asset, even on low-value sites.
I think the problem here is that the above-mentioned groups of users tend to use the same password for all applications from many different security levels (from banking to recipe blogs). So the question is, if it is the responsibility of the developer to protect the users even from themselves. I would definitely say, yes!
I'm sorry, but identity itself is a high value asset, period. No exceptions, no excuses. No matter how small and inconsequential you think your site is. And a shared password is the identity if it lets the hacker into your users' Facebook accounts, Gmail accounts, bank accounts, etc. It's nothing whatsoever to do with semantics, but it's everything to do with consequences. Just ask anyone who was affected by a hacker attack such as this one: theregister.co.uk/2009/08/24/4chan_pwns_christians
@Jacob, in what world would your client be sued because Erma's accounts on other systems have been compromised? Even given gross negligence on the part of your client (which is NOT a given, as I elaborated), and BESIDES the fact that there is NO WAY to prove that the other system was breached because of yours, there is no possible legal standing to claim any form of damages from one system on the other system. It would be thrown out of court with prejudice, and finding the plaintiff in contempt. However, Erma might be at fault for violating numerous Terms of Service...
@Jacob, that is so very wrong. Just because the password happens to be the same (which would clearly violate your ToS and their security policy), their is no legal standing to corrolate the two. Thats even BESIDES the fact that PROVING it would be darn near impossible. As an aside, I will also point out that there is NO LAW that requires a random company to not have lax security practices, unless specific regulations are relevant. And on top of that, the passwords ARE encrypted (!), so the laxness is far from a forgone conclusion.
O
Oded

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.


You know, I have used that in several situations (usually this is my middle ground), but I have had folks tell me that the end user is just not going to get the interaction and that support needs to be able to 'tell them their password' due to circumstances in that business' model. I agree though that when possible this is preferable.
You can alway tell your client about the risk of their DB falling into evil hands and them getting the publicity of stolen passwords... There are plenty of examples around.
Ask them to sign off on the "design", with an added clause that they can't sue you if what you warned them about does indeed happen... At least then you cover yourself.
-1 passwords should never be "encrypted" It is a violation of CWE-257 cwe.mitre.org/data/definitions/257.html
@Michael Brooks: There's no need to downvote and copy-paste the same comment over and over; we're all aware that it's bad practice. Shane stated that he lacks leverage in the matter, though, and so the next best thing(s) are being proposed.
N
Nicholas Shanks

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.


Most users don't have a PGP key (I still don't have one; after 20 years in the industry, I've never felt the need), and it's not a frictionless process obtaining one. Further, a private key is really just a proxy for an actual password anyway. It's a password for a password, in other words; it's turtles all the way down.
@RobertHarvey The goal is to allow a user to retrieve their password without allowing the site employees or any hackers to get at it. By requiring that retrieval process happen on the user's own computer, you enforce this. There may well be alternatives to PGP which could achieve the same. Turtles all the way down it may be (perhaps some elephants along the way), but I don't see any other way. For the general population (not likely to be targeted individually) having your passwords on a bit of paper, and being unable to retrieve them from the service, would be more secure than we are currently
I like it because it forces everyone to have a PGP public key, which is, strangely, a very ethical thing to do.
you could just generate one and give it to the user.
@RobertHarvey You may be right that this is "not a frictionless process", but it could be an extra service for power users, which regular users can ignore it. As for the argument about a PK being "a password for a password", remember that it can in theory be so for many passwords; you might use different passwords for different services, and encrypt them all using the same key. Then the PK will be more valuable than just a single password. Perhaps it is in an abstract way comparable to a password manager(?). It's not immediately clear to me what consequences this may have though...
z
z-boss

I think the real question you should ask yourself is: 'How can I be better at convincing people?'


@sneg - Well, I am a furly convincing guy, but sometimes it's a boss and sometimes a customer so I don't always have the leverage I need to convince them one way or another. I will practice in the mirror some more though.. ;)
To be convincing you don't really need any leverage other than your competence and communication skill. If you know a better way of doing something but people don't listen... Think about it.
@z-boss - Apparently you haven't worked with/for some of the hard heads that I have had the pleasure of working with. Sometimes it doesn't matter if your tongue is plated in gold and you could reprogram Google Chrome in a day (which arguably might actually make it useful) they still won't budge.
a
atiquratik

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.

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

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

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"

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


T
Thomas

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.


Your answer completely ignores that passwords are reused across multiple sites/services, which is central to this topic and the very reason why recoverable passwords are considered a serious weakness. A security professional does not delegate security decisions to the non-technical client; a professional knows that his responsibilities extend beyond the paying client and does not offer options with high risk and zero reward. -1 for a rant heavy on rhetoric and extremely light on facts - and for not even really answering the question.
Again, you are completely overlooking risk assessment. To use your argument, you cannot stop at just 1-way hashes. You must ALSO include complexity requirements, password lengths, password reuse restrictions and so on. Arguing that users will use dumb passwords or reuse passwords is not a sufficient business justification if the system is irrelevant and frankly, I did answer the question. The short answer: push for using a std implementation, document your objections if you are overruled and move on.
And again you repeat the canard that none of this matters for a low-value system! The value of a user's password has nothing to do with the value of a user's account on your system. It's a secret, and one that you must always keep. I wish I could give another -1 for the comment demonstrating that you still don't understand the issues here.
Risk assessment is the core issue. Password reuse is only one potential issue in a much larger set of issues. Why not require fobs? Why not require that the person drive to your office to login? Without a reasonable assessment of the risks, there is no way to answer these questions. In your world, everything is a risk so every system requires FBI level login security. That is simply not how the real world works.
The only thing that is clear here is that your entire argument is nothing more than a Slippery Slope fallacy and that you are trying to steamroll readers with buzzwords like "risk assessment" in order to cover up that fact. Rest assured whatever system the "FBI" uses is going to be far more secure than a bcrypt hash and a minimum password length. If requiring industry-standard authentication systems makes me a "security fanatic", then I guess I am a fanatic; personally, it pains me to know that there are people out there willing to sacrifice MY security for money. That is unethical.
R
Rob Fonseca-Ensor

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)


The user may answer differently the question too. Some questions beg longer answers that are easy to rephrase later.
Security questions are a bad idea. How do you get your mom to change her maiden name once the information is breached? Also see Peter Gutmann's Engineering Security.
M
Monoman

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


Temporarily removing a factor from a multiple-factor authentication system is indeed a much more secure means to reset a password than the infuriating "secret question" systems seen on so many sites. But as for storing passwords in a recoverable format, I'm not sure how it helps, unless you're somehow using the second factor to encrypt or obfuscate the first, and I'm not sure how that's possible with something like a SecurID. Can you explain?
@Aaronaught What I've said is, if you are 'required' to have recoverable passwords, the inherent risk is lower if it is not the only authentication factor, and it is also easier for the end user, if that workflows reuses factors that he/she already possesses and has current access to, than trying to remember probably also forgotten 'secret answers' or using time-limited links or temporary passwords, both sent through unsafe channels (unless you are using S-MIME with client certificates, or PGP, both incurring costs specially on management of correct association and expiration/substitution)
I suppose all of that's true, but the risk of public compromise is minimal to begin with; the more serious issue with recoverable passwords is internal security and potentially allowing a disgruntled employee to walk off with the e-mail passwords of thousands of customers, or a crooked CEO to sell it to phishers and spammers. Two-factor authentication is great at combating identity theft and password guessing but doesn't really bring much to the table as far as keeping the actual password database safe.
S
Steven Sudit

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.


D
Dmitri Zaitsev

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.


d
devio

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.


GUID is a bad idea, not nearly random enough and easy to bruteforce. there are other issues with this, see stackoverflow.com/questions/664673/…
c
casraf

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.


I wouldn't assume that email is more secure than any other system. Though this does take the legal concern out of my hands there is still the issue of someone losing/deleting their email and now I am back to square one.
Provide both a password reset and email the plaintext password. I think that's the most you can do on the subject, without keeping a copy of the password yourself.
This is an absolutely horrible idea. It's both ineffective (many users actually delete emails after reading) and worse than what you're trying to protect against (since e-mail is unencrypted by default and passes through untrustworthy networks). Better to suggest to the user that they make a note of the password themselves, at least sending oneself an email the information never goes farther than the email server, not across the entire Internet!
a
anopres

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.


As long as you have an e-mail address associated with a password, and that password is recoverable, you've potentially leaked the password for that e-mail address due to password reuse. That's actually the primary concern here. There's really no other personally-identifiable information that matters.
You completely missed my point. If you don't really need a password, don't collect one. Developers often get stuck in the "that's just the way we do it" mode of thinking. Sometimes it helps to throw out pre-conceived notions.
J
JonnyBoats

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?


A master key would be awfully risky, the support staff would have access to every account -- and once you give that key out to a user, they then have the master key and access to everything.
A master key is a terrible idea, since if someone discovers it (or has it disclosed to them by accident), they can exploit it. As per-account password reset mechanism is far preferable.
I am curious, I thought Linux by default had a super user account with root level access? Isn't that a "master key" to access all the files on the system?
@JonnyBoats Yes, it is. That's why modern Unixes like Mac OS X disable the root account.
@NicholasShanks: Disable the root account, or disable interactive login on the root account? There's still a lot of code running with unlimited permissions.
J
Jeremy C

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.


A
Amir Arad

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.


If the app server can access it, so can anyone with access to the app server (be it a hacker or malicious insider). This offers zero additional security.
The added security here is that the application server's DB does not hold passwords (so a second hack is needed - to the passwords DB), and the passwords DB can protected better against irregular activity, as you control the accessibility of the password retrieval service. so you can detect bulk data retrievals, change the retrieval SSH key on a weekly basis, or even not allow automatic pass retrieval, and do it all manually. This solution also fits any other internal encryption scheme (like the public+private keys, salt, etc.) for the passwords DB.
S
Sablefoste

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.


E
Eliott

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.


Why do you think it is necessary to compare what the user entered directly to the hashed password stored in the database? What kind of functionality does that give you? Also, when doing this it is hugely important to apply constant-time comparison function between the user entered password and the hashed password from the database. Otherwise, it is almost trivially possible to determine the hashed password based on timing differences.
@ArtjomB. The question asks how to protect the user's password while also allowing customer support (CS) to talk/email a user through entering their forgotten password. By making the hashed version be useable as a plain-text password, CS can read it out and have the user use it in lieu of their forgotten password. CS can also use it to log-in as the user and help them through a task. This also allows users who are comfortable with automated forgotten-password systems to be protected, as the password they enter and use is hashed.
I see. I haven't read the question in its entirety. The use of a constant-time comparison is still necessary to prevent trivial breakage of the whole system.