-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree. If there are no objections, I'll revert and change initial_data.sql to use the hard-coded hashes this code generated.
Marlon On 8/12/11 10:32 AM, Franklin, Matthew B. wrote: >> -----Original Message----- >> From: Ciancetta, Jesse E. [mailto:[email protected]] >> Sent: Monday, August 08, 2011 9:11 AM >> To: [email protected] >> Subject: RE: [discuss] hashing, salting, and initial_data.sql >> >>> -----Original Message----- >>> From: Marlon Pierce [mailto:[email protected]] >>> Sent: Monday, August 08, 2011 8:59 AM >>> To: [email protected] >>> Subject: Re: [discuss] hashing, salting, and initial_data.sql >>> > Yes, but I was thinking about implementing a (hopefully) more elegant > solution. >>> >>> For what use case? The only thing I can think of where this might be useful >>> would be for moving users over from some other container to Rave -- but I >>> would think in that case you'd inevitably end up needing to write some kind >>> of >>> custom migration utility anyway and I'd see dealing with the passwords as >>> part >>> of that. > > >> + 1 > >> I just noticed that hashing and salting of passwords was added to the >> SqlFileParser class. This class (SqlFileParser) is very generic and can be >> used in any situation where SQL statements and child scripts are to be >> parsed from a file. The hashing and salting definitely does not belong in >> this class as it is unique to a particular table in a particular context. > >>> >>> Is there some other use case you have in mind? >>> > > Marlon > > > On 8/8/11 8:39 AM, Ciancetta, Jesse E. wrote: >>>>>> -----Original Message----- >>>>>> From: Marlon Pierce [mailto:[email protected]] >>>>>> Sent: Thursday, August 04, 2011 4:53 PM >>>>>> To: [email protected] >>>>>> Subject: [discuss] hashing, salting, and initial_data.sql >>>>>> >>>>> I'm looking at hashing and salting passwords stored in Rave's database. >>>>> This >>>>> works fine for new user accounts, but the demo accounts (canonical, >>>>> john.doe, etc) are a problem because they are inserted directly into the >>>>> DB > by >>>>> DataSourcePopulator.java by reading initial_data.sql. It would be possible >>> to >>>>> grok the "@user_id_" lines from initial_data.sql and hash the passwords > there >>>>> in SqlFileParser.java before inserting in the DB, but this would be an >>>>> ugly >>> and >>>>> fragile hack. >>>>> >>>>> >>>>> Other suggestions? Should we populate the database of demo users > through >>>>> JPA instead of inserting directly via SQL commands? >>>>> >>>>>> Is there some reason you can't salt and hash the passwords for the demo > accounts manually and then insert the pre-salted/hashed values directly into > the initial_data.sql file (with a comment block explaining what's being done > and what the actual passwords are)? >>>>> >>>>>> Admittedly not the most elegant solution, but seems good enough for > what we need to do. >>>>> >>>>> >>>>> Marlon > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJORTq/AAoJEEfVXEODPFIDn5gH/iHsuE9xshj1KStBJCOg0+oz KYr74mlN8BL7dWYAJZGf+OIN6SqDXeoH1O8IJYFjI38dZOD0+/RAsxmQa0KCzdb2 lPDCIxZZO5FBDoXYRxsBYr8TWWiOujcp42pAWazomNVp9KMyoFKqXa9X6BVB/krU POKTMPqtR+pn1TESJDOgBxdFiLdSYPn3cKkjYgAQDSjihESAz10ryDGmnEoCRk8B lZEwlZ4zzn1coQOr5fxNR1x2WQ54TrsxkYt9uq02ZsTXGeDIYMfqGKfgVEJ/0Ryw +3GNktB26uMVD9eVP7iITO1U2wOKK+xB+iLtejYA771lFLPYxYcllSck4XXeBeE= =aZSG -----END PGP SIGNATURE-----
