martinstoeckli

906 reputation

139

bio	website	martinstoeckli.ch
	location	Switzerland
	age	40
visits	member for	1 year, 3 months
	seen	10 mins ago
stats	profile views	122

I belong to the lucky people, who can combine job and hobby, in my case writing software. Coming from the Delphi world, i'm working more and more with CSharp and use PHP for my spare time project, an internet lost-and-found office.

	906 reputation	bio	website	martinstoeckli.ch	visits	member for	1 year, 3 months
139 badges		location	Switzerland		seen	10 mins ago

summary answers questions tags badges favorites bounties reputation activity

122 Actions

suggestions reviews revisions comments badges posts accepts all

Feb 8	revised	*How can I constrain or limit 3rd party Javascript (.js) files that can DOS my site?** added 104 characters in body
Feb 8	answered	*How can I constrain or limit 3rd party Javascript (.js) files that can DOS my site?**
Jan 23	comment	is it easier to get the original password if you have multiple hashes of it? @sujeesh - Actually the OP knows that one can brute-force the weakest hash value. I think his question was, whether combining the different hashes may give an advantage.
Jan 23	comment	is it easier to get the original password if you have multiple hashes of it? I think the OP's scenarion was more, that a user reused the same password on several sites, and the attacker got access to those different hashes (not calculating several hashes on the same CPU). But your first part answers the question i think.
Jan 11	comment	In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - The stored salt is plain text, it is not hashed itself. You can just look for the signature `$2y$10$` and the next 22 characters are the used salt, you can reuse it to calculate the new hash. In contrast to `password_hash()`, the function `password_verify()` does not create it's own salt, it uses the extracted salt from the stored hash-value.
Jan 11	comment	In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - What i tried to explain is, that the salt is part of the generated hash-value. The `password_verify()` gets the entered password and the stored hash-value from the database, and can extract the salt from the stored hash-value. Then it calculates the hash of the entered password, with the same salt it used to calculate the stored hash-value. Now it can compare the hash-values, because they are based on the same salt.
Jan 11	comment	In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - The part `2y` is the algorithm BCrypt, the part `11` is the cost factor and the next 22 characters are the salt. The rest after the salt is the actual hash-value. The whole string can be stored in the database, and when you verify the password these parameters are extracted from the stored hash-value to hash the entered password. Have a look at the bottom of this page for an example.
Jan 11	comment	In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - Yes, each password gets it's own salt, therefore equal passwords get different hash-values. To check if the password matches the hash-value, you use the function `password_verify()` instead, here you can find an example.
Jan 8	comment	What exploit types do I need to protect against in PHP? @FrankE - Using sleep to delay a login won't help. You can start say 1000 login attempts, each one will wait but they wait "together". To get a delay you have to store the last login attempt time in a database, and block all following attempts in a certain period.
Dec 21	answered	If someone asks to borrow your phone to make a call, what could they do?
Dec 20	revised	How can I explain SQL injection without technical jargon? Adapted to changed title
Dec 20	comment	How can I explain SQL injection without technical jargon? Simple, understandable, brilliant!
Dec 20	revised	How can I explain SQL injection without technical jargon? Not recommended to make page public.
Dec 20	answered	How can I explain SQL injection without technical jargon?
Dec 12	answered	Gold Standard for password hashing
Dec 12	comment	Password Salts and Randomness @Polynomial - Absolutely agree with you (though it is a very big IF), only meant that if somebody wants to add a secret, he should not "misuse" the salt.
Dec 12	comment	Password Salts and Randomness @Polynomial - Exactly, the pepper provides the same advantage, as making the salt secret. As long as the attacker has only access to the database (SQL-injection) it is an advantage, if he has control over the server, he can get the pepper or has access to the hidden salts. I only wanted to propose, that we let the salt doing it's job, and don't mix it up with the job of the pepper.
Dec 12	comment	Password Salts and Randomness @Nakaan - As Polynominal said, a salt is not meant to be secret, it fullfills it's purpose to thwart rainbow tables even when known. If you want to add a secret, then combine your password with a pepper additionally to the salt.
Dec 6	comment	cookies “secure” flag @ted - If you define a redirect, the server will answer with a HTTP response status code 301 and does not send any cookies or other content. The server does not send back a cookie, your application tells the browser to create one. In PHP you have to call `setcookie()` or `session_start()`, but in case of a redirect your application will never be started. Cookies are a client side thing.
Dec 6	revised	cookies “secure” flag Tried to make it better understandable.