Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>SaltedAuthenticationInfo</h2> <p><code>SaltedAuthenticationInfo</code> is an interface. The Shiro API provides a number of default implementations for convenience. As much as possible try to use one of the default implementations; avoid creating your own.<br> I suggest <code>SimpleAuthenticationInfo</code> which implements more than just <code>SaltedAuthenticationInfo</code> but will probably suffice for your purposes.<br> See <a href="http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/SimpleAuthenticationInfo.html" rel="noreferrer" title="Shiro JavaDoc">org.apache.shiro.authc.SimpleAuthenticationInfo</a> for more information. </p> <p>If you absolutely need to implement your own <code>SaltedAuthenticationInfo</code>, you should follow the documentation carefully.<br> See <a href="http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/AuthenticationInfo.html" rel="noreferrer" title="Shiro JavaDoc">org.apache.shiro.authc.AuthenticationInfo</a> and <a href="http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/SaltedAuthenticationInfo.html" rel="noreferrer" title="Shiro JavaDoc">org.apache.shiro.authc.SaltedAuthenticationInfo</a> for more information. </p> <h2>HashedCredentialMatcher</h2> <p><code>boolean doCredentialsMatch(AuthenticationToken, AuthenticationInfo)</code> actually takes care of the authentication logic.<br> This method takes the user-submitted credentials in the form of an <code>AuthenticationToken</code> and compares them to the previously stored credentials in the form of <code>AuthenticationInfo</code>.<br> You have to make sure that you pass all the necessary information to <code>HashCredentialMatcher</code> first though (iterations, algorithm, and a salt in the <code>SaltedAuthenticationInfo</code>). </p> <p>pseudo-example use,</p> <pre><code>final int iterations = 50000; AuthenticationToken authToken = ...; SaltedAuthenticationInfo saltedAuthInfo = ...; HashedCredentialsMatcher authenticator = new HashedCredentialsMatcher(Sha256Hash.ALGORITHM_NAME); authenticator.setHashIterations(iterations); final boolean successfulAuthentication = authenticator.doCredentialsMatch(authToken, saltedAuthInfo); </code></pre> <p>See <a href="http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/credential/HashedCredentialsMatcher.html" rel="noreferrer" title="Shiro JavaDoc">org.apache.shiro.authc.credential.HashedCredentialsMatcher</a> for more information.</p> <h2>Other security notes</h2> <ul> <li><p><strong>Salt length</strong><br> 256-bit salt looks good. With a salt that large you minimize the risk of any two users sharing the same salt. Keep in mind when picking a salt length that the <a href="http://en.wikipedia.org/wiki/Birthday_problem" rel="noreferrer">Birthday Paradox</a> comes into play. </p></li> <li><p><strong>Number of iterations</strong><br> As a rule of thumb you should <em>never</em> use less than 10,000. You currently use 512, </p> <pre><code>String hashedPasswordBase64 = new Sha256Hash(inPassword, salt, 512).toBase64(); </code></pre> <p>Most hashing algorithms are extremely fast (sha256 included), you don't want to do any would-be hackers any favors. The more iterations you use the slower authentication will be, but it directly slows down cracking attempts as well. </p> <p>You will want to set the number of iterations as high as possible while still maintaining an acceptable responsiveness for your application. You may be surprised how high you can go.<br> Personally I tend to use millions; but I am paranoid and don't mind a slight delay<br> See <a href="http://en.wikipedia.org/wiki/Key_stretching" rel="noreferrer">Key Stretching</a> for more information.</p></li> <li><p><strong>Personally I would avoid hard coding any of the hashing parameters (hashing algorithm, salt size, iteration count, ect)</strong><br> By hard coding these values you limit your immediate ability to adapt and respond. </p> <p>Storing these values with the hashed credentials allows you to make a more dynamic authentication where you can configure and roll out stronger algorithms in the future with relatively little effort. </p> <p>For example your default hashing algorithm may be sha256 using 50,000 iterations and a 256-bit salt. In the future though 50,000 iterations may not be enough.<br> Without much fuss you would be able to change the preferred algorithm configuration to iterate 100,000 times for all new passwords. You don't have to worry about breaking old passwords because you are not changing the algorithm parameters that you stored with existing credentials. You can also use this to change the salt-size or even the algorithm altogether. </p> <p>If desired you can then make everyone to change their password; forcing users pick up the new (hopefully stronger) preferred algorithm setup.<br> The Unix operating system has done this for years with <a href="http://en.wikipedia.org/wiki/Shadow_password" rel="noreferrer">/etc/shadow</a>. </p> <p>It takes a bit more effort up front, but it's worth the investment. Strong authentication controls are critical. </p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POHow to use the Shiro's SaltedAuthenticationInfo?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USJared Paolin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to use the Shiro's SaltedAuthenticationInfo?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for your help. I think my problem is I don't use the same Credentials Matcher's params. I don't give the right algorithm name to the credential. I will test this.
      singulars
      1. PO
      1. USFred37b
    2. CO@Fred37b no problem. As noted above, make sure you set all the appropriate parameters on the `HashedCredentialMatcher`, including the number of iterations.
      singulars
      1. PO
      1. USJared Paolin
    3. COMy method buildAuthenticationInfo(String username, char[] password) which create a AuthenticationInfo or SaltedAuthenticationInfo does not work at all. I don't create a correct AuthenticationInfo object.
      singulars
      1. PO
      1. USFred37b
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload