Well, maybe i'm a little out of context, but aren't we talking about a way to store the password???
Well, as long as i remember there are certain rules... like password encryption should not be reversible, that's why you should use MD5 or even better SHA1. For the proccess of validate the user.... 1. The MD5 or SHA1 must be calculated on the client's browser isn't it?? it must be done in a SSL enviroment so the hash should not be sniffed. why AES? why 3DES? those are not intented to password protection, 'cause they are reversible, aren't they? well, just some thought ... thanks Carlos Ospina El jue, 26-02-2004 a las 19:40, Matthias Niess escribiÃ: > Hi, > > I don't know whether this was discussed before but here are a couple of > thoughts on encryption algorithms and user validation: > First of all I don't think that the collision problem is important since > usernames are short enough to make a hashing collision impossible. The > attackablity of MD5 indeed poses a critical threat to an application such as > care2x which is supposed to be used in sensitive environments. This makes > MD5 unusable for a productive environment. > My proposal would be to use MD5 for testing and developement purposes, but > switch to a 2-key system for productive environments. One might use AES with > an OpenPGP implementation like GnuPG. Every user could have a chipcard and > the computers running care2x would have chipcard terminals then. The private > key is stored on the chipcard and - in combination with a password - used to > identify the users to the system. > > I think this is the most secure and attack-resistant ways of user > validation. Just too annoying for testing and presentation. It should be > possible to switch between those two systems. So when care2x is being set up > at a client (like a hospital), as long as it's still being tested use MD5 - > when everything works switch to PGP. > > Shouldn't be too hard to implement? > > regards > Matthias Niess > > ----- Original Message ----- > From: "J. Antas" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, February 26, 2004 3:50 AM > Subject: [Care2002-developers] MD5 vs. DES (+knoppix-installer) > > > > The following summary was prepared in the context of a work for the > > Knoppix developers ring. > > As Care2x also uses the MD5 algorithm to validate its users I thought > > that it could be of some use to also post it here. > > > > -------- Original Message -------- > > Subject: Re: [debian-knoppix] Re: MD5 vs. DES (+knoppix-installer) > > Date: Thu, 26 Feb 2004 02:44:18 +0000 > > From: plasticdoc > > Reply-To: > > To: Fabian Franz <[EMAIL PROTECTED]> > > CC: [EMAIL PROTECTED] > > References: <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED]> > > > > Fabian Franz wrote: > > > > > Well, I will read some of them, although I'm really short of time :-/ > > > > I will try to summarize: > > > > Some other software projects currently use MD5 to verify the identity of > > its users. Given an input string, for instance made off as âlogin nameâ > > and âpasswordâ, it produces a fixed length output string. This output > > string has some special characteristics that, in theory, make it very > > difficult to reverse the process and find the original input string. > > > > In those projects when a user logs into the program he is asked for a > > login name and a password. Those strings are immediately processed with > > MD5 and the result may be stored somewhere for future use. If the user > > forgets his password or login name it is very difficult to recover the > > lost information and usually the user is reset by the system > > administrator to a new password. When compared with other procedures MD5 > > is an order of magnitude safer. > > > > But some study of the MD5 algorithm must be made to evaluate its value > > in the context of its intended use to protect the access to confidential > > personal information. > > > > The MD5 algorithm, meaning Message Digest 5, was described by Rivest in > > 1991 and intended to be used as a general good quality Hashing Function > > with the following characteristics: > > It is a one way One Way Hash Function (OWHF), meaning that it has the > > following properties: > > 1. it is easy to compute (no need to use specially fast hardware), > > 2. it is able to compress an arbitrary length message to a fixed > > length output string, > > 3. it has pre-image resistance, i.e., given an output it is hard to > > find a corresponding input, > > 4. it has 2nd pre-image resistance, i.e., given an input/output pair > > it is hard to find a second of computation computationally > > > > Theoretically, it has also a Collision Resistant Hash Function (CRHF), > > meaning that it has all the above properties plus: > > 5. collision resistance, i.e., it is hard to find any two inputs that > > provide the same output, > > 6. collisions are computationally hard to identify. > > > > Practice has evidenced some problems with MD5: > > 1. Pseudo-collisions for the compression function have been described > > by Bosselaers (1993) > > 2. Collisions for the compression function have been described by > > Dobbertin (1996) > > > > So it is now regarded as best practice not to use MD5 as an Collision > > Resistant Hash Function. It is now feasible to break MD5 in under 6 > > hours with a plain vanilla 3 GHz i86 family CPU. And as these attacks > > have the potential to be "parallelizable", I guess that in many > > enterprises it should be possible to use available computers as a > > cluster (for instance with openmosix), and in that case the break-in > > would be a matter of minutes (!!!). > > > > Other algorithms were proposed as more robust alternatives. > > That was the case of HAVAL and RIPEMD, but also SHA (in various bit > > lengths). The current best choices seem to be: > > 1. HAVAL, which is an improved derivative of MD5, described by Zheng, > > Pieprzyk, and Seberry in a 1992 paper. > > 2. RIPEMD, which was born as a result of an EU initiative and was first > > described in 1993. It seems that RIPEMD-160, an 160 bit version of > > RIPEMD, is also a very popular alternative to MD5. > > > > I do prefer HAVAL but, be warned, neither MD5, HAVAL nor RIPEMD are used > > by the Intelligence or Military communities for any serious work, so the > > message seems to be clear... > > > > Also take note that in the USA, most of those algorithms are considered > > weaponry, so if you visit the USA take care not to leave with software > > containing them, or you risk to be arrested when you leave the USA. > > > > Best regards, > > > > J. A. > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > > Build and deploy apps & Web services for Linux with > > a free DVD software kit from IBM. Click Now! > > http://ads.osdn.com/?ad_id56&alloc_id438&opÃk > > _______________________________________________ > > Care2002-developers mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/care2002-developers > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id56&alloc_id438&op=click > _______________________________________________ > Care2002-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/care2002-developers ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Care2002-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/care2002-developers
