4

so i have read over a 100 so questions trying to understand how authentication / authorisation / sso / security...etc etc work and i am almost clueless.

My end goal is to create a login system for this client for which am surely gonna use firebase/firestore/some 3rd party logins, but i thought of learning about these stuff anyways.

So back to my question , here is some basic but secure(i guess?) authentication system that i vaguely understood, kindly let me know if it has some vulnerabilities:

----------------------------------------------
1. REGISTRATION: When user opens the app, it will ask for user details(say name, email password, gender). then it will create a rest based post request to some endpoint say https://server/create/ . on the server, the code will receive the entries encrypt the code via some function ECTR, which will work in the following manner:
$> password----->ECTR---> encr_pass+ hash

the encrypted password(aka encr_pass) will be stored in the database while the hash will be returned back to user for automated login.

For next time, the user's device will be able to access any info if it either sends user email +password or the hash . the 2 paths would work like this:

1. if user's device sends hash, then hash will go through a new function on server DCTR along with original encr_pass to generate the original password. this password would again be passed through ECTR and should be generating the original encr_pass and hash. if both of these matches, the login is authorized else a malicious attack. i.e:

$> hash+encr_password(from the server)--->DCTR-->password
$> password---->ECTR---> encr_pass2+ hash2
$> check(encr_pass2 == encr_pass) and check(hash==hash)
most of the times this route will be followed for accessing any resources since hash is stored in the app securely and won't make user login again and again

2. if user's device sends email + password, the password would again go through ECTR function and matched from the server stored password. i.e

$> password--->ECTR--> encr_pass2 + hash
$> check(encr_pass2== encr_pass)

this would happen when the user had manually logged themselves out and trying to log back in

We can make the ECTR and DCTR more secure by using multiple attributes/timestamp/stuff idk for generating encrypted password and hash

---------------------------------------------------

So is it a correct implementation? Does it have any vulnerabilities? I would like to read some case studies/ research papers on this if possible

Comments
  • 2
    The client should only use the hash if the hash is stored on that client. Otherwise send the pw over https and encrypt On the server.

    Once the password is checked and valid, that should be it for that session. The server/backend should then generate a unique session token and return this to the client. From then in, until the token is expired, only the token should be used for authorisation.

    The less you use and send around the pw the smaller the chance someone gets his fingers on it.
    If it’s not happening in an app, do NOT encrypt the pw on the client. The wncryptiom key should ONLY be known by the server/environment and should NEVER be shared with any other system.

    Check out some tutorials for JWT, they usually cover most of this, at least the logic part.
  • 2
    @just8littleBit there are other ways to do it and someone will attack me for this. But this is the basic and most common approach.

    Also, make sure your encryption is a 1-way encryption.
    And the key should be stored in a secure place (often as a env variable), never put it in any properties file. It’s a common thing I see with e.g spring boot noobs.
  • 1
    @just8littleBit thanks. My friend just explained me jwt in great detail. I kind of got it, its like making the password super irrecoverable . Like the password is just being stored fully encrypted and never used otherwise. He would use other details like email, first name last name etc , to create a jwt and instead of password being encrypted/decrypted, its the jwt that gets encrypted/decrypted.

    I like that approach. But the difference between my approach and jwt approach is that in jwt approach mainly anyone can access the user account if the jwt encryption key is leaked. In my approach any account can be breached if my encryption/decryption algorithms got leaked. So yeah jwt wins.

    Any other approach you know about being professionally used? I find these studies on system designing very interesting
  • 0
    @2Large yea, the jwt shouldn’t be generated from other data like email and stuff. It can just be a UUID, no one will ever guess or brute force a UUID.

    Well, Anything you can imagine probably exists, all the way to IP whitelisting and mapping to user accounts. That mainly makes sense on a already secure, private network.
  • 0
    @just8littleBit hold on, so jwt , which is already an encrypted form of data should also be generated from a irrelevant data i.e uuid? Seems redundant to me? For my friends case, he is decrypting the jwt sent by client to get access to various user info, so that he could use those and run the user requested query.
    What would the jwt generated via uuid be useful for? I guess you would have to maintain another table which has the mapping for entries to uuid (or an extra uuid column)
  • 0
    @yowhatthefuck And what happens if someone steals the hash?

    On another note, JWT is a nice and easy to understand option IMO.

    You store input + hash of (input+secret). To verify, check if hash is correct, else reject. You can not fake hash because you don't know secret.

    If hash is hmac sha*, only the signing party will be able to verify, because noone else knows your secret. If you use RSA/asymmetric cryptography, then ANYBODY can verify your secrets, given public key.

    In any case, if you use a strong hash function and secret, nobody but you can sign. And by property of hashing, nobody can find out the secret or make a fake hash
  • 0
    And, whatever you store in JWT is plaintext encoded, so make sure there is no personal identifiable information in JET token. That is why, associate UUID with some account, and use that to authenticate. Now nobody can get any information, even if token is stolen
Add Comment