Web Auth and Security

Question 1

How to store passwords?

Answer 1

Never store direct password.
* Hashing - A hash function accepts an input and maps it to a smaller value. Hashes are one way (It’s very hard to reverse a hash). Most popular hashing algos are MD5, SHA-1, SHA-256
* Salting - Adding a random bit of information (salt) to all passwords, making common passwords more secure.

Question 2

What are the best practices for web sign-ins

Answer 2

• Always use HTTPS to ensure passwords are not plain text on the internet.
• Avoid logging POST bodies and GET parameters as they may be sensitive.
• Use a session token to authenticate subsequent requests.

Question 3

What is a session token?

Answer 3

• A generated token that represents a particular sign-in session for a user.
• The token should be randomly generated, and long enough to infeasible brute force.
• Putting the session token in a cookie to be verified on future requests.
• Session tokens should be equivalent to passwords in their handling.
• Tokens should have expirations, often they are regenerated until there has been a long period of inactivity.

Question 4

What are Cookies and how are they used for authentication?

Answer 4

• Cookies are text that a browser associated with a given key, and sends it back to the server whenever a request is made.
• The server may include a set cookie header, which indicates the value to store and metadata on expiration/security.
• Cookies are always shared in requests to the same domain (Can be more limited if needed), so by storing session tokens, we can validate all future requests for the session duration.

Question 5

What is a JSON Web Token?

Answer 5

• Alternative to a plain session token, JWTs are not random date, but explicitly encodes the users access.
• It may have the usernmae/ID and explicit permissions for the login session.
• Requires additional work to verify a JWT is valid.

Question 6

How can a server verify a JWT

Answer 6

A JWT can be verified in one of two ways.
1. Sign the payload - Attaching a signature from a private key held by the service verifies its legitimacy.
2. Encrypt the payload - Encrypt so that only the service can read it. Requires distributing a decryption key to the various services at play.

https://www.reddit.com/r/linuxquestions/comments/rnp5ww/how_can_i_finally_understand_public_and_private/

Question 7

What are private/public keys?

Answer 7

1. First you generate two keys a private (Kept only to yourself) and a public (a key you can communicate with anyone to know this key identifies who you are)
2. The keys have a methematical relationship, what one encrypts, the other decrypts.
3. The public key can be shared, while the private key should only ever be held by the owner and used to decrypt messages encrypted by their public key.

Question 8

How does an SSL (HTTPS) handshake work?

Answer 8

1. The website sends their public key to the user/client.
2. The client generated a random password, encrypting it with the websites public key, sending it back to the server.
3. Further communication is ecrypted using the shared password.

Question 9

How does authentication via a Public Key work?

Answer 9

1. Specify that a public key should have some sort of access (For exmaple, GIT or SSH)
2. When connecting, send public key to the server. Server determins if it matches a public key with permissions, and starts the handshake.
3. Server generates a password, encrypts with public key and sends it back.
4. Decrypte the password, use it to encrypt further communication.

Question 10

How does payload signing work?

Answer 10

1. Take the message you want to send, hash it and encrypt it with your private key.
2. Send the message and hash together with is like “Want proof its me? decrypt with my public key”
3. If the server decryptes and creates the same hash of the message and they are equal, they know it was from you (The person with the private key, matching their declared public key)