It sounds like you are storing the password hash rather than the password in LDAP. However, the plaintext password is still travelling from the browser to the server where it is hashed and the hashes are presumably compared.
So this will *not* mitigate any issues with an expired web site cert. In theory, it prevents the plaintext password from travelling from the web server to your LDAP DIT. However, most directories I have experience with natively handle storing the the password hash rather than the plaintext password. Performing an LDAP BIND requires the plaintext password, but the LDAP auth mechinisms will transparently select the matching authentication mechanism (e.g. OpenLDAP) does this. MD5 has also been defeated. The wikipedia entry mentions that in 2013, a technique was published that can break MD5 in 2 seconds on a modern computer. It would probably be wise to look into using your LDAP's native hashing ability and seeing if it supports a better hashing scheme, ideally with a salt. That said, having the trasport from the web server to the LDAP server encrypted would also be a good idea, and this is also commonly done using SSL certificates. For encryption in transport, use SSL. Thanks, Carl Waldbieser Lafayette College On Sep 28, 2014 3:26 AM, "Sreejith NP" <np.sreej...@gmail.com> wrote: > Hi Anshika, > Even if you are accessing the site over https the site may become > vulnerable if your certificate expires. > To achieve client side password encryption, we have done the following > steps. > 1. password is stored as cleartext in LDAP, but the stored (clear text) > password is the MD5() of actual password. > 2. in jasp we have converted the password entered by the user to its > respective md5() > > with regards > Sreejith > > On Fri, Sep 26, 2014 at 10:39 PM, Marvin Addison <marvin.addi...@gmail.com > > wrote: > >> > SSL/TLS is mandate. Along with that I need to client-side password >> encryption also. >> >> I encourage you to reconsider. I realize that may be difficult if the >> requirements are dictated by a third party, but it's worth repeating >> that this is most likely a bad idea. In particular the key management >> issue is much harder than the cryptographic algorithm implementation: >> >> Successful key management is critical to the security of a >> cryptosystem. In practice it is arguably the most difficult aspect of >> cryptography because it involves system policy, user training, >> organizational and departmental interactions, and coordination between >> all of these elements. [1] >> >> If you can solve that problem in your encryption scheme, the code >> changes in CAS will be trivial by comparison and something you ought >> to be able to handle on your own. >> >> M >> >> [1] http://en.wikipedia.org/wiki/Key_management >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: >> np.sreej...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> > > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > cwaldbie...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
