Comments on: Tableless and Secure One-Time Password (OTP)

By: Amir Shevat

Amir Shevat — Fri, 12 Aug 2011 04:05:15 +0000

Hi Bill – Adding the user ID to the hash protects against OTP hijacking – without it an attacker can request and OTP for his user, then change the user ID to someone else and replace their password… adding the ID to the hash prevents that.

By: Saleh

Saleh — Thu, 11 Aug 2011 21:28:31 +0000

thanks amir, perfects

By: Bill

Bill — Mon, 18 Jul 2011 02:50:41 +0000

Can you elaborate on how an attacker would change user context? Adding user id to the hash doesn’t seem to add additional security to me.

By: seamoon_alice

seamoon_alice — Wed, 04 Aug 2010 07:53:38 +0000

Very interesting system, however it doesn’t completely isolate the problem of ’storing the state of the OTP’, basically the OTP lifespan is represented by the password of the user.
There are many places outside that area that needs an OTP that wouldn’t work with this logic.

This also means that even when you don’t need to store the OTP in the database during checks like in your case (which is very good), you still need the database to store the fact that the OTP is used up.

BUT (!) this means its an excellent solution for everything that is targeting a value in a database (could be something else like the email of the user). Nice article!

By: Jahufar

Jahufar — Mon, 24 May 2010 11:31:57 +0000

Very clever – solves all the problems with securely resetting a hashed password in one fell swoop.

Thanks for posting this!

By: Majic

Majic — Sun, 23 May 2010 22:55:34 +0000

very smart idea with clear instructions – I have bookmarked this for a future reread + full tryout

thanks very much

By: T0aD

T0aD — Fri, 21 May 2010 18:33:50 +0000

Very interesting system, however it doesn’t completely isolate the problem of ‘storing the state of the OTP’, basically the OTP lifespan is represented by the password of the user.
There are many places outside that area that needs an OTP that wouldn’t work with this logic.

BUT (!) this means its an excellent solution for everything that is targeting a value in a database (could be something else like the email of the user). Nice article!

By: anonymous

anonymous — Sat, 10 Apr 2010 01:40:43 +0000

thanks for this pretty clear and simple post on this topic, which is mostly known if you look at ‘attempts’ (i like yours a lot) by openid, twitter, fb auth etc…

But yeah, nice i love the numbered list description and outline of it thank you!

By: Amir Shevat

Amir Shevat — Tue, 09 Feb 2010 11:54:41 +0000

Thanks for your feedback!

The puzzle has 5 parts:
1) User (semi public)
2) Time (public)
3) User old password (super private)
4) Application salt (private)
5) hash function (public)

The Key is the old password – if you know the old password as a hacker then it is ‘game over’ – You can just login and do whatever you want (like change the password and email in the account area). If you do not know the password then a combination of the password and the application salt should be a strong seed for the one time password. Right?

Cheers
Amir Shevat

By: anonymous

anonymous — Tue, 09 Feb 2010 11:25:36 +0000

Amir – thanks for the heads up. This looks like a very clever solution!

I was initially concerned with the security, as;

I know the user I want to “hack”
I know today’s date.
I might guess the old password

SO it is possible I know or guess most of the puzzle, and could generate my own hash to pass in along with my spoofed time. Though I would think that the remaining salt and hash algorithm used should add enough variability to prevent such intrusions.

I am very interested to see some feedback from a security professional, because this looks like a great solution to a common need.