0
$\begingroup$

I am building a website more or less for me and myself and wanted to try a scheme where there is no username; just a password to login.

So I take a user registration and use PHP's password_hash() and save that to the DB. password_hash() returns a string encompassing algorithm, salt & hash.

The issue is that as I don't have a username for finding the hash from the DB.

To work around this it is possible to:

  1. get and check every password in the database for the correct one (but I don't like this workaround);
  2. generate a second hash over the password (unsalted this time), this hash is small and fast such as adler32 and use it to find the real hash(es) for verification checking.

How easy would it a be for an attacker, if my db got leaked, to find out the password from the hashes?

Is there a better algorithm than adler32, that has maybe more collisions or has a smaller output?

What if I force my users to a 40+ char password?

Improve this question
$\endgroup$
4
  • $\begingroup$ adler32 is a checksum algorithm it is not hash for any cryptographic hash function. Also, note that if they do not remember they must remember their e-mail or any other information that is used to identify during registration. $\endgroup$
    – kelalaka
    Commented Jun 30 at 10:52
  • $\begingroup$ @kelalaka my project would have just have them create new accounts $\endgroup$
    – guest
    Commented Jun 30 at 10:54
  • $\begingroup$ I've significantly shortened your question, and removed the sudden "username" from the second option, as that was the part you were explicitly trying to avoid and it seemed incongruous with the rest of the question. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 30 at 12:29
  • 1
    $\begingroup$ @MaartenBodewes thank you. I was, quite literally, unable to formulate it so well $\endgroup$
    – guest
    Commented Jun 30 at 12:43

1 Answer 1

Reset to default
1
$\begingroup$

A fast hash is by definition easier to attack. A modified dictionary attack (a dictionary with symbols inserted etc.) would easily filter out the passwords that would generate the adler32 and then the second, slow hash can be used to validate if the correct password was used.

It would be hard(er) to use a rainbow table attack though as rainbow table attacks won't work on hashes that have a lot of collisions, and the actual password hash is protected by a salt. A rainbow table would not be very efficient for a small user base anyway.

If you'd use a smaller hash output then there the chance of a collision indeed becomes higher. That would mean that you'd have to reject specific passwords as they would hash to the same account. Normally in a hash table you'd simply look for the correct key that generated the hash. But in your case that would be the password itself, and the whole idea of a password hash is to not store the password itself. There are some ugly workarounds possible of course, but let's not over-complicate things. This idea doesn't really remove the major drawback of being able to filter out possible password matches.

You could indeed use a randomly generated "secret" rather than a password. In that case you might just store SHA-256 hashes over that secret, as nobody is going to guess a 40 character secret anyway. Nobody is going to remember it either of course; you'd be restricted to using a password manager basically.

There may be an Oracle attached to your solution. Basically the hash acts like a user ID. However, if the system returns a different error or takes less time returning an "unknown password" if the adler hash cannot be found then an online adversary can use your scheme to quickly filter out incorrect passwords as well.

In general: there is a good reason why this kind of scheme is not common. There are simply too many issues. Don't forget that the password would still identify the user in your scheme, so your user doesn't gain any anonymity. If you want that there are several anonymous / identity-free PAKE- and ZK-schemes out there. Those do require a higher proficiency in cryptography though.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ It took me much more time to write down this answer than to come up with all the issues with the scheme. This is why "don't invent your own" is such a meme within the cryptographic community. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 30 at 13:11
  • $\begingroup$ I wouldnt in a normal professional setting, as user are quite hard to educate about the goofy stuff that could be done. As this is a project of mine, I worked on my aproach and am now splitting the password in two parts. One of the parts will be the "username". That'll fix it. Thank you for your time and expertise $\endgroup$
    – guest
    Commented Jun 30 at 14:07
  • $\begingroup$ Yeah, that's reasonable, given that the password is unique anyway. Still leaves you with one input field at least. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 30 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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