Create New Fingerprint Programmatically

[David S Taylor]

Is there a way to create a new fingerprint programmatically and have it store in the sessionID cookie? I saw where two users had the same fingerprint in the redis session. To ensure this never happens, I was thinking I could just set a new fingerprint id in the cookie  every time a user logs in...

[Evan Tahler]

That's frightening!  Can you be sure that it wasn't a user who coppied his cookie over?

The fingerprint logic comes from this package: https://github.com/evantahler/browser_fingerprint

Can you create a reproducible test case where 2 separate browsers can get the same fingerprint?  You can see how we try to generate a unique hash for each request, which includes:

- client headers

- client IP

- random numbers

- process hostname

- process pid

- Date/Time

and then we sha1 the whole thing to generate the fingerprint

Rather than have options to change the fingerprint, I would like to *ensure* that it is unique.  One option might be to replace Math.random() with a true UUID generator...

[David S Taylor]

Can you create a reproducible test case where 2 separate browsers can get the same fingerprint?  

I could not reproduce it. I talked to the users, and they swear they never used the same machine. I can reproduce a similar problem in my app by one user being logged in, and then the second user navigating to the login dialog and logging in before the other user logs out (both users on the same machine). Thus, I thought I'd solve this by simply recreating the cookie on login.

I'd like to regenerate the fingerprint and store the sessionID cookie upon login. Is that possible?

 

[Clay Himmelberger]

Is your example that you reproduce locally on the same browser session? To actionhero, I think that would share the fingerprint. Perhaps you can clear the __browserFingerprint cookie when a user logs out (or when you navigate to the login screen)? That should regenerate on the server side. 

Will keep following this thread, it's an interesting one! Keep us posted what you find out : )

[Evan Tahler]

Well, cookies clobber each-other in the same browser.  If you have 2 tabs open in say Chrome, and you login twice, the second cookie will clobber the first, and you'll end up logged in as the same user at the same time in both tabs (potentially after reloading).   Assuming you do your test in different browser, we should be accounting for that by checking the remote connections' outgoing port, which must be unique even though they are both accessing port 80/443.  

[David S Taylor]

On Thursday, April 21, 2016 at 6:25:13 AM UTC-7, Clay Himmelberger wrote:

Is your example that you reproduce locally on the same browser session?

Yes. That was easy to reproduce. I can't explain how the two users, on two different machines, got the same fingerprint. That is a mystery to me.

 

To actionhero, I think that would share the fingerprint. Perhaps you can clear the __browserFingerprint cookie when a user logs out (or when you navigate to the login screen)? That should regenerate on the server side. 

Yes, thats what I am planning on doing, and disabling the login button if the user is already logged in. Seems that in this office where the problem occurred, its not uncommon for people to share computers, or for computers to be assigned to different users. So I need to improve on the long lasting cookie approach I've taken.

 

Will keep following this thread, it's an interesting one! Keep us posted what you find out : )

Will do. Hope to have some time to test this out soon....

[David S Taylor]

Well Im hacking about here, but I can't seem to find a way to set a cookie from an action. I was thinking maybe adding a header with

data.connection.rawConnection.responseHeaders

or setting the sessionID cookie here

data.connection.rawConnection.cookies

but I can't seem to make that work either way. Is there a way to set the sessionID cookie from an action with expiration? (I want it to expire immediately)

[Evan Tahler]

you are on the right track with `data.connection.rawConnection.responseHeaders`.  I would suggest setting the expiration date to be in the past, which is how you "Delete" a cookie, then on the next request (even just an AJAX API call) will get & set a new cookie.

Check this example: https://gist.github.com/evantahler/6e1ef37d8d5d270c68aba7f25a1ab644

[David S Taylor]

Check this example: https://gist.github.com/evantahler/6e1ef37d8d5d270c68aba7f25a1ab644

That worked perfectly. Thanks!