On Mon, Jun 13, 2011 at 6:36 AM, Mike Dewhirst <mi...@dewhirst.com.au>wrote:
> I need a choice of login mechanisms ... > > - Standard django-auth for some users > > - SMS a one time password for other users > > Would you think the following is the way to go? The user interface seems > clunky to me. Any feedback will be greatly appreciated. > As most users aren't used to having an 'otp' login, it's usually best to allow the user to configure this within their profile. I am actually working with a client at the moment to integrate SecurID tags with their Django webapp, slightly different implementation, but same concept. The way we are doing it with them, is only allowing the admin to attach the SecurID seed key, giving the user the standard login screen, then once logged in, if it requires OTP, it gives them a big security screen asking for the key. Depending on the nature of your webapp, you may want to allow clients to configure a phone number themselves, go through the confirmation steps, and also offer some sort of override. > > > 1. Enter the userid and optional password and submit > (if it is standard django-auth user then process as normal) > > 2. If the userid is recognised as a one-time-password user ... if the > password is absent or incorrect return a different error message saying to > check the cellphone for a new password and try again. > > 2.1 Get output from a random password generator > > 2.2 Change the django-auth password and send it via SMS > > 3. If the userid is recognised as a one-time-password user ... if the > password is correct then authenticate the user and change the password yet > again so it is guaranteed incorrect for the next login. > Actually changing the password to whatever is sent via SMS is not a good way forward. Not only will this be db write-intensive if you scale out, but also leaves you open to race conditions within the auth system, unless you have a distributed objecting locking mechanism in place. Ideally, you'd want to store the OTP (sent from SMS) in a caching server (or db if you want to save it for retention purposes), validate the user again their standard user/pass, then ask for the OTP once they have passed the login screen. The downside to this approach is that someone can at least find out if a user/pass is valid, without needing the OTP, but can't get any further. If you disliked this, you could ask for the OTP (without validating the user/pass first), then validate it all in one chunk after they entered the OTP. Personally, I'd prefer the first (at the slight loss of some security). Hope this helps > Thanks > > Mike > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
