On 4/11/2014 8:51 AM, Hubert Kario wrote:
----- Original Message -----
From: "Jakob Kramer" <[email protected]>
To: [email protected]
Sent: Friday, 11 April, 2014 3:01:42 PM
Subject: [openssl-dev] Maximum length of passwords
There should either be a function that automatically allocates enough
memory to put the whole password in it (openssh does it this way, see
read_passphrase from openssh/readpass.c), or a compile-time flag that
sets the PASS_MAXLEN.
Either way every `app' should check whether the whole password was read
and not silently truncate the password, and all apps should behave
consistently.
I would like to hear which approach you would choose, malloc or PASS_MAXLEN.
128 characters allows you to hex encode 512 bits of data (e.g. from sha512sum)
assuming 8 character words from 2048 word dictionary gives you
176 bit entropy for the same 128 characters.
So, PASS_MAXLEN of 256 characters should be enough for anybody
Maybe not. Some smart cards are looking at accepting a fingerprint scan as a
PIN. The card then does the match.
In some apps this might be passed in as a password then passed to an engine to
be passed in as a PIN.
(How the card detects a replay is up to the card.)
and of 128 for
most environments. It still should refuse to accept longer passwords and not
silently truncate....
I agree. no silent truncation.
As such, I think both solutions are acceptable.
The static buffer implementation should be simpler, so should have lower
probability of bugs in it.
--
Douglas E. Engert <[email protected]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
