About Passwords (Outdated do not use)
If you want to host your own web service, at some point you'll most likely need to store passwords.
Here are some [insecure, outdated] ideas of keeping the passwords safe:
Don't store passwords at all. Use Google/Facebook/OpenID to log in.1
If you can't hash and salt them2
Don't use PHP's == for comparing passwords. Use === or don't use PHP at all.3
Whatever you do, never send clear-text passwords over the internet. Send passwords from the browser to the server through a SSL (Preferably a TLS 1.2)4 connection. Always remember to keep your password5 up to date!
Do some sort of two-factor authorization. This won't keep the password safe, however other persons won't get access to an account, unless they have the owner's phone or PC.
Using Google to log in
|Most persons have a Google account||Some persons don't use Google for privacy reasons.|
|Can use same 'Project' in Android Apps||One password problem: If someone steals the user's Google account's password, they have the password for your service, too7|
Hash and Salt password
Use argon2id or scrypt instead.
|Very hard to reverse8||Bug-Prone: crypt() in PHP's default settings will truncate the password to 8 characters making it almost trivial to brute-force it.9|
|Lots of code examples. Most forum softwares use this apporach.10|
Here is a quick python code example. user is a tuple containing ('username', 'hash', 'salt')
sha512(sha256(password), sha256(salt))and can be found deep within a binary file within some github repo (where i found the archives in the first place)
A salt is a random integer and is stored in cleartext in the database.
Two factor authorization
This option is not necessarily user-friendly if your server can't send texts, however you can still ask users for an OTP-Password. It's a 6-digit number which changes every 30 seconds and is different from each user. One problem here: You need a private13 key to generate the OTP on the clientside and the same key on serverside to verify.when hacked, the password is pretty much exposed, however you can maybe encrypt it in the database14. (with AES-256-CTR or RSA 4096)15
Never encrypt the user's passwords! If the (private)13 key ever gets leaked, all the passwords can be decrypted!
- Minimum password length: 8 characters
- Maximum password length: none/4 Billion characters
- Password contents: Any combination of printable, non-zero-width, Unicode characters, but at least one number character, one punctuation character. 16
- Make sure password stays same when trim()ing it! (No leading or trailing space characters)
- Ask users to change passwords every 3 months- 17
I'll probably write another article about this subject later.
Author's Annotations (2020)
This might still be a good idea in 2020, but password security has increased on both the client and the server, plus it reduces the risk of having a "single point of failure"
Unlike what the article suggests, you do so using strong key derivation functions like scrypt or argon2id.
Not sure what sparked this reccommendation, I think it had something to do with its weak typing
Update 2020: Support only TLS 1.2 and 1.3 unless you have to support stupidly old clients
I almost certainly meant "certificate" here
This password compromise thing can also happen with password managers. It can always happen without zero-knowledge password proofs which are way beyond my ability to explain concisely or this endnote
This is false for the method shown in this section. sha2 was never meant to hash passwords. Use argon2id or scrypt instead.
The bigger problem is not that its maximum password length is 8 but that it will silently truncate to 8 characters as crypt() uses the password as a DES key to encrypt a block of zeroes. It's just way too quick for password hashing
Pretty sure the following code snippet is based on what a lot of forum software did at the time
No. Use argon2id or scrypt.
Don't use these at all. This also includes sha1.
secret* key. private keys are something else and i should have known that
Security by obscurity is bullshit. If someone has access to the database server they likely also have access to the secret key.
No password composition rules please thank you
Do not ask users to change their passwords unless there is evidence of compromise