The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Resetting Passwords

I have an application (with confidential data) with a relatively simple password system. The problem is that due to employee turnover etc... the users forget/loose there password. Currently, the only way to recover the password is for them to send me their files and me to manually create a temporary user name/password.

I don't want to create a hardcoded backdoor into the software for obvious reasons. I would appreciate any ideas about how to get around this problem. TIA.
Luke Miller Send private email
Thursday, April 05, 2007
You can always automate reseting the password and only let a specific role reset someones password.  This way they would only need to send it to you if the person who has the role to reset the password forgets his
Eric Matson Send private email
Thursday, April 05, 2007
Don't store passwords. Store an MD5 or SHA-1 checksum.
Sathyaish Chakravarthy Send private email
Thursday, April 05, 2007
How do you read the data without the password?

Suppose you had a user with no long term memory. You could encrypt the data using Winzip and a client-company-specific key (K1), which you show no one.

Then you give the client user a second file, encrypted with a user specific key (K2) which which contain the key K1. To read the file, the user uses K2 to discover K1 to decrypt. When he loses K2, you only need to send new file with K3 that also contains K1.

Now, replace Winzip with the encryption of your choice, and hide "use K2 to discover K1" step in your software.
Peter Vanderwaart
Thursday, April 05, 2007
That doesn't solve his problem. Regardless of whether the password itself is saved in the application, or the MD5 checksum, Luke still has to change it whenever someone forgets their password.

As a result, I'd recommend that you consider upgrading the application to use local authentication, i.e., if they're on an Active Directory network, let AD authenticate the user. This is "passing the buck" but the fewer passwords the user has to remember, the less likely they'll forget one.

Alternatively, you can code a question-answer mechanism. If they forget the password, they can answer their secret question and either recover their password or be prompted to set a new one.

Ultimately, because this is confidental data, your options are going to be limited by the existing security policies. If integration and password recovery are forbidden such that you have to manually reset their passwords, you're stuck.
Thursday, April 05, 2007
"That doesn't solve his problem."

Sorry, I was initially referring to Sathyaish's answer, but I did get the impression that Luke doesn't want to be involved at all when it comes to recovering passwords.
Thursday, April 05, 2007
Let me amplify my suggestion:

1. On the account creation scren, user enters his user name and desired password.

2. The user name goes into the database intact; the password doesn't. Instead, your source code computes an MD5 or SHA-1 hash of the user's password and sends the hash value to the database.

1. User remembers his user name and password and enters them correctly.

2. Your source code compares the user name input by the user with the user name in your database. Your code then computes the MD-5 or SHA-1 hash of the input password. It compares this value with the earlier hash value in its database. If they are the same, the user is successfully logged on.

1. User clicks on 'I have forgotten my password' button/link/thingy.

2. He goes to a screen where he enters his secret question and secret answer and enters some captcha numbers to validate that it is a human being who has clicked the button or link and not a bot.

3. In the next screen, the user enters and re-enters a new password. An MD-5 or SHA-1 is computed and sent to the database against the user's user name. His password is updated.

The OP is *not* involved.
Sathyaish Chakravarthy Send private email
Thursday, April 05, 2007

Yes, you never mentioned scenario 3 step 1 in your original response, which is the critical aspect. In fact, that step works regardless of whether the actual password is encrypted or not.

For example, if I write the password in plain text to a binary file, the security is almost as good since an evil person is still going to have figure out which string represents the password.
Thursday, April 05, 2007
At the end of the day, isn't that just giving him two passwords: one that easy to forget, and another that has a prompting question.
Peter Vanderwaart
Thursday, April 05, 2007
If you have the user's email address, you can send an email to that address when they say they have forgotten the password.

There are two variants: in one, the email contains a unique "one-off" hyperlink (with a big random number in it, so no-one else can guess it) which must be clicked as part of the password reset process.  This verfies that the user really is who they say they are (or at least that htey really can read mail sent to that address).  This is most secure if the email address used is one that you already have "on file" for the user, rather than one they choose to enter at the time they say they have forgotten their password.  (Although if they no longer use the address you have on file, then the scheme comes unstuck somewhat).

In the other variant, the email simply says "Your password has been changed at your request" after the change.  Not so much security as a chancce for users to complain if after a security breach has happend. (I.e. if you get such an email unexpectedly)

Don't email paswords out.  Hash them (making them comparable but otherwise write-only) as above.
John Rusk Send private email
Thursday, April 05, 2007
Sorry I haven't had time to follow up on the suggestions. Thanks for all input.

TheDavid: Most of my users operate stand-alone and are not on  an Active Directory network.

Sathyaish Chakravarthy: The secret question doesn't really help me out in the scenario of employee turnover. My customers often don't have good employee termination procedures. The new employee has no clue what was the password is or the answer to the secret question. Unless I'm missing something weather I store the password or a Hash of the password, I still have the problem manually telling the user what to use to get-in.

Peter Vanderwaart: The password is stored in an encrypted database. I am the only one with a master key that allows me to open the datafile and see what usernames and passwords are stored in the system. I need to get my head around the concept of using "K2 to discover K1".  One issue would be the following scenario.  My software is installed on two separate systems. How do I prevent someone from using his method (legally on system 1) of resetting the password (illegally) on System 2?

Thanks again to all.
Luke Miller Send private email
Thursday, April 05, 2007
I have to admit that given the particular circumstances, the entire security model seems flawed. Consider these these requirements.

1) No "master" passwords are permitted, each employee must have his own password.

2) If an employee leaves, the terminated employee may forward the existing password to the newly hired employee. (I'm not sure about this one, but it's implied in the original problem description.)

3) If an employee does not know the password, he must request a new one from the software vendor.

The only scenario that I can think of where something like this makes sense is if you've sold an application to an office or a company, and you've authorized one and only one representative at that location to use the system.

If that's the case, that sounds awkward.

Luke, will you please give us a specific real world scenario? I've never seen requirements one and three implemented together and I think there's a piece missing. If we knew what that piece was, we could suggest a better overall method of password recovery.
Thursday, April 05, 2007
"I don't want to create a hardcoded backdoor into the software for obvious reasons."

You already have.  If you can reset a password on their system without knowing an existing password, then you have a backdoor.  It may not be an obvious backdoor, but you are certainly walking through it.  Having a different backdoor wouldn't make security any worse than it already is.

Actually, I wouldn't be surprised if an average cracker could get into your system in under five minutes.  Based on your description of your system, in order to validate passwords it must have the credentials stored internally to access the encrypted database that contains the password.  A practiced user of a debugger can pull the embedded credentials out pretty quickly.

One secure design would use an encryption key derived from the password to encrypt all of the data.  Unfortunately, that would make it so that when the employee lost the password, the data would be permanently inaccessible.

A good design with a "reset" feature might be this:

1.  Before shipping the app, generate a public/private key pair.  Include the public key with the application (we'll call this the "appkey").  Joe cracker could use this appkey to wallpaper his living room and still not be able to use it to crack the app.

2.  When the app is installed, generate a random symmetric encryption key for the data (we'll call this the "datakey".  Derive a key from the initial user password (we'll call this the "empkey").

3.  AES Encrypt all of the data with the datakey.  XOR the datakey with the empkey and store it somewhere.  RSA encrypt the datakey with the appkey and store it in the same place.

4.  During app login, regenerate the empkey from the typed user password.  Decrypt the datakey and access the data.  If the password is guessed incorrectly, the data cannot be deencrypted.

5.  For password changes, decrypt all of the data with the old password and reencrypt with step 2 and 3 over again.

6.  If you need to change a lost password, recover the datakey with your private key.  Then encrypt with the newly assigned password using steps 2 and 3.

Any simpler or more efficient system probably won't work in a stand-alone system where the attacker has physical access to the data files.  In a client-server system, you don't have to get this crazy, because the attacker can't debug the process that does the data access.
JSmith Send private email
Thursday, April 05, 2007
The situation is the system deals with confidential information about residents. The "Master" company may have many different sites that are not "connected" and thus each site operates as a stand-alone system. While I allow many users, typically only one person at that location has access to the system. For example a Social Worker has access to their clients files but the Manager of the Social Worker does not.

The ideal solution would be a program that "unlocks" one and only one installation of the software. In that way they could not take that unlock program to a different site and unlock that sites data. Because I deal with shrink-wrapped software, it would be more of a headache creating customer specific exe's than the occasional manual retrieval of the password.

My ultimate goal is to lower the amount of time that I spend on support by resetting/retrieving passawords. That also that makes my customers happy because they don't have to go through the process and time of me doing the work. Perhaps, this is an insoluable problem. I appreciate your comments.
Luke Miller Send private email
Thursday, April 05, 2007
I don't think it's an insoluable problem, but I do think you need to change the rules of the game a little. The obvious thing that comes to mind is that employees don't exchange passwords but the data itself.

For example, say I'm leaving the company. I decrypt my files, send them to my manager (figuratively speaking) and he encrypts them under his password. When he hires my replacement, he decrypts the files and the new guy takes ownership. Keep in mind that this doesn't solve the entire problem, but it should go a long ways towards reducing the employee turnover related support calls.

In practice, you may want a "transfer ownership" wizard that reminds the users that only one user can have access to the files at a time.

If the person quits and walks off the job without transfering the files, I'd like to think that's the manager's administrative responsibility to get the password, not yours. For example, if I quit and take my security badge with me, my company has the right to sue me for recovery.

As for lost passwords, I gotta admit I like JSmith's thinking, particularly the public key/private key aspect of it. I think there are some potential problems, but I need a bit of time to wrap my head around it.
Friday, April 06, 2007
In most cases in the real world, the solution is a trustworthy person on at the client location, e.g. network and DB access are contolled by IT persons with the power to reset passwords.

Is your app really so unique that that model won't work?
Peter Vanderwaart
Friday, April 06, 2007
A further thought on the notion of a trusted user-company person. Let's call him The Boss.

There are two apps. One is the app you have. The other is a single function app that can change the password. The Boss has the PW for the second. He can change a PW, but that is all. The main app is written so that a new PW can only be used once; the user has to change it.

So The Boss contols access, but does not have access. Of course, the aforementioned cracker with a debugger may still be able to defeat it.
Peter Vanderwaart
Monday, April 09, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz