[imp] 2-Step Authentication

[Simon Brereton]

On Apr 19, 2012 3:48 AM, "Michael M Slusarz" <slusarz at horde.org> wrote:
>
> Quoting Andrew Morgan <morgan at orst.edu>:
>
>> I'm not sure where you are getting your information from - unless you
think Google's 2-step verification via a cell phone is not actually
2-factor authentication?  Since a hacker won't have access to your phone,
they cannot retrieve the one-time PIN generated by Google and sent to your
phone.
>
>
> I didn't say this wasn't 2-factor authentication.  Of course it is.  But
what does that mean?  2-factor authentication in and of itself doesn't
imply any sort of additional security.
>
> AFAICT, with Google's system you could have a password like "password".
 You then get a PIN such as "123456".  So your password essentially becomes
"password123456".  Don't see how this is any different than forcing a user
to have a password of at least 12 characters, and having this password
expire every 30 days.

But that's not how it works.  Think of the cell phone more of an RSA token
than an SMS.  Your other points not withstanding (and there a large FUD
factor in that article, I admit), even a password like password becomes
more secure if you have to tack on a random 6 figure number.

And yes, I realise for the majority it amounts to a 30 day expiration - but
the real value is in having to get a unique random 6 figure number for
every access terminal (in a shared computer environment like a university
that becomes very effective).

It was just something to think about.

> Especially since almost every sane user is NOT going to have the PIN sent
to them on every email access.  They are going to have the PIN sent to them
once every 30 days.  (I will say that having the PIN sent every time is
similar to the RSA keyfob security method, although not as secure since the
PIN has to be delivered via the cellular network).

That's exactly how it works though!  The app sits there generating a PIN
every minute - just like the key fob.

> Not to mention that if you REALLY care about security, you're not going
to have Google host your data anyway.

Which is why I'm asking here :)

>> Sending an SMS message to an arbitrary cell phone number is hard though.
Most providers have email-to-SMS gateways, but that requires getting more
information from the user than just their cell phone number.  You need to
know their carrier in order to lookup the email gateway from a list, or the
user must provide the full email-to-SMS gateway email address for their
phone.  Sending "real" SMS messages requires getting a special cell card
from a carrier and signing a contract saying how many messages you'll be
sending.
>
>
> You simply can't require SMS for anything.  Cell service is not
universal.  And plenty of people don't have SMS, because of cost (e.g. my
parents) or because of technical reasons (I have friends who work in the
finance industry who, because of SEC regulations, are not allowed to
receive SMS messages).
>
> It seems to me that a OTP system is preferable to any kind of system that
requires an additional network.  Especially with the prevalence of
smartphones, it is trivial for a user to carry around the pad (which used
to be the limiting factor in implementing).  It implements no further
requirements than Google's 2-factor system  since both require a phone, and
has the additional bonuses of being easier to implement and, if implemented
correctly, 100% secure.
>
> My point being that at a practical level, you can provide secure
passwords easier/more reliably by enforcing appropriate password policies
rather than by adding additional levels to the process.

I don't think - for reasons outlined - SMS is not feasible, and that's why
the Google Authenticator app works so well...

Simon