Dear Colleagues, You may remember that at the RIPE-41 it was agreed to improve the security of password(passphrase) based auth-schemes by introducing the MD5 hash algorithm for password encryption. Please find enclosed the MD5 proposal for your comments and suggestions. Regards, Andrei Robachevsky DB Group Manager RIPE NCC Improving security of password (passphrase) based auth schemes (MD5 proposal) -============================================================================- Introduction ------------ Currently the RIPE Database implements the only password based "auth" scheme, which is "CRYPT-PW" scheme. This scheme uses an encryption process which is similar to that used to make and check login passwords in UNIX. A password is chosen by the user; this is encrypted using DEC crypt(3) and put in the database. The encrypted password can be seen by everyone. The user sends the clear password in the same mail as the request to change an object using "password:" pseudo-attribute. Motivation ---------- The main flaw of the CRYPT-PW scheme is that password is limited to 8 characters, which makes exhaustive searches of the key space possible given that crypted password is publicly available. Also the DES algorithm itself has a few quirks which lower the security of the scheme. Allowing longer keys and using more secure encryption algorithm could improve security of password-based auth scheme. Proposal -------- A new "auth:" scheme is introduced based on MD5 hash algorithm. The format of the new "auth" scheme is: auth: MD5-PW <digest> where <digest> is a 128-bit MD5 digest. For example: auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 When submitting an update to the database that needs to be authorised using this scheme, a "password:" pseudo-attribute must be used to submit a key (passphrase). Line continuation is not allowed for this attribute, so the whole key should fit on one line. If the key gets split across multiple lines this will be treated as syntax error. If the mntner that defines authorisation information for the submission has CRYPT-PW and MD5-PW "auth" schemes, the key specified by "password:" will be checked for both types.
Hi, On Mon, 25 Mar 2002, Andrei Robachevsky wrote:
Proposal --------
A new "auth:" scheme is introduced based on MD5 hash algorithm. The format of the new "auth" scheme is:
auth: MD5-PW <digest>
where <digest> is a 128-bit MD5 digest.
For example:
auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524
Why not use md5 crypt wich is already used on many operating systems for passwords? auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0 /Oli -- Olafur Osvaldsson Systems Administrator Internet a Islandi hf. Tel: +354 525-5291 Email: oli@isnic.is
In message <20020325130131.T20936@isnic.is>, Olafur Osvaldsson writes:
auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524
Why not use md5 crypt wich is already used on many operating systems for passwords?
auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0
The source can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning Kamp wrote:
In message <20020325130131.T20936@isnic.is>, Olafur Osvaldsson writes:
auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524
Why not use md5 crypt wich is already used on many operating systems for passwords?
auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0
The source can be found here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c
I agree that a salt makes dictionary attacks very hard if not impossible. And this is good argument in favour of the Olafur's and Poul-Henning's proposal. My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash better? Regards, Andrei Robachevsky RIPE NCC
In message <3CA1F83A.80802@ripe.net>, Andrei Robachevsky writes:
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future.
The implementation will not change, it would screw all cisco router enable passwords and most FreeBSD passwords.
And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash better?
It makes dictionary attacks harder and more timeconsuming, it also makes it harder to do hardware implementations because you need many times more hardware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash better? It makes dictionary attacks harder and more timeconsuming, it also makes it harder to do hardware implementations because you need many times more hardware.
the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area. randy
----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Poul-Henning Kamp" <phk@critter.freebsd.dk> Cc: "Andrei Robachevsky" <andrei@ripe.net>; "Olafur Osvaldsson" <oli@isnic.is>; <db-wg@ripe.net> Sent: Thursday, March 28, 2002 5:31 PM Subject: Re: MD5 proposal
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash better? It makes dictionary attacks harder and more timeconsuming, it also makes it harder to do hardware implementations because you need many times more hardware.
the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area.
randy
Randy and all, On Thu, 28 Mar 2002, Randy Bush wrote:
Andrei Robachevsky wrote:
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future.
[snip]
the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area.
randy
I'm looking into this. Any other volunteers/suggestions? Pierre.
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area. I'm looking into this. Any other volunteers/suggestions?
keep it simple. what is the minimal draft to accomplish what is needed? do that. randy
----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Pierre Baume" <pierre@baume.org> Cc: "Poul-Henning Kamp" <phk@critter.freebsd.dk>; "Andrei Robachevsky" <andrei@ripe.net>; "Olafur Osvaldsson" <oli@isnic.is>; <db-wg@ripe.net> Sent: Friday, March 29, 2002 6:21 PM Subject: Re: MD5 proposal
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area. I'm looking into this. Any other volunteers/suggestions?
keep it simple. what is the minimal draft to accomplish what is needed? do that.
randy
----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Pierre Baume" <pierre@baume.org> Cc: "Poul-Henning Kamp" <phk@critter.freebsd.dk>; "Andrei Robachevsky" <andrei@ripe.net>; "Olafur Osvaldsson" <oli@isnic.is>; <db-wg@ripe.net> Sent: Friday, March 29, 2002 6:21 PM Subject: Re: MD5 proposal
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area. I'm looking into this. Any other volunteers/suggestions?
keep it simple. what is the minimal draft to accomplish what is needed? do that.
randy
----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Pierre Baume" <pierre@baume.org> Cc: "Poul-Henning Kamp" <phk@critter.freebsd.dk>; "Andrei Robachevsky" <andrei@ripe.net>; "Olafur Osvaldsson" <oli@isnic.is>; <db-wg@ripe.net> Sent: Friday, March 29, 2002 6:21 PM Subject: Re: MD5 proposal
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future. the way out of this would seem to be for someone to write an internet draft on salted md5 and process it through the ietf security area. I'm looking into this. Any other volunteers/suggestions?
keep it simple. what is the minimal draft to accomplish what is needed? do that.
randy
----- Original Message ----- From: "Poul-Henning Kamp" <phk@critter.freebsd.dk> To: "Andrei Robachevsky" <andrei@ripe.net> Cc: "Olafur Osvaldsson" <oli@isnic.is>; <db-wg@ripe.net> Sent: Wednesday, March 27, 2002 6:03 PM Subject: Re: MD5 proposal
In message <3CA1F83A.80802@ripe.net>, Andrei Robachevsky writes:
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future.
The implementation will not change, it would screw all cisco router enable passwords and most FreeBSD passwords.
And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash better?
It makes dictionary attacks harder and more timeconsuming, it also makes it harder to do hardware implementations because you need many times more hardware.
-- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Poul-Henning Kamp wrote:
In message <20020325130131.T20936@isnic.is>, Olafur Osvaldsson writes:
auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524
Why not use md5 crypt wich is already used on many operating systems for passwords?
auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0
The source can be found here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c
I agree that a salt makes dictionary attacks very hard if not impossible. And this is good argument in favour of the Olafur's and Poul-Henning's proposal.
A reasonbly lengthy (and random) salt only makes pre-computed dictionary attacks impossible, but it does not prevent brute force dictionary attacks. John the Ripper (www.openwall.com/john) has support for dictionary-based attacks on des-crypt, FreeBSD md5-crypt, and OpenBSD bcrypt password hash functions.
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future.
Changing an existing Unix password hash function would be a very unlikely action as you would break portability of password hashes between systems (speaking as a former sys-admin, this would be a nightmare). This is one reason for longevity of des-crypt (despite it's documented weaknesses).
And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash better?
It's a combination of the salt and computational complexity that makes md5-crypt significantly better than straight MD5. OpenBSD's bcrypt goes a step further than md5-crypt in computational intensity and also allows one to specify the number of interation rounds in the hash to provide further strength as computing power progresses. One could argue that, absent any mandatory password goodness/length requirements, the existing des-crypt is better than straight MD5. Speaking from an RPSLng perspective, I'd like to see any new hashed password based auth mechanism provide better support for keeping the hash private. While I'm not necessarily arguing this should be mandatory, I believe it should at least be optional. One way to provide better support for this would be to include some sort of identifier with the hash. This could either be on the same auth: line as the hash, or the identifier could be a key to a separate object that contains the actual hash (as is done with PGPKEY based authentication). -Larry Blunk Merit
Regards,
Andrei Robachevsky RIPE NCC
----- Original Message ----- From: "Larry J. Blunk" <ljb@merit.edu> To: "Andrei Robachevsky" <andrei@ripe.net> Cc: "Poul-Henning Kamp" <phk@critter.freebsd.dk>; "Olafur Osvaldsson" <oli@isnic.is>; <db-wg@ripe.net> Sent: Thursday, March 28, 2002 9:34 AM Subject: Re: MD5 proposal
Poul-Henning Kamp wrote:
In message <20020325130131.T20936@isnic.is>, Olafur Osvaldsson writes:
auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524
Why not use md5 crypt wich is already used on many operating systems
passwords?
auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0
The source can be found here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c
I agree that a salt makes dictionary attacks very hard if not impossible. And this is good argument in favour of the Olafur's and Poul-Henning's proposal.
A reasonbly lengthy (and random) salt only makes pre-computed dictionary attacks impossible, but it does not prevent brute force dictionary attacks. John the Ripper (www.openwall.com/john) has support for dictionary-based attacks on des-crypt, FreeBSD md5-crypt, and OpenBSD bcrypt password hash functions.
My main concern here would be that basing the proposed method on an implementation (md5-crypt), which may change or may be mixed with some other implementation, rather than on the documented algorithm (md5 hash), which cannot, may cause confusion in the future.
Changing an existing Unix password hash function would be a very unlikely action as you would break portability of password hashes between systems (speaking as a former sys-admin, this would be a nightmare). This is one reason for longevity of des-crypt (despite it's documented weaknesses).
And, as a side question from a person far from cryptography, is it a proved fact that iterative complexity of md5-crypt makes the hash
better?
It's a combination of the salt and computational complexity that makes md5-crypt significantly better than straight MD5. OpenBSD's bcrypt goes a step further than md5-crypt in computational intensity and also allows one to specify the number of interation rounds in the hash to
for provide
further strength as computing power progresses. One could argue that, absent any mandatory password goodness/length requirements, the existing des-crypt is better than straight MD5.
Speaking from an RPSLng perspective, I'd like to see any new hashed password based auth mechanism provide better support for keeping the hash private. While I'm not necessarily arguing this should be mandatory, I believe it should at least be optional. One way to provide better support for this would be to include some sort of identifier with the hash. This could either be on the same auth: line as the hash, or the identifier could be a key to a separate object that contains the actual hash (as is done with PGPKEY based authentication).
-Larry Blunk Merit
Regards,
Andrei Robachevsky RIPE NCC
On Mon, 25 Mar 2002, Andrei Robachevsky wrote: AR> You may remember that at the RIPE-41 it was agreed to improve the AR> security of password(passphrase) based auth-schemes by introducing the AR> MD5 hash algorithm for password encryption. AR> AR> Please find enclosed the MD5 proposal for your comments and suggestions. AR> AR> auth: MD5-PW <digest> AR> AR> where <digest> is a 128-bit MD5 digest. AR> AR> For example: AR> AR> auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 Hmm, would it not to be simpler to use BSD-style of $1$ crypt? E.g. Auth: CRYPT-PW $1$salt$hash... Which is - standard for most of current *NIX clones - easy to detect by $1$ prefix for the software Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Dear Colleagues, Please let me summarise the additions and modifications to the proposal, and present you the next approximation. Only changes to the proposal are included below. Would it be possible to respond with your comments till the end of the next week so we can proceed with implementation?
Improving security of password (passphrase) based auth schemes (MD5 proposal) -============================================================================-
[...]
Proposal --------
A new "auth:" scheme is introduced based on MD5 hash algorithm. The format of the new "auth" scheme is:
auth: MD5-PW <md5-crypt> where <md5-crypt> is an output of the md5-crypt, which is concatenation of "$1$", the salt, and the 128-bit hash output. For example: auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0 #A comment: We feel that despite $1$ indication of the algorithm used we need #this separate "MD5-PW" label. Our experience shows that every effort made to #avoid confusion is eventually paid back. #Another comment: we would appreciate if someone writes an #internet-draft on md5-crypt and processes it through IETF, as Randy #suggested.
At the first character after the first white space (space or tab)
following the colon (":")
When submitting an update to the database that needs to be authorised using this scheme, a "password:" pseudo-attribute must be used to submit a key (passphrase). Line continuation is not allowed for this attribute, so the whole key should fit on one line. If the key gets split across multiple lines this will be treated as syntax error.
The value of the key starts at the first character after the first white space following the colon (":").
If the mntner that defines authorisation information for the submission has CRYPT-PW and MD5-PW "auth" schemes, the key specified by "password:" will be checked for both types.
Regards, Andrei Robachevsky RIPE NCC
Dear Colleagues,
Please let me summarise the additions and modifications to the proposal, and present you the next approximation.
Only changes to the proposal are included below.
Would it be possible to respond with your comments till the end of the next week so we can proceed with implementation?
Improving security of password (passphrase) based auth schemes (MD5
----- Original Message ----- From: "Andrei Robachevsky" <andrei@ripe.net> To: "Andrei Robachevsky" <andrei@ripe.net> Cc: <db-wg@ripe.net> Sent: Thursday, March 28, 2002 6:02 PM Subject: Re: MD5 proposal proposal)
-=========================================================================
[...]
Proposal --------
A new "auth:" scheme is introduced based on MD5 hash algorithm. The
of the new "auth" scheme is:
auth: MD5-PW <md5-crypt>
where <md5-crypt> is an output of the md5-crypt, which is concatenation of "$1$", the salt, and the 128-bit hash output.
For example:
auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0
#A comment: We feel that despite $1$ indication of the algorithm used we need
#this separate "MD5-PW" label. Our experience shows that every effort made to
#avoid confusion is eventually paid back.
#Another comment: we would appreciate if someone writes an #internet-draft on md5-crypt and processes it through IETF, as Randy #suggested.
At the first character after the first white space (space or tab)
following the colon (":")
When submitting an update to the database that needs to be authorised using this scheme, a "password:" pseudo-attribute must be used to submit a key (passphrase). Line continuation is not allowed for this attribute, so
===- format the
whole key should fit on one line. If the key gets split across multiple lines this will be treated as syntax error.
The value of the key starts at the first character after the first white space following the colon (":").
If the mntner that defines authorisation information for the submission
has
CRYPT-PW and MD5-PW "auth" schemes, the key specified by "password:" will be checked for both types.
Regards,
Andrei Robachevsky RIPE NCC
Dear Colleagues, Recently a proposal for a new, MD5 based "auth" scheme was circulated and discussed in this list. Thank all of you who contributed to this discussion. The final version was prepared based on your comments and suggestions. Please find attached the description of the new "auth" scheme. It is currently being implemented and we plan to make it available at the beginning of May. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC New "auth" scheme, MD5-PW, in the RIPE Database -=============================================- Introduction ------------ Currently the RIPE Database implements the only password based "auth" scheme, which is "CRYPT-PW" scheme. This scheme uses an encryption process which is similar to that used to make and check login passwords in UNIX. A password is chosen by the user; this is encrypted using DEC crypt(3) and put in the database. The encrypted password can be seen by everyone. The user sends the clear password in the same mail as the request to change an object using "password:" pseudo attribute. Motivation ---------- The main flaw of the CRYPT-PW scheme is that password is limited to 8 characters, which makes exhaustive searches of the key space possible given that crypted password is publicly available. Also the DES algorithm itself has a few quirks which lower the security of the scheme. Allowing longer keys and using more secure encryption algorithm could improve security of password-based auth scheme. Implementation -------------- A new "auth:" scheme is introduced based on MD5 hash algorithm. The format of the new "auth" scheme is: auth: MD5-PW <md5-crypt> where <md5-crypt> is an output of the md5-crypt, which is concatenation of "$1$" string, the salt, and the 128-bit hash output. For example: auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0 When submitting an update to the database that needs to be authorised using this scheme, a "password:" pseudo attribute must be used to submit a key (passphrase). The value of the key starts at the first non-white space character after the colon. Line continuation is not allowed for this pseudo attribute, so the whole pseudo attribute should fit on one line. If it gets split across multiple lines this will be treated as syntax error. If the mntner that defines authorisation information for the submission has CRYPT-PW and MD5-PW "auth" schemes, the key specified by "password:" will be checked for both types.
participants (8)
-
Andrei Robachevsky -
Dmitry Morozovsky -
Larry J. Blunk -
mc -
Olafur Osvaldsson -
Pierre Baume -
Poul-Henning Kamp -
Randy Bush