1,643 reputation
1922
bio website traveljournal.net
location Netherlands
age
visits member for 3 years, 6 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.


Jan
10
comment How safe is “trust this computer” option for websites?
A server side expiration option also allows for a 'forget me everywhere' button, thereby allowing the user to expire cookies for all previously trusted computers.
Jan
10
comment Is it possible to make an xss with only html tags
@Polynomial, yeah, I noticed two other answers mention it, but only after commenting. I was about to delete the comment, but now you already noticed.
Jan
10
comment Is it possible to make an xss with only html tags
onmouseover requires user interaction, onerror fires on pageload.
Dec
30
comment E-mail can be made to appear like it came from a big organization?
SPF is not broadly implemented
Dec
24
comment How can encrypted traffic bypass the Great Firewall of China when it is being blocked?
related: security.stackexchange.com/q/3317/2113
Dec
13
comment Does including decorative HTTP headers into server reply pose extra security risk?
not a security issue, but extra headers do consume (some) extra bandwidth.
Dec
10
comment What are the disadvantages of single sign-on authentication?
I'm pretty sure, the avarage user would not use a better password for a single sign-on solution. Most don't care and wouldn't even know the difference; to them it is just another password box they need to fill in.
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
2
comment Password Hashing add salt + pepper or is salt enough?
I would suggest bcrypt(hash_mac('sha256', $password, $pepper), $salt)
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/…