Re: hashPassword()?

[Brian Demers]

Take a look:
https://github.com/apache/shiro/blob/master/tools/hasher/src/main/java/org/apache/shiro/tools/hasher/Hasher.java

On Mon, Jan 29, 2018 at 8:55 AM, Olaf  wrote:

> That's the functionality I'm looking for. What's the corresponding Java
> class
> / function?
>
>
>
> --
> Sent from: http://shiro-user.582556.n2.nabble.com/
>

Re: RememberMeManager in Database

[Brian Demers]

>
> Thanks for the pointer. Don’t know that much about JWT. From looking at
> the code it seems you are storing the subject in the cookie. Like the
> current implementation does. This might be different from what we are
> trying to achieve. We don’t want the subject in the cookie, but in the
> database. Otherwise I can’t invalidate cookies for a segment of our users
> on the server side. Is my assumption correct?
>


Right, I just didn't know if the proposed encode/decode methods I proposed
to CookieRememberMeManager would make your code any easier

Re: hashPassword()?

[Olaf]

That's the functionality I'm looking for. What's the corresponding Java class
/ function?



--
Sent from: http://shiro-user.582556.n2.nabble.com/

Re: hashPassword()?

[Björn Raupach]

You can use the Shiro Command Line Hasher. 

$ java -jar shiro-tools-hasher-1.3.2-cli.jar -gs -p

It generates somethings like this:

$shiro1$SHA-256$50$E6PdauzOv8tHCyyUYSxOMQ==$HcTjCPThvdtntrRqxIrkaenilDlyMYBOb0Hb7VUfP5Y=

Shiro uses a so called modular crypto format. Salt, algorithm everything is 
stored in a single line.

The Credentials Matcher can interpret the modular crypto format.

> On 29. Jan 2018, at 10:28, Olaf  wrote:
> 
> I have, but it doesn't look like a good match.
> 
> Users shouldn't have to bother with salts. It should be like:
> 
> // String password;
> String hash = hashPassword(password);
> 
> bool ok = verifyPassword(password, hash);
> 
> It it's not available it might be nice to add it.
> 
> 
> 
> --
> Sent from: http://shiro-user.582556.n2.nabble.com/

Re: hashPassword()?

[Olaf]

I have, but it doesn't look like a good match.

Users shouldn't have to bother with salts. It should be like:

// String password;
String hash = hashPassword(password);

bool ok = verifyPassword(password, hash);

It it's not available it might be nice to add it.



--
Sent from: http://shiro-user.582556.n2.nabble.com/

Re: RememberMeManager in Database

[Björn Raupach]

Hi Brian,

thanks for your time!

> On 26. Jan 2018, at 17:03, Brian Demers  wrote:
> 
> Looks like a good start, I left a comment on the nonce logic.  My JDBC is a 
> little rusty though (which oddly makes me smile) so I might not be the best 
> person to look at that.

Thanks. Fixed it. Replaced my self-made random nonce generator with 
org.apache.shiro.crypto.SecureRandomNumberGenerator. 

My JDBC better be not that rusty, even though we usually stick to MyBatis for 
persistence logic. I think the wrapper around the statements is fine but the 
actual SQL statements are very customer centric. Meaning you need to adapt it 
to your database schema. No idea if there is a easier solution. I was just 
thinking about our use case and how we would implement it.

> 
> There is probably some logic we can bubble up 
> I almost forgot about this, but I was messing around with a JWT remember me 
> manager, a while back:
> https://github.com/bdemers/shiro/commit/31bbeff2b93f7ddcd2121aa30d69d9281e666981#diff-b7b4d173bb5d4b6d00aa3cecfa7cb861
>  
> 
> 
> If we create a encode/decode method that _should_ simplify your 
> implementation.  Thoughts?
> -Brian

Thanks for the pointer. Don’t know that much about JWT. From looking at the 
code it seems you are storing the subject in the cookie. Like the current 
implementation does. This might be different from what we are trying to 
achieve. We don’t want the subject in the cookie, but in the database. 
Otherwise I can’t invalidate cookies for a segment of our users on the server 
side. Is my assumption correct?

> 
> 
> 
> On Fri, Jan 26, 2018 at 8:10 AM, Björn Raupach  > wrote:
> Hi Brian,
> 
> know you are busy. Could you give me some feedback on this?
> 
> kind regards
> Björn
> 
> 
>> On 12. Jan 2018, at 16:44, Björn Raupach > > wrote:
>> 
>> Not sure where to talk about the proposed feature. JIRA Ticket? Mailing list 
>> or GitHub issue/pull request?
>> 
>> Anyways here is the link to the implementation: 
>> https://github.com/raupachz/shiro/tree/dbcookies 
>>  The class is called 
>> DatabaseRememberMeCookieManager.java
>> 
>> This is more or less a simple proof of concept, so we have something to talk 
>> about.I am also not very familiar with the internals of Shiro and the 
>> terminology. So please correct me.
>> 
>> DatabaseRememberMeCookieManager inherits RememberMeCookieManager. I have 
>> overriden the methods: getRememberedPrincipals(SubjectContext) and 
>> rememberIdentity(Subject, PrincipalCollection). getRememberedPrincipals 
>> retrieves the cookie value. rememberIdentity generates a random, non 
>> guessable nonce instead of the encrypted, serialized PrincipalCollection. 
>> Not sure what to call this value, I just went with nonce. This nonce and all 
>> the principals of the collection are written to a debase with jdbc.
>> 
>> getRememberedPrincipals reads the nonce from the cookie, if available, and 
>> retrieves the matching principals from the database.
>> 
>> The smoke tests do work :)
>> 
>> Open issues:
>> 
>> * Not sure how to get the proper realm name in getRememberedPrincipals. See 
>> the placeholder: “whatever" in the constructor of PrincipalCollection
>> * A nonce can have multiple principals and every principal can have multiple 
>> nonces.
>> 
>> The m:n relationship with nonces probably needs three tables. A select with 
>> joins would make a very long single line in shiro.ini. Would work, but it is 
>> not nice. The insert is even more complicated. Maybe it is better to not use 
>> shiro.ini in that case and let the user override some abstract method to 
>> load and store the principals. For example abstract loadPrincipals in 
>> DatabaseRememberMeCookieManager.
>> 
>> Hoping for a good discussion on this :)
>> 
>> Sorry if this message came several times. I keep forgetting what email 
>> address I use on different mailing lists.
>> 
>> /Björn
>> 
>>> On 10. Jan 2018, at 16:56, Rob Young >> > wrote:
>>> 
>>> I'd be interested to see this in action, I'd be happy to check out what you 
>>> get up to!
>>> 
>>> On Wed, Jan 10, 2018 at 10:25 AM, Brian Demers >> > wrote:
>>> Probably an override, you will still need to add the cookie, so you should 
>>> be able to override just what you need.
>>> 
>>> 
 
 Keep us posted!
>>> 
>>> Since we need this feature I can dedicate company time on this matter. Will 
>>> work on this in my repo and open a pull request once I have something 
>>> figured out. Might need some help troubleshooting. 
>>>  
>>> Cool!
>>> 
>>> 
>>> 
>>> -- 
>>> Rob Young
>>> robertjohnyo...@gmail.com 
>>> 
>> 
>