This line. ... generate a password for them, which we never send to them. This is the start of your design problem.
You generate a password which the user never knows. When the user returns your system expects the user to know the unknown password. No amount of software will solve this problem. What is the password protecting? If the DeviceID is globally unique perhaps you don't need a password, the Device itself can act as a password. On 14 February 2014 02:12, [email protected] <[email protected]>wrote: > So in our application (REST) we have the standard users with logging in > via username/password. However, we also have a login as guest. However, > guest users are still full users in our system. When a user signs in as > guest for the first time a request is sent with just a FingerPrint, this is > a HASH sent from the client to the REST api. To determine that this is the > first time this fingerprint/deviceID has been sent I do a db lookup WHERE > db.fingerPrint = loginRequest.fingerPrint. > > If it doesn’t return a record then that means it is a new guest and we > create a User instance and store it in the db. We generate a username > GuestNNN and generate a password for them, which we never send to them. If > it does return, then we take the userName from the db and the passed in > signature and create a SignatureAuthenticationToken, which just extends > UsernamePasswordAuthenticationToken and the constructor we pass in username > and fingerprint String. This works when we encrypt the fingerPrint with > PasswordService and store it encrypted. > > However, this does not work then on subsequent logins by that guest, > because in order to get the userName I have to query the db using the same > WHERE clause > WHERE db.fingerPrint = loginRequest.fingerPrint > > It fails because the incoming login request has the fingerPrint > unencrypted and the where clause will never match what is in the db, > because the db has it stored encrypted. > > If I try to just store the fingerprint in the db unencrypted, then the > login will fail because we are using PasswordMatcher with > DefaultHashService which will always take the fingerprint and encrypt it > and compare it to what is in the db, which is now unencrypted. So I am sort > of damned if I do, damned if I don’t. > > The login as guest request will always just have the fingerPrint, the > client will never know or send us the userName because it doesn’t know it. > > We can’t use rememberMe as unauthenticated user as guest because we need > to make them an actual user with data stored in the database that on > subsequent logins keeps their information etc. > > Any ideas? > > Thanks > > Mark > >
