

Ask HN: Is this pseudocode client side login algorithm secure? - alhenaadams

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.<p>essentially you create a huge solution space problem only the right username/password combo can solve in reasonable time.<p>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.
======
dalke
I have read this several times and still don't understand the point of what
you want to achieve. Some loud alarm bells ring - it looks like you're making
a brand new hash algorithm. Don't every do that. Use one of the existing ones.
For one, in the one you outlines, anagrams give the same hash value.

If 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?

~~~
anonymouz
I completely concur with your post, I have been scratching my head for some
minutes now trying to figure out what the OP wants to do.

> 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.

------
anonymouz
I'm really at loss at what problem you're trying to solve here, what your
algorithm is doing, and where/for how long the mentioned files are stored and
who's involved in the transaction? Who's holding which files? For how long?

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.

~~~
alhenaadams
I am trying let people login to a site hosted on/as a github pages site. A
client side only site with authentication. A single javascript file the can
add this feature to my projects. i'm trying to create a homomorphic
authentication system where no server ever stores any data about the user.
your data never leaves your client. user data gets stored within the client
itself custom encrypted for each user by their username, password, and hash.

If I change the additions in my algorithm to multiplications I can avoid some
issues others have pointed out.

~~~
anonymouz
Multiplication instead of addition in the hash will give you the same
problems.

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.

