The problem of using salt in Shiro Jdbcrealm

General wording for creating users in Jdbcrealm:

 PublicString Register (user user) {RandomNumberGenerator Gen=NewSecurerandomnumbergenerator (); Bytesource Salt=gen.nextbytes (); String hashedPasswordBase64=NewSha256hash (User.getpassword (), salt, 1024). ToBase64 ();        User.setpassword (HASHEDPASSWORDBASE64);        User.setsalt (Salt.getbytes ()); Try{userdao.create (user); } Catch(SQLException e) {e.printstacktrace (); //Tood:log Error        }        return"Redirect:login"; }

One of the more troublesome questions in this is how the salt should be stored. The actual value returned by the Nextbytes () method is Simplebytesource, and some places use salt.tostring () directly as a string, Simplebytesource overrides the ToString method. The base64 encoding is actually returned. The problem is that JDBC does not use the data stored in this way.

Look at the Dogetauthenticationinfo method of Jdbcrealm:

protectedAuthenticationInfo Dogetauthenticationinfo (Authenticationtoken token)throwsauthenticationexception {usernamepasswordtoken Uptoken=(Usernamepasswordtoken) token; String username=Uptoken.getusername (); //Null username is invalid        if(Username = =NULL) {            Throw NewAccountexception ("Null usernames is not allowed by this realm.")); } Connection Conn=NULL; Simpleauthenticationinfo Info=NULL; Try{conn=datasource.getconnection (); String Password=NULL; String Salt=NULL; Switch(saltstyle) { CaseNo_salt:password= Getpasswordforuser (conn, username) [0];  Break;  CaseCRYPT://todo:separate Password and hash from getpasswordforuser[0]                Throw NewConfigurationException ("Not implemented yet"); //Break ;             Casecolumn:string[] QueryResults=Getpasswordforuser (conn, username); Password= Queryresults[0]; Salt= Queryresults[1];  Break;  CaseExternal:password= Getpasswordforuser (conn, username) [0]; Salt=Getsaltforuser (username); }            if(Password = =NULL) {                Throw NewUnknownaccountexception ("No account found for user [" + username + "]"); } Info=Newsimpleauthenticationinfo (username, Password.tochararray (), GetName ()); if(Salt! =NULL) {Info.setcredentialssalt (ByteSource.Util.bytes (salt)); }        } Catch(SQLException e) {FinalString message = "There is a SQL error while authenticating user [" + username + "]"; if(log.iserrorenabled ()) {log.error (message, E); }            //Rethrow any SQL errors as an authentication exception            Throw Newauthenticationexception (message, E); } finally{jdbcutils.closeconnection (conn); }        returninfo; }

You can see Jdbcrealm. The password and salt are read as strings, whereas Bytesource essentially holds a byte array. Dig down, actually using UTF-8 decoding string get byte[]. However, the problem is that string is not a byte can be stored, whether it is used internally by the JVM UTF-16, or the codec used here UTF-8, there is a certain format requirements. Not what byte[] can be put in and then taken out intact, not to mention the middle also passed a MySQL.

More importantly, there is no need to use string storage, ByteSource.Util.bytes itself has byte[] overload, and Base64 is not what encryption. There is no problem with directly storing the binaries. It's easy to implement. Rewrite dogetauthenticationinfo, use byte[] to create Simplebytesource.

The problem of using salt in Shiro Jdbcrealm