1,668 reputation
1922
bio website traveljournal.net
location Netherlands
age
visits member for 3 years, 8 months
seen Jan 31 '13 at 11:06

The more I learn about security, the more I realise I don't know anything about the subject.


Dec
2
comment How to Securely Implement a “Remember Me” Feature?
I think we both have a different approach. data such as computer name can be spoofed, IP addresses can change for many reasons. I create a 256bit random number, store the (hash of) this number in the database and set a cookie with the primary key & random number. Whomever presents the cookie is assumed to be the user associated with the DB record. (also see the answer I linked above).
Nov
30
comment How to Securely Implement a “Remember Me” Feature?
I meant to say that, because the nonce is a password equivalent, instead of the nonce, only the hash of the nonce should be stored in the database. Offcourse you also need to store things like expiration date and/or userId, etc.
Nov
30
comment How to Securely Implement a “Remember Me” Feature?
of interest: Is it safe to store the password hash in a cookie and use it for “remember-me” login?
Nov
30
comment How to Securely Implement a “Remember Me” Feature?
Only the hash of the nonce should be stored in the database.
Nov
29
comment Does shuffling a hashed password increase its security?
As others pointed out, you should use BCrypt or another key derivate function. However, you also seem to be unclear on what a salt is. A salt is defined as a random set of bytes of fixed length; not a static value! please also read: stackoverflow.com/questions/1645161/…
Nov
15
comment PHP crypt() or phpass for storing passwords?
I've been reading through the documentation and concluded this library is totally unsuited for password hashing. Its focus is on encryption. it does feature a crypt_hash method, but only general purpose algorithms (md2, md5, md5-96, sha1, sha1-96, sha256, sha384, and sha512) are available. All in all, I do not see any additional value over PHP's mcrypt extension.
Nov
13
comment Creating Secure PHP Sessions
using the client IP in the session fingerprint is a recipe for malfunctioning sessions. IPs can change, for many legit reasons. think about mobile users, among others.
Nov
5
comment Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
@clayrichardson, then, the idea of hashing password on the client side has been debated over and over again. It will not add anything over that TLS does. If you server gets compromised to the point where the attacker can sniff incoming traffic on the server side, you have lost the battle. The attacker at that point is in control of your server and could just modify the html and/or javascript as he or she pleases. A client side script will not protect against a compromised server.
Nov
5
comment Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
@clayrichardson, Then, the assumptions you make are flawed. If an attacker gains the position to sniff the incoming traffic on you machine, you have already lost. Any value the machine can access, be it from a remote service or local value, will be readable to the attacker. Storing keys on a remote server increases complexity and opens up more attack options, but does not increase security. Because, you need to assume an attacker will be able to read any value, be it remotlely stored keys or email addresses.
Nov
5
comment Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
@clayrichardson, First, you write "or both the public salt and pepper, I am using a long string of characters" A salt is defined as a random set of bytes of fixed length, while a pepper is a (secret) key.
Nov
5
comment Password Hashing add salt + pepper or is salt enough?
I'm not sure in what language your example is, but it would be more clear if it where language agnostic
Nov
4
awarded  Good Question
Nov
2
comment Password Hashing add salt + pepper or is salt enough?
I would suggest bcrypt(hash_mac('sha256', $password, $pepper), $salt)
Nov
2
revised Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
added 113 characters in body
Nov
2
revised Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
added 21 characters in body
Nov
2
revised Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
added 21 characters in body
Nov
2
answered Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
Nov
2
comment Is there a better way to take advantage of current 'approved', 'proven', and memory/cpu-expensive algorithms while using salts and peppers?
read: security.stackexchange.com/questions/21263/…
Nov
2
revised Password Hashing add salt + pepper or is salt enough?
added 96 characters in body
Oct
26
comment How to store salt?
@Polynomial maybe also add a link to stackoverflow.com/questions/1645161/… ?