Server-side hashing, url sanitation, redirecting logged in users to home

[k-hendricks]

This is what I'm planning to work on today. I will also be working on https implementation and server symmetric encryption, but I probably won't get those finished.

[k-hendricks]

Oh I am also going to do try and handle Neitzsche-sanitation. He seems to have appeared, like the first pustule of plague, on our homepage.

[taa176]

I'm still wondering about the server encryption. Almost all references I find suggest using different salts for each user and hashing server-side. Is encryption a good enough substitute? Is there a good reference that talks about this?

Actually, maybe we should just do both.

To your other point (note the spelling): This is a Nietzsche website. You're welcome.

[k-hendricks]

Yeah storing the key in somewhere more secure than the server is difficult. It would just be nice because it would protect more than just the passwords. I'm not proposing that server side encryption be used to protect plaintext passwords. Remember they would still be hashed clientside with the username

• constant random string as salt. This is only to prevent the server from accepting requests if someone gets access to the hashed password and the server is directly comparing that to the hash on file. I can't really think of a situation where an attacker could dump the entire database and decrypt it, but not be able to just modify the server code to accept "opensesame" as a password directly in plaintext. Still its better to be safe so I will add server side hashing in the normal way with random salts.

On Sun, Sep 15, 2019, 08:58 taa176 notifications@github.com wrote:

I'm still wondering about the server encryption. Almost all references I find suggest using different salts for each user and hashing server-side. Is encryption a good enough substitute? Is there a good reference that talks about this?

There are still some things I have questions about, including how we will secure the private key. Hashing each password also has the benefit that you have to crack each password individually if you want to get any information. W/ encryption, if the attacker has the key, they'll have access to the entire database.

To your other point (note the spelling): This is a Nietzsche website. You're welcome.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/taa176/web/issues/6?email_source=notifications&email_token=AEKJW6JEG6ZW4YOA43GKN6LQJZLQ3A5CNFSM4IW25UUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6XTTYQ#issuecomment-531577314, or mute the thread https://github.com/notifications/unsubscribe-auth/AEKJW6OXTWINLI3OAH3ZEXTQJZLQ3ANCNFSM4IW25UUA .

[taa176]

Okay, sounds good to me. Facebook should hire us as consultants

https://newsroom.fb.com/news/2019/03/keeping-passwords-secure/

[k-hendricks]

Lol "don't worry it was just poor people". These guys are terrible. "Facebook Lite is a version of Facebook predominantly used by people in regions with lower connectivity."

On Sun, Sep 15, 2019, 09:30 taa176 notifications@github.com wrote:

Okay, sounds good to me. Facebook should hire us as consultants

https://newsroom.fb.com/news/2019/03/keeping-passwords-secure/

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/taa176/web/issues/6?email_source=notifications&email_token=AEKJW6OCW4DGVPS47TPDYMDQJZPJJA5CNFSM4IW25UUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6XUFMI#issuecomment-531579569, or mute the thread https://github.com/notifications/unsubscribe-auth/AEKJW6J6QXE7GA3JPM4XWFLQJZPJJANCNFSM4IW25UUA .