Hi Les, Thanks very much for your answer - It confirms what I was thinking (I was just a little unsure about how SaltedAuthenticationInfo fitted into the picture).
I may need to add some custom logic for non-MCF formatted hashes but I will use the PasswordService (I might plug it in to our custom CredentialsMatcher (which will wrapper the PasswordService). Cheers, Stuart On Fri, Sep 13, 2013 at 8:37 PM, Les Hazlewood <[email protected]>wrote: > Hi Stuart, > > If you configure the PasswordMatcher on your Realm and use the > PasswordService in your code, you should be good to go: > > > http://shiro.apache.org/static/1.2.1/apidocs/org/apache/shiro/authc/credential/PasswordService.html > > The usage pattern is documented in that Javadoc, but the idea: > > The PasswordService returns MCF-formatted strings. You can safely store > those in the database in a single column. > Then, during an authentication attempt, your Realm can return > SimpleAuthenticationInfo instances (the 'credentials' constructor arg is > just the MCF-formatted String stored in your DB). > > The PasswordMatcher will internally use the PasswordService to do the > comparison. The PasswordService knows how to parse the MCF-formatted hash > string to obtain the hashing algorithm parameters - the raw submitted text > is hashed using these parameters, and then the output is compared with what > is stored in the DB. > > Using the PasswordService and MCF-formatted passwords is always a good > idea: you can upgrade hashing schemes over time and this won't break > existing stored passwords! This is usually a pretty mandatory for > production systems. Upgradability is _not_ possible without using > MCF-formatting schemes, so I would stick with the Shiro1 format for now (or > you can implement your own format if you prefer). > > I hope that helps! > > > -- > Les Hazlewood | @lhazlewood > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > > > On Fri, Sep 13, 2013 at 4:04 AM, Stuart Broad <[email protected]> wrote: > >> Hi, >> >> In a database along with the hashed password I am storing the hash >> algorithm, iterations and salt. Initially I planned to store these in >> separate columns but have recently come across some of the HashFormat >> classes (in particular Shiro1CryptFormat and ModularCryptFormat) and am >> confused on how best to use them. >> >> Originally I planned to return my own AuthenticationInfo (that extended >> SaltedAuthenticationInfo) with some additional information. But now I am >> thinking of storing the formatted hash (which includes the algorithm >> etc...) I don't think I need my own auth info. Even more I don't think I >> need the SaltedAuthenticationInfo since the salt will just be part of the >> formatted credentials (in a normal AuthenticationInfo). >> >> So my questions are: >> >> 1) If my password hash is formatted (as per Shiro1Crypt of ModularCrypt >> format) should I return just a simple AuthentiationInfo or a >> SaltedAuthenticationInfo? >> >> 2) Since we may change the algorithm over time what would be the best db >> field type/length to store the formatted password hash in? TEXT? >> >> Hope my question makes sense! >> >> Cheers, >> >> Stuart >> > >
