-1

I've just made the prototype for my new secure password-based authentication method, but there are several doubts about chosen size of password and alphabet. The method is simple - user calculates the checksum of his password (sum of positions of these symbols in different random permutations of the chosen alphabet. So, for each symbol its position in corresponding permutation should be found and added to the sum. The actual value of checksum is a remainder of division of this sum by the total number of all symbols in the chosen alphabet).

Actually, it goes this way (size of password equals 16, size of alphabet equals 20):

  1. Server sends just generated random permutations of alphabet - one particular permutation for each letter of user password. Let these permutations be called as G1, G2, ... G16;
  2. User calculates the value of checksum as = (G1(L1) + G2(L2) + G3(L3) + ... + G16(L16)) % 20 (here: L1...L16 - separate letters of the password);
  3. Server receives the checksum and compares with its own calculation;
  4. The whole procedure can be repeated to decrease the possibility of accidental guessing.

Actually, I believe it's a reliable method (Or not?), but what about the lengths? I think 16 such letters for password - it's not enough to resist brute-force guessing for this method. Am I right? Would 20 be enough? Alphabet is another big question. Cryptography is not my cup of tea, so, please excuse me for such a cumbersome description. Here is the simple demo of it: secure password-based authentication method. I hope it's much more informative.

AlexAnd
  • 1
  • 1
  • 2
    Unfortunately, I too am not an expert in cryptography, so I cannot answer whether your scheme is secure or not, but the general consensus is to not roll your own security scheme, see http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own – Matthew Jan 24 '15 at 17:53
  • 2
    Please don't roll your own. Use existing password hashes designed and vetted by cryptographers, like [bcrypt](https://en.wikipedia.org/wiki/Bcrypt) or [scrypt](https://en.wikipedia.org/wiki/Scrypt), or if you *absolutely must*, use a zero-knowledge PAKE protocol like [SRP](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol). Do not implement any of these yourself; use a preexisting off-the-shelf implementation. – Stephen Touset Jan 24 '15 at 19:15
  • Why aren't you hashing? – schroeder Jan 25 '15 at 20:16
  • I just try to make an algorithm which can be easily computed by human. I thought it's the suitable one. Although, I'm not certain about its cryptographic strength. So, now I'm diving into related mathematics, but any sensible advise would be appreciated. – AlexAnd Jan 26 '15 at 12:22

1 Answers1

1

I just tried you demo, and what worries me is that at the end the authentication is made using one single character, therefore the whole authentication system relies only on one single character guessed right, to be compared to 8+ characters for passwords with a minimum length enforced to 8, and the size of the hash in case a hash is sent to the server (32 hexa characters in case of md5 for instance). You mention the idea to repeat the entire procedure, but even if you repeat it two or three times the authentication will still only rely on 2 or 3 characters.

The main point here to note is that when an attacker will try to bruteforce your system, he will most likely not try to guess a password and not bother with your system: he will just flood your server with random hashes until one turns out to be valid. One chance over 20 currently to win at each try (better than any lottery!), a bit more if you repeat the process, but still nothing to do with, say, the billions of billions of billions of possibilities offered by a cryptographic hash which annihilates the chances to find a correct hash by bruteforce in less than a few centuries.

WhiteWinterWolf
  • 19,142
  • 4
  • 59
  • 107
  • I agree with almost everything, but the only one thing - as I always thought, long hash is needed to block the possible brute-force attack only when they leaked, so, when an attacker is able to guess them on his own system(s). I just can't imagine how somebody would attack my system if I imply an increment of the minimal number of positive results for each failed attempt (just for instance). I don't even say about timers and delays. Am I wrong? – AlexAnd Jan 24 '15 at 19:46
  • A secure system is only as strong as its weakest point. When your authentication form sends the password hash to the server, you must ensure that the hash offers at the very least as much combinations as the password itself, otherwise it will wreck all strength from the password. When security admin has to deal with a web app relying on an untrusted authentication scheme, he will not use the method you describe (they are just good enough to prevent spam and turn away automated bots) but simply replace the authentication page with a stronger one (reverse proxy, sso, ...). – WhiteWinterWolf Jan 25 '15 at 16:09
  • You're right, but ... OK, let's just suppose, that the method implies 16 results (or more), that should be sent to the server at once for the authentication check (suppose it's easy for user to gather them). My actual question is: whether this simpliest method is cryptographically secure? I just can't find it anywhere. Actually, I think it should be either canonical one or just too weak. Thank you for not bumping me as all others with the same "don't roll your own". I don't see how to imply any of standard methods here. – AlexAnd Jan 25 '15 at 18:06
  • You have to click on 16 or more "symbols" (to remain abstract, could be characters, colors, pictures, ...): this in itself constitutes a password. The valid password to send to the server changes each time, is valid only once and deduced from a secret only known by the server and the client but never shared during the authentication process: this makes this password system to become an OTP, One Time Password. Did you dig in all the OTP related literature? I know there are a lot of different and original concepts there, some may inspire you in improving your authentication system? – WhiteWinterWolf Jan 27 '15 at 21:17
  • It's possible there is something I'm looking for. It's strange, but didn't even think about it. Thank you. Now I'm just trying to look at the method just as if it was a plain hash function and analyse it somehow. – AlexAnd Jan 29 '15 at 16:21