Talk:Password Storage Cheat Sheet - Revision history

Lbriner at 11:22, 16 November 2015

2015-11-16T11:22:38Z

Adedov at 13:28, 13 November 2015

2015-11-13T13:28:57Z

James Sanderson: Start discussion on credential data included in hashes

2014-07-02T22:25:36Z

Start discussion on credential data included in hashes

Arran Schlosberg: possible DoS with PBKDF2 etc.

2014-02-19T09:06:13Z

possible DoS with PBKDF2 etc.

Jmanico: removing 2012 discussion

2013-09-17T02:22:06Z

removing 2012 discussion

Jmanico at 02:19, 17 September 2013

2013-09-17T02:19:43Z

Jmanico at 02:19, 17 September 2013

2013-09-17T02:19:28Z

Jmanico at 02:18, 17 September 2013

2013-09-17T02:18:48Z

Manuel Aude Morales: reviving discussion on peppers ("secret salts")

2013-03-19T01:39:57Z

reviving discussion on peppers ("secret salts")

Manuel Aude Morales: formatting

2013-03-19T01:34:02Z

formatting

← Older revision		Revision as of 11:22, 16 November 2015
Line 1:		Line 1:
		+	1) It is not clear that the slow hash is preferred over an HMAC storage format and why you would choose HMAC over slow hash.
		+	2) Ideally, some mention should be made of the bcrypt-style storage format where cost, salt and hash are all stored together, which permits a very easy way to increase cost over time without breaking existing hashes. I am unsure of the scrypt format and I don't think PBKDF2 stores it this way by default. The format should be recommended since it then allows the contingency work mentioned further down.
		+
		+	--[[User:Lbriner\|Luke Briner]] ([[User talk:LBriner\|talk]]) 11:22, 16 November 2015 (UTC)
		+	----
		+
	Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's [http://openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/ slides] from Yac 2012 (unfortunately, there is no English video).		Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's [http://openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/ slides] from Yac 2012 (unfortunately, there is no English video).

← Older revision		Revision as of 13:28, 13 November 2015
Line 1:		Line 1:
		+	Suggest take in account planned/actual scale of a system to protect. Bigger systems probably need more layers of defense, like additional authN server + secret salt (local parameters) + traditional KDF for storage. See Solar Designer's [http://openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/ slides] from Yac 2012 (unfortunately, there is no English video).
		+
		+	--[[User:Adedov\|Adedov]] ([[User talk:Adedov\|talk]]) 07:28, 13 November 2015 (CST)
		+	----
		+
	Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?		Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?

← Older revision		Revision as of 22:25, 2 July 2014
Line 20:		Line 20:
	--[[User:Manuel Aude Morales\|Manuel Aude Morales]] , 18 March 2013 (UTC)		--[[User:Manuel Aude Morales\|Manuel Aude Morales]] , 18 March 2013 (UTC)
	----		----
		+
		+	Is there any utility in incuding credential data in the input to the protective function? I don't understand what it adds, given a sufficiently random salt. [[User:James Sanderson\|James Sanderson]] ([[User talk:James Sanderson\|talk]]) 17:25, 2 July 2014 (CDT)

← Older revision		Revision as of 09:06, 19 February 2014
Line 1:		Line 1:
		+	Increasing work factor with PBKDF2 etc. can result in an application-level DoS vector. This can be abused in a passively distributed manner by inducing CSRF authentication attempts and hence standard CSRF mitigation should be applied to authentication systems too. Mitigating automated DoS attacks on this vector can be achieved with CAPTCHA but which users should be required to complete a CAPTCHA isn't as simple; linking it to a session and failed authentication attempts will not work as an automated attack can simply request a new session token. Perhaps it should be linked to IP or subnet?
		+
		+	--[[User:Arran Schlosberg\|Arran Schlosberg]] , 19 Feb 2014 (UTC)
		+	----
		+
	Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/		Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

← Older revision		Revision as of 02:22, 17 September 2013
Line 15:		Line 15:
	--[[User:Manuel Aude Morales\|Manuel Aude Morales]] , 18 March 2013 (UTC)		--[[User:Manuel Aude Morales\|Manuel Aude Morales]] , 18 March 2013 (UTC)
	----		----
−
−
−	I think, for this cheat-sheet, we should begin by identifying and describing the minimum acceptable mechanisms for password storage (IMO, this is probably still salt+hash) first. Then, describe the additional controls that can be applied to further enhance the protection.
−	~~--[[User:Dan Anderson\|Dan Anderson]] 17:33, 8 June 2012 (UTC)~~
−
−
−	~~IMO, this is a good example: [http://fredericiana.com/2012/06/08/lets-talk-about-password-storage/\|Let’s talk about password storage]~~
−	~~--[[User:Dan Anderson\|Dan Anderson]] 20:58, 8 June 2012 (UTC)~~
−
−	~~----~~
−
−	~~Since the community is focusing more on this page, I think we need a discussion.~~
−
−	~~A few of the points mentioned on this page are dubious to me :~~
−
−	~~==Recommendation: Make it hard to steal the salt==~~
−	~~As far as I know salts are salts, not secrets. They are supposed to be known (in a cryptographic point of view).~~
−
−	* Fixed system salt is a fine practice followed by many,
−	~~but does not increase system security since when concatenated with random salts, its just one long salt with less randomness.~~
−	* Embedding a portion of the salt on source code, is not much different from the configuration file. Same scenario.
−	* Generate new salt everytime password changes. That is true, and somehow required. But not to make salt gathering harder.
−	* Salt in different location: same old
−	~~==Multiple hashes==~~
−	Oddly many open source software follow this paradigm, but it's totally irrelevant. As in Merkle's TIme-Memory tradeoff and Rainbow algorithms it is obvious that multiple hashes result in the same chain or another chain of the rainbow, thus don't add a single bit of security. I believe it must be mentioned that this practice is wrong. I have seen numerous OSS use
−
−	~~hash(salt.hash(user.hash(pass)).salt) which is as secure as hash(salt.pass)~~
−
−	~~or even less (can be exploited somehow).~~
−
−	~~I strongly suggest that this page be modified and fixed. If other members approve, please let me know.~~

@@ Line 1: / Line 1: @@
 Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/
---[[User:jmanico: Jim Manico]] , 16 Sept 2013 (UTC)
+--[[User:jmanico|Jim Manico]] , 16 Sept 2013 (UTC)
 ----

← Older revision		Revision as of 02:18, 17 September 2013
Line 1:		Line 1:
		+	Setting a unlimited length for passwords can be an easy DOS vector. http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/
		+
		+	--[[User:jmanico]] , 16 Sept 2013 (UTC)
		+	----
		+
	More on the previous dicussions on secret salts. They are usually referred to as pepper on practice. The advantage of having a pepper for the passwords is that you can keep them on the web server. Thus, if the hacker has access to the database data and he has access to all hashed passwords (doesn't matter if they are created using PBKDF2, bcrypt or scrypt, or even simple salt+sha2), he still needs to also hack the web server to obtain the pepper, or fixed salt. It isn't cryptographically significant, but it adds yet another layer to the information the hacker has to obtain before starting to do the brute force.		More on the previous dicussions on secret salts. They are usually referred to as pepper on practice. The advantage of having a pepper for the passwords is that you can keep them on the web server. Thus, if the hacker has access to the database data and he has access to all hashed passwords (doesn't matter if they are created using PBKDF2, bcrypt or scrypt, or even simple salt+sha2), he still needs to also hack the web server to obtain the pepper, or fixed salt. It isn't cryptographically significant, but it adds yet another layer to the information the hacker has to obtain before starting to do the brute force.
	I think it would be nice if it was possible to add it to the cheat sheet.		I think it would be nice if it was possible to add it to the cheat sheet.

← Older revision		Revision as of 01:39, 19 March 2013
Line 1:		Line 1:
		+	More on the previous dicussions on secret salts. They are usually referred to as pepper on practice. The advantage of having a pepper for the passwords is that you can keep them on the web server. Thus, if the hacker has access to the database data and he has access to all hashed passwords (doesn't matter if they are created using PBKDF2, bcrypt or scrypt, or even simple salt+sha2), he still needs to also hack the web server to obtain the pepper, or fixed salt. It isn't cryptographically significant, but it adds yet another layer to the information the hacker has to obtain before starting to do the brute force.
		+	I think it would be nice if it was possible to add it to the cheat sheet.
		+
		+	--[[User:Manuel Aude Morales\|Manuel Aude Morales]] , 18 March 2013 (UTC)
		+	----
		+
	I was considering adding bcrypt to the article. I checked previous versions and noticed it was in it on January, but it was taken out during editions in March. From my knowledge, bcrypt is still a widely recommended adaptative hashing function. While it has limitations (particularly, a 55 bytes limitation) and doesn't protect to all hardware accelerated attacks, it does protect against GPU and works as good as PBKDF2 for most cases. Also, scrypt hasn't existed for nearly as much as bcrypt, and thus it isn't as widely tested or supported by platforms.		I was considering adding bcrypt to the article. I checked previous versions and noticed it was in it on January, but it was taken out during editions in March. From my knowledge, bcrypt is still a widely recommended adaptative hashing function. While it has limitations (particularly, a 55 bytes limitation) and doesn't protect to all hardware accelerated attacks, it does protect against GPU and works as good as PBKDF2 for most cases. Also, scrypt hasn't existed for nearly as much as bcrypt, and thus it isn't as widely tested or supported by platforms.

@@ Line 2: / Line 2: @@
 Would it be ok to add a table making a comparison between PBKDF2, bcrypt and scrypt, with suggestions on when to use (and clarifying that the three are valid options)?
---[[User:Manuel Aude Morales|Manuel Aude Morales]] 17:33, 8 June 2012 (UTC)
+--[[User:Manuel Aude Morales|Manuel Aude Morales]] , 18 March 2013 (UTC)
 I think, for this cheat-sheet, we should begin by identifying and describing the minimum acceptable mechanisms for password storage (IMO, this is probably still salt+hash) first.  Then, describe the additional controls that can be applied to further enhance the protection.