Where is the Md5PasswordDecoder????

[twoencore]

I really need it..why is this not provided?

[igotmilk]

Why do you need a decoder?

It not good security practice to have your application decoding password. Ideally if either the user entered password or the stored DB password is MD5'd, then it better to MD5 encode the one that is not encoded and do a password comparison.

[twoencore]

The application itself wont use the decrypt, We plan to convert all our passwords using using the net.sf.acegisecurity.providers.encoding.Md5Passwor dEncoder

but i noticed there was no .decoding package ,..leave it up to the developer(me) who implements the security to decide what to do with the decoder....

now i am wondering where do i set the passphrase?, i hope the passphrase is not set automatically in every package ACEGI .jar...is that the reason the decoding code is left out??? i hope no,.... security is in the passphrase, and not the in the "salt" .....salt is the only public method i see..

Anway
our customer has this requirement because..
in case we have to get access to a user's account on our system..we need the decoding package..is it avaible???? I've been preaching about this framework now we may not use it cause there is no decoding... or we may just have to write our own.:P.

[igotmilk]

1st off MD5 cannot be decrypted, period. This is why MD5 is very secure.

i hope the passphrase is not set automatically in every package ACEGI .jar

By default, if you do not specify a "salt", then the base MD5 encrypting algorithm will be used. For example here's a sample site for generation MD5 strings http://www.adamek.biz/md5-generator.php. These strings, will be exactly the same in Acegi or any other MD5 encrypted app.

[feenixx]

I really need it..why is this not provided?

Sounds that you really need to read principles of one-way hash algorithims.
It's called one-way for a reason. You compare two digests, like string comparison.

[twoencore]

Sounds that you really need to read principles of one-way hash algorithims.
It's called one-way for a reason. You compare two digests, like string comparison.

i was not asking a question on how to do anything, i can clearly see why ACEGI implemented MD5Ecoding the way it did to simply compare the password....however my post clearly says i wanted to juts do the decoding of the data that is stored on the DB myself using an API....my customer is requesting this feature not I.

1st off MD5 cannot be decrypted, period. This is why MD5 is very secure.

not true, if you can encrypt somthing you can decrypt it. period. ACEGI is most liklying using the Java Cryptography Extension behind the scene.

you both read this.
Cryptographic Concepts.
http://java.sun.com/j2se/1.4.2/docs/...ERefGuide.html

the the "private key" sort of speak is the passhrase which is used to help decrypt/encrypt a "public key" which is the password.



I totally aggree with what "igotmilk",but already stated this is a simply a requirement..i can use have my on Md5 PBE encode/decode method, but i rather use ACEGI totally...i t may not be a good thing to have somthing that decrypts, but it is needed nevertheless..


if you don't know why it was left out other than "you won't need it" then don't flame.

[igotmilk]

ACEGI is most liklying using the Java Cryptography Extension behind the scene.

Spring uses the Apache Commons Codecs to do create its MD5 hash. Take a look at the DigestUtils

the "private key" sort of speak is the passhrase which is used to help decrypt/encrypt a "public key" which is the password.

MD5 is not a private/public key type of security and the SALT key is used for appending to the password to make it more secure against dictionary attacks, but you cannot use the SALT key to decrypt because an MD5 decrypting algorithm does not exist.

[twoencore]

Spring uses the Apache Commons Codecs to do create its MD5 hash. Take a look at the DigestUtils



MD5 is not a private/public key type of security and the SALT key is used for appending to the password to make it more secure against dictionary attacks, but you cannot use the SALT key to decrypt because an MD5 decrypting algorithm does not exist.

Thanks ,
i assumed it was using Java Cryptography Extension(with public/private ) behind the scene..i wish they had more implemented options..we will have to use own ..i think i will post it on JIRA as a request.

[Luke Taylor]

not true, if you can encrypt somthing you can decrypt it. period.

You can.... it may take you some time though.

[assaf]

not true, if you can encrypt somthing you can decrypt it. period.

Please see http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html

To quote:
" [The MD5 algorithm] takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input."

In other words, a given 128-bit MD5 digest (this is what is actually stored in the database) could be decrypted into an infinite number of possible passwords of arbitrary length.

However, finding any single one of those would take an enormous amount of computing time, which is why no decrypt function is provided.

Regards