From: Scott M S. <sco...@jb...> - 2004-01-31 02:22:14
|
SHA is a one way hash that by definition cannot be reversed. In order to encode a password in a reversible form you need another password for the encoding/decoding, hence the question on how you want to encode the database password. If the database accepts a hashed form of the password then simply enter that. =20 xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx=20 =20 ________________________________ From: jbo...@li... [mailto:jbo...@li...] On Behalf Of Mark Wang Sent: Wednesday, January 28, 2004 4:43 PM To: jbo...@li... Subject: RE: [JBoss-user] how to encode database password in descriptor file mysql-ds.xml Scott: =20 Thank you for your reply. =20 Sorry I don't understand why you need another password.The user-name/password in mysql-ds.xml is the only user for jboss to communicate with mysql. At this moment, let's assume we need another password. Certainly, I can't get another user-name/pasword to encode the above from mysql-ds.xml. Can we try to get something from other database such as hsqldb-ds.xml(which I assume is embedded in JBOSS) or some flat files? Do we need to encode this password too? =20 Since I don't know your potential solution, my point is that the password in mysql-ds.xml should be encoded(using SHA for hashAlgorithm, base64 for hashEncoding) and JBOSS should be able to decode it when it gets it and use this decoded password to=20 connect to MySql database. I check the code UsersRolesLoginModule.java, there is no problem to encode a=20 password, but I don't know how JBOSS can decode this encoded password. My understanding is that for normal JAAS, the encoded password is stored, and when the input user-name and=20 password come, JBOSS will encode the input password and compare it with stored password. But in my scenario, we don't have the input password. =20 Anyway, could you/JBOSS provide a secure way (or a sample) to communicate with database? Right now the plain user-name and password are less secure. I think this will benefit the jboss application and expend far-reach of jboss. =20 Again thanks, =20 Mark =20 |