mobile phone + password = 2 factor auth?

[Stephen John Smoogen]

On Tue, May 26, 2009 at 1:30 PM, Seth Vidal <skvidal at fedoraproject.org> wrote:
>
>
> On Tue, 26 May 2009, Eric Christensen wrote:
>
>> On Tue, May 26, 2009 at 15:13, Jeroen van Meeuwen <kanarip at kanarip.com>
>> wrote:
>>>
>>> Although this is entirely true, my bank sure considers my phone safe
>>> enough
>>> to send me one-time transaction confirmation codes that are only valid
>>> with
>>> the existing session.
>>>
>>> So, to hack this, you would need access to my phone as well as my current
>>> session.
>>>
>>> -Jeroen
>>
>> I'm glad your bank considers your phone safe enough.  But do you?
>> Your bank puts the security of your money in your hands which is fine
>> for them because it isn't their money.
>>
>> Remember, messages going through the Internet to the phone company to
>> your phone isn't encrypted or otherwise protected.
>
>
> Which is why it is 2-factor auth! You have to put bot the session key and
> the password you know together in order to auth.
>
> The bank is implicitly saying they don't trust the phone, nor do the trust
> your password, but if you have both of them..... then they trust that.
>

The bank has also put risk factors on how much money they can lose in
the inevitable case that both are compromised. Now the issue banks
don't cover usually is what they will do when the loses occur.

Those are the parts of deciding about a 2factor method.

1. how much risk are 'we' willing to take on,
2. how can we generally measure the risk a method has
3. does the estimated risk less than we what we are going to take.
and finally (the one most places skip)
4. what coverage do we have in place when the method breaks down.

All methods break down at some point. The question is the cost of the
method more or less what the organization wishes to pay.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"