1

I am currently in the process of designing a registration form for the users to register accounts. The accounts will contain a lot of personal information, so I want to ensure highest possible security. The biggest flaw/problem in the requirement is that username must be first letter of the user followed by his last name, and thereby finding username is an easy task. Due to that I ensure to enforce minimum 12 character passwords that include numbers and capital and lower case letters.

However I was wondering if a user goes on vacation or has a child or takes some long leave and then comes back not remembering the password. What means would there be for him to retrieve/reset his password?

I found issues in any approach I can think of.

Asking security questions doesn't seem like a good choice, since that seems to defeat the purpose of enforcing long passwords. Nowadays many people are not too smart and therefore answers to many security questions can be found easily online by doing some research.

Simply sending reset link or new temporary password to the user's email without doing some authentication also seems pointless because what if the user has a very weak password on their email then the attacker will just try cracking their email instead of their account.

And pretty much any other reset/retrieve password means I can think of seems to defeat the purpose of ensuring a user has long password.

What authentication/reset method would you recommend for this?

Any help will be greatly appreciated.

  • Let me just comment that the majority of your users are going to hate you for requiring a 12 character password and your reset procedure is going to get a LOT of use, so if you make it too complex, people will literally be cursing your name. Are you certain that the system you are building requires such a high level of security? – AJ Henderson Feb 12 '14 at 15:13
  • @AJHenderson It will be storing a lot of sensitive data about the user. So I would rather have users cursing me instead of having all that info being stolen and then company losing face due to my incompetence/negligence. – Quillion Feb 12 '14 at 15:23
  • My experience with 12+ character passwords is that they become less secure. Take for example when my health insurance company required a 12 character password with silly requirements. My password became Fu@kY0uMVP!C# instead of my much more secure and slightly shorter password system that didn't meet there requirements. (And they were not even granting access to anything particularly sensitive with that account.) I'd challenge that 12 characters and complexity requirements isn't going to make people's passwords significantly harder to guess and might actually make them easier. – AJ Henderson Feb 12 '14 at 15:31
  • Fundamentally you either have to assign secure passwords (which would be even more unpopular, to the point people would consider different services) or trust users to choose secure passwords. You can't force a user to choose a secure password. – AJ Henderson Feb 12 '14 at 15:33
  • @AJHenderson without disclosing much information let's say that the information is about health industry patients with some really serious issues. And the company guarantees that such information about them will not be exposed to outside world because it can harm or even ruin their normal lives. So I have to make sure that the patients information stays as secure as it can get. If not 12 character password what do you propose then? – Quillion Feb 12 '14 at 15:35
3

In some very secure scenarios (I don't know if you really need to do this way) I have seen the following configurations:

  1. Send the password by letter (not the securest way, but...).
  2. Send half of the password by phone and the other half by e-mail.
  3. Two different telephone operator spells parts of the temporary key.

I believe the second way is the best, but I believe the best secure/usability way of doing would be "resetting link" + "sms to the mobile number" (something the user have). You can always ask some data regarding the account if you want to add to the security "something the user know". Always, when giving a way to restore the key providing one you must oblige the user to change it the first time he uses it.

I am sure you can make up a solution starting from these points, but, as always, do not overkill if it is not necessary, most of the people tend to think his application needs to be NSA-LIKE-EXTRA-SUPER SECURE".

  • Thanks :) that sounds good considering that the users are also given phones too. I will go with #2, never knew that such a thing even existed. – Quillion Feb 12 '14 at 16:21
  • 1
    To clarify for you and other users, you need to send the temporary generated password half through the phone and half through email or some other communication medium other than phone. Don't think of sending the original password in half pieces because that would mean you will store the password in plaintext or in an encrypted format both of which are not the appropriate procedures. Use a multi-iterated slow hashing function such as bcrypt. – void_in Feb 12 '14 at 16:38
1

Another approach, if your system allows it, is to use rsa keys (not the key-fob-thingies, the public-private kind).

For example, with ssh (secure shell), I have a directory on my laptop containing an "id_rsa" file with a key in it. On work machines, the directory has a id_rsa.pub file in it containing something like

ssh-dss AAAABRHW ... OvfVD9+3+hC+cR1680H5UBe4k= davecb@froggy

The latter is (a little snippet of) my public key, and the work machine can use it to confirm that I have the matching private key in a split second.

If my laptop gets stolen, I tell my admin at work to delete the private key file, and that I'll create a new one after I get a new laptop (;-))

If I leave the company, the admin deletes the public key file and I can't log on any more.

The laptop then becomes important, so I have an encrypted disk on it, and the password to it becomes my "master password", and the only one I have to memorize.

  • This is not a bad idea at all but dealing with keys is hard enough and a PITA for experts so I won't try to use this kind of solution if there are alternatives =). Key management is hard and annoying for users. – kiBytes Feb 12 '14 at 19:35
1

Avoid the problem completely; don't issue passwords at all. Use federated identity. There are a wide variety of identity providers who will manage the user's identity for you and you don't have to worry about password resets (The list given is for the US; Europe has a similar "trust provider", but I don't have a link). Update: I removed one example because a commenter pointed out that it was a bad example. The point remains sound. The Identity Ecosystem Steering Group, the National Strategy for Trusted Identities in Cyberspace, and Kantara are merely three organizations working to make federation more robust.

Obligatory Disclaimer; I am an "at large" delegate to the IDESG

  • 1
    This solution also generates a dependency between your system and your identity provider (if your provider falls then you can provide your service), and maybe one user would prefer login into a service without his "google" knowing where he is loging (just imagine the webpage name being: "ihavecancer.org"). Consider my comment from a very-secure-system architecture. – kiBytes Feb 12 '14 at 15:49
  • 1
    This answer is a bit outdated. Google is phasing out OpenID support. (The replacement has severe technical limitations, which makes it unusable for many sites.) – kasperd Aug 10 '14 at 11:56
  • Thank you @kasperd; I've updated the answer based on your input. Very good point. – Mark C. Wallace Aug 10 '14 at 17:57
  • @kiBytes, those are interesting, but not compelling points. In general the security of an identity provider is going to be superior to the security provided by "ihavecancer" or some other organization for which identity is a sideline. (See Cyvor for evidence). Federation is included in the security architecture at every level of security, including the most secure. – Mark C. Wallace Aug 10 '14 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.