about summary refs log tree commit diff
path: root/src/crypt/crypt_sha512.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2012-09-15 03:03:21 -0400
committerRich Felker <dalias@aerifal.cx>2012-09-15 03:03:21 -0400
commitaeaceb1fa89b865eb0bca739da9c450b5a054866 (patch)
tree7fb333d7d9cab1198053973d39b62630d588cfd2 /src/crypt/crypt_sha512.c
parent881868382a54b851b37d0b0f5f2d44f77af998a7 (diff)
downloadmusl-aeaceb1fa89b865eb0bca739da9c450b5a054866.tar.gz
musl-aeaceb1fa89b865eb0bca739da9c450b5a054866.tar.xz
musl-aeaceb1fa89b865eb0bca739da9c450b5a054866.zip
revert low rounds-count limits in crypt hashes
it was determined in discussion that these kind of limits are not
sufficient to protect single-threaded servers against denial of
service attacks from maliciously large round counts. the time scales
simply vary too much; many users will want login passwords with rounds
counts on a scale that gives decisecond latency, while highly loaded
webservers will need millisecond latency or shorter.

still some limit is left in place; the idea is not to protect against
attacks, but to avoid the runtime of a single call to crypt being, for
all practical purposes, infinite, so that configuration errors can be
caught and fixed without bringing down whole systems. these limits are
very high, on the order of minute-long runtimes for modest systems.
Diffstat (limited to 'src/crypt/crypt_sha512.c')
-rw-r--r--src/crypt/crypt_sha512.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/crypt/crypt_sha512.c b/src/crypt/crypt_sha512.c
index 2c0de698..0f1de814 100644
--- a/src/crypt/crypt_sha512.c
+++ b/src/crypt/crypt_sha512.c
@@ -193,7 +193,7 @@ static char *to64(char *s, unsigned int u, int n)
 #define SALT_MAX 16
 #define ROUNDS_DEFAULT 5000
 #define ROUNDS_MIN 1000
-#define ROUNDS_MAX 20000
+#define ROUNDS_MAX 9999999
 
 /* hash n bytes of the repeated md message digest */
 static void hashmd(struct sha512 *s, unsigned int n, const void *md)