Hello all,
I do some investigations about userpassword and Authpassword problems , ....1st I will mention something about Hashing (One way function) and has no inverse. derived from Mathematics.
I studied open source for LDAP openldap(some of the source code) and I found some standards in using of such attributes Auth:userPassword and that's what I found
I install it under my Linux box RH)
I will give u a snapshot of a program using a brute force attack on 8 char passwords for Unix crypt function done by me last year to see that there's no difference in storing a password as clear text or hashed if it is under protocol transfer.
MD5 hashing tech under Linux:
=========================================
{crypt}:$1$$fSLJR.mDihX4h7VRnvhWg0
pass:aaaaaaad {crypt}:$1$$5Gwynw/LWU3To8herc2cE/
pass:aaaaaaae {crypt}:$1$$QiXBLeKAa4PRqdRVc2G1t/
pass:aaaaaaaf {crypt}:$1$$eD4UKhZ1lNm/1txfyzq/z1
pass:aaaaaaag {crypt}:$1$$/DIYAIOzWZetuvdxjkplT.
pass:aaaaaaah {crypt}:$1$$sAiFY5pWhGsNA/riXI6jt/
pass:aaaaaaai {crypt}:$1$$Wxi2NW7Hdse5e/JJyOXXl.
pass:aaaaaaaj {crypt}:$1$$GbCYLifS2P2DmpkyzbR8b1
pass:aaaaaaak {crypt}:$1$$MXhbdgSKdrUp4ExQSsbFV.
pass:aaaaaaal {crypt}:$1$$c.h8jsU6hO4FNqow702zh/
=========================================
ie if u have a hash also u could try millions of possibilities to know the matched password depends on what CPU's do we have. that's How attacker thinks.
inside the source I found some nice statemets about security it looks like the roots for our Tree:
1- The practice storing hashed passwords in userPassword violates Standard Track (RFC 2256) schema specifications and may hinder interoperability. A new attribute type, authPassword, to hold hashed passwords has been defined (RFC 3112).
2- Security: Use of hashed passwords does not protect passwords during protocol transfer. TLS or other eavesdropping protections should be inplace before using LDAP simple bind. The
hashed password values should be protected as if they
were clear text passwords.
from RFC(3112) :
The userPassword attribute type [RFC2256] is intended to be used to support the LDAP [RFC2251] "simple" bind operation. However, values of userPassword must be clear text passwords. It is often desirable to store values derived from the user's password(s) instead of actual passwords.
The authPassword attribute type is intended to be used to store
information used to implement simple password based authentication.
The attribute type may be used by LDAP servers to implement the LDAP Bind operation's "simple" authentication method.
The attribute type supports multiple storage schemes. A matching rule is provided for use with extensible search filters to allow clients to assert that a clear text password "matches" one of the attribute's values.
Storage schemes often use cryptographic strength one-way hashing.Though the use of one-way hashing reduces the potential that exposed values will allow unauthorized access to the Directory (unless the hash algorithm/implementation is flawed), the hashing of passwords is intended to be as an additional layer of protection. It is RECOMMENDED
that hashed values be protected as if they were clear
text passwords.
This attribute may be used in conjunction with server side password generation mechanisms (such as the LDAP Password Modify [RFC3062] extended operation).
Access to this attribute may governed by administrative controls such
as those which implement password change policies.
here is :
authPasswordSyntax
( 1.3.6.1.4.1.4203.1.1.2
DESC 'authentication password syntax' )
Values of this syntax are encoded according to:
authPasswordValue = w scheme s authInfo s authValue w
scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
; 0-9, A-Z, "-", ".", "/", or "_"
authInfo = schemeSpecificValue
authValue = schemeSpecificValue
schemeSpecificValue = *( %x21-23 / %x25-7E )
; printable ASCII less "$" and " "
s = w SEP w
w = *SP
SEP = %x24 ; "$"
SP = %x20 ; " " (space)
where scheme describes the mechanism and authInfo and authValue are a scheme specific. The authInfo field is often a base64 encoded salt.
The authValue field is often a base64 encoded value derived from a user's password(s). Values of this attribute are case sensitive. Transfer of values of this syntax is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.
I want to ask a Q's ....when a user login using iPlanet Massenging service the Password are automaticly hashed using a function which is inside the iPlanet(client itself) ie the hashed Password transfered thru the wires ????
authValue attribute or AuthPassword MUST be derived from a clear text (user Password) as also they mentioned thru the last post. everything will work fine if we follow the Standards.if we have hashed password received from a client and in userPassword there is a clear-text Password ie we have to do hashing for the clear text Password and compare them on the Server.I think that's a problem if hundred of user login or more .
if we have a script to used for saving cleartext and hashed value of all formatted and Let AuthPassword Accessed to cleartext value ie we have to interface or to Know the source Code as we are in an open enviroment(OnEvent) .like in OpenLDAP. I have to be On ground and have access to the whole system Inshalllah.also these days I 'm studying TSL (Transport Security layer) as a solution to protect and secure our not system but data transmission (encryption) and confidentially.
Does any one have suggestion Please in details
Oracle AuthPassword and LDAP
