I've got a page with a login system where you type your username and password, the salted hash gets pulled down from the database depending on the username ...

SELECT hash FROM db WHERE username = ?
bind theSubmittedUsername

The potential password is then run through a method to verify if its the right one or not.

Is it conceivably possible to get rid of the username input box so only a password would be required to authenticate the user.

SELECT hash FROM db WHERE .... 

I was thinking perhaps 2 letters from each password could be stored in the database in plain text then i could do something along the lines of ...

SELECT hash, username FROM db WHERE 2letters = ?
bind the2LettersOfPass

then run any hashes returned from the database through the comparison function, is there a better way that is more secure?

  • Why would you want to do this? – PwdRsch Sep 10 '14 at 21:34
  • To cut down the amount of typing required – Crizly Sep 10 '14 at 21:37
  • 3
    If you just want to save users time typing I would recommend saving a persistent authentication cookie to their browser after login with normal username/password. Otherwise if you have low security requirements you should consider only requiring usernames to authenticate. Using passwords in this manner doesn't seem wise. – PwdRsch Sep 10 '14 at 21:44
  • The other ways to solve this with out materially effecting security would be to allow autocomplete on the username field so the browser usually pre-fills it. Or store a long term cookie with the users username and pre-fill the username field with the value from that cookie if present. Cookie should be marked as "secure" and "HttpOnly", consider disabling autofill on the password field. – David Waters Sep 11 '14 at 4:07

That's really a very bad idea. Consider two people using a similar password where the two letters match. How will you be able to distinguish between the both of them? Not.

We use username and password to identify someone. If you just need to protect the application you might as well share a password since you don't seem to care about accountability.

  • Its a salted hash, 2 similar passwords would give 2 very different hashes, if i did it the way i described it'd just take ages to verify each hash to get to the right one – Crizly Sep 10 '14 at 21:36
  • 2
    Ages of users are still prone to collisions. Ages of passwords defeat the purpose as well since you still don't have accountability. Also by disclosing two letters of the password you are weakining the password's strength, even in its hashed form. – Lucas Kauffman Sep 10 '14 at 21:39
  • I think he meant that it would take "a long time" to verify each hash to find the right one. But the problem is two identical passwords; you have no way of distinguishing between two users if you only uniquely identify based on passwords. – Stephen Touset Sep 10 '14 at 22:20

No, this is not possible.

  • A salt protects you from collisions in the hashed password, not collisions in the plain text password. If two users have the same password then you'll have two password/salt/hash combinations which pass your validation and you won't be able to distinguish between the users.

  • The problems you're having with how to look the users up is because you have no primary key. You can't use a password as a primary key unless you actively reject duplicate passwords (and in which case you've just told an attacker someone's password).

  • A username can be a source of entropy. "Find any user with a password of test" is more likely to return a result than "find me user abc with password test". An opportunistic attacker could probably find an account by trying common passwords.

Use a persistent login cookie to achieve your objective instead.

  • 1
    These are three excellent reasons why this is a terrible, terrible idea. // cc: @Crizly – Xander Sep 10 '14 at 22:13

The traditional way to avoid the user having to type in a user name is to include "remember me" functionality where the user name is persisted in a manner that is associated with the browser, e.g. an encrypted cookie or a cookie containing a durable token (say, 30 days) that the server can use to infer the user name.

Some of the replies here are going to argue that user name provides additional entropy. You could deal with this objection by requiring a password that is twice as long. Of course this sort of cancels out the benefit of reduced typing since now the user has to type in just as much stuff, with the added difficulty of the input being masked.

If you insist on going with a username-free design, there are a number of common features that depend on user name that you're going to have to figure out how to deal with in other ways:

  1. Authentication lockout. If the user hasn't provided a user name or a correct password, where do you store the lockout counter?

  2. Password recovery. What does the user type into the "Forgotten password" workflow that allows him to identify himself? (I guess this problem is no more difficult to solve than a "forgot user name" feature).

  3. User ID collision detection. What message would you display instead of "That user name is already in use by another user" ?? I'm thinking a message like "congrats you just guessed someone else's password!" would not pass security review.

  4. Auditability and customer support. What string does your application emit into audit logs, debug logs, or other tables or files, that can be recognized by a developer or support technician supporting the customer? Surely not the password. Also, what does the customer provide over the phone when asking for support, if not the user name?

You will also have issues if you are attempting to achieve PCI-DSS compliance (e.g. if you need to accept credit cards), FDIC compliance (if you work with banks), or ISO compliance (if you work with government agencies).

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.