Ask HN: Is this pseudocode client side login algorithm secure?
on new user login:
1)generate a random assignment of prime numbers to permissable characters for a new username/password entry and save it as tempTransform.json, save a copy to rawTransforms.json
2)translate username and password to integers using this list, then add them together and save the resulting integer in userHashes.html
3)add the username, password, and userHash and use the sum to encrypt tempTransform.json, then save it as userHashTransform.json;
4)on subsequent user login, take entered username and passwords add them together using all available rawTransforms looking for userHashTransform collisions. decrypt with sum if username, password, and user hash. if alphabets match, authenticate user.
essentially you create a huge solution space problem only the right username/password combo can solve in reasonable time.
i bet that samsonite, I'm way off, but please tell me how to protect user data with a client side only js/css3/html5/bootstrap site? I want an open source drop in js login script we can all verifiably agree is secure so this doesn't happen to me.
6 comments
[ 2.4 ms ] story [ 17.7 ms ] threadIf you want everything to be client-side then you're out of luck. The client controls everything, and tweaks of the Javascript, to invert the logic of the password check, will break everything. You could have the password be the decryption key for the rest of the code to run, but I don't understand the goal.
What's the threat model? Who's is going to try to do what?
> For one, in the one you outlines, anagrams give the same hash value
It's even worse: Only the number of occurences of a given character matter for the value of the hash. So "correct horsebatterystaple" gives the same as "aabcceeeehlooprrrrsstttty". Permutation of letters does not change the output at all, making a brute force attack extremely viable.
I can only guess that the rawTransforms.json and userHashTransform.json are kept by some server, and the user is then authenticated against this? If so, why not use some standard method? (bcrypt, scrypt?)
In any case, creating your own hash function or making up your own secure authentication procedure should generally be considered a big red flag. Chances are, whatever authentication issue you're trying to solve, there is already a standard way for it: Stick to it.
Remember: It's trivial to create a security scheme you cannot break, but very hard to create one that somebody else cannot break.
If I change the additions in my algorithm to multiplications I can avoid some issues others have pointed out.
I'm not familiar with Github pages, but it seems one cannot store anything on the server-side, it's just HTML+JS. If nothing is sent to any server, there does not seem anything to authenticate or protect from anyone.