2

How many iterations does the scram-sha-256 setting use in PostgreSQL 10?

The docs just say

Setting this parameter to scram-sha-256 will encrypt the password with SCRAM-SHA-256.

The build log reads.

Add SCRAM-SHA-256 support for password negotiation and storage (Michael Paquier, Heikki Linnakangas) This proves better security than the existing md5 negotiation and storage method.

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468

1 Answers1

4

It's a compile-time variable in scram-common.h known as SCRAM_ITERATIONS_DEFAULT. Currently it's set to 4096.

That's substantially under the specs "rule of thumb" which is cited in Nov 2015 as being 15,000. It's currently the lowest value for permissible iterations. From RFC-7677

The strength of this mechanism is dependent in part on the hash iteration-count, as denoted by "i" in [RFC5802]. As a rule of thumb, the hash iteration-count should be such that a modern machine will take 0.1 seconds to perform the complete algorithm; however, this is unlikely to be practical on mobile devices and other relatively low- performance systems. At the time this was written, the rule of thumb gives around 15,000 iterations required; however, a hash iteration- count of 4096 takes around 0.5 seconds on current mobile handsets. This computational cost can be avoided by caching the ClientKey (assuming the Salt and hash iteration-count is stable). Therefore, the recommendation of this specification is that the hash iteration- count SHOULD be at least 4096, but careful consideration ought to be given to using a significantly higher value, particularly where mobile use is less important.

Community
  • 1
  • 1
Evan Carroll
  • 78,363
  • 46
  • 261
  • 468
  • You could write to the -hackers list and suggest that the count be raised. Changing this value would render all existing passwords invalid, right? – Laurenz Albe Apr 28 '17 at 09:32
  • 1
    I thought about this some more, and I'd say that it would not be a good idea to set this value higher than the minimal value considered safe. Setting this to a high value will slow down verification, which is good against a brute force attack that tries to guess the password, but it will slow down **every** connection to the database. This is a price that is too high in my opinion. – Laurenz Albe Apr 28 '17 at 14:20
  • @LaurenzAlbe by the same token, anything other the plain text slows down a connection to the database. =) The slower you make the connection, the more secure the password. And, also, should connection speed really matter or should apps be connection pooling? Either way, I was just curious to know what the setting was, and I imagine others will be too. – Evan Carroll Apr 28 '17 at 16:59
  • in reply to "Changing this value would render all existing passwords invalid, right?": No, it would not. The iteration count is embedded inside the "encrypted password" stored by Postgres. As such, increasing the iteration count would only impact newly set passwords, but existing passwords would simply keep using the previously lower iteration count. – Vogelsgesang Feb 03 '21 at 10:41