LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 07-24-2003, 03:55 AM   #1
atiato
LQ Newbie
 
Registered: Mar 2002
Posts: 5

Rep: Reputation: 0
Post Oracle AuthPassword and LDAP


Requirement:

The passwords for users need to be synchronized from iPlanet to Oracle Internet Directory (OID) for use with iFS. The synchronization will only be a one-way synchronization. The users will change their password in iPlanet Directory through the iPlanet Messaging Web Interface and the password needs to be propagated to OID. OID and iPlanet both store their password in the userPassword attribute. iFS stores its password in the authPassword attribute. authPassword is a mutli-valued attribute. The authPassword attribute is generated from the userPassword attribute automatically. The authPassword attribute must be updated for iFS authentication to be successful (which is the basic requirement).



Password Format:

The passwords are stored in iPlanet in SSHA format, but can also be stored in SHA or MD5 format. OID supports SSHA, SHA and also MD5.



Problem:

Whenever the userPassword attribute is updated in clear-text in OID, the userPassword attribute automatically gets encrypted and also generates an encrypted form of authPassword attribute. If the userPassword attribute is updated in encrypted form directly by taking the encrypted userPassword from iPlanet, the authPassword attribute does not get updated. The technical reason for the authPassword attribute not being updated is because "A Hash cannot be generated from another Hash". The userPassword in OID although does get updated and is correct. If only the userPassword attribute is directly used for authentication is has the correctly synchronized password attribute. The problem is that iFS does not use the userPassword attribute for authentication, it uses authPassword attribute instead.



Possible Solutions:

Following are some of the possible solutions for the password synchronization:

Modify the Web Interface of iPlanet Messaging Server such that whenever the user updates his/her password from the web interface, the server also updates the userPassword attribute in OID. (The connection between servers must use SSL).
Investigate on and check if iPlanet supports Events. Implement a "Before-password-Change-Event" that updates the userPassword attribute in OID. (The connection between servers must use SSL).
Store the password in iPlanet in Clear-text by default. Whenever the userPassword gets updated, use the clear-text version of the password to update the userPassword attribute in OID. The userPassword attribute will be encrypted in OID in this way. Then use this encrypted password in OID and write it back to the userPassword attribute in iPlanet. (The connection between servers must use SSL).


I Will also Write My opinion in this Problem if any body could help I would appreciate that !!!!!!!
 
Old 07-24-2003, 04:02 AM   #2
atiato
LQ Newbie
 
Registered: Mar 2002
Posts: 5

Original Poster
Rep: Reputation: 0
My Suggestion???

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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LDAP: Can't contact master ldap server rulirahm Linux - Networking 2 07-14-2014 02:02 AM
Difference between Oracle Server and Oracle Database ganninu Programming 3 02-27-2007 01:06 AM
LDAP server not starting as user LDAP klnasveschuk Fedora 1 02-15-2007 04:49 AM
xhost + as user oracle not working, need to see oracle install GUI enzo250gto Linux - Software 2 02-11-2007 11:27 AM
ldap-abook unable to get street name in ldap-entry Jingle Linux - Software 1 06-06-2004 07:13 PM


All times are GMT -5. The time now is 02:24 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration