[sldev] [VWR] Improving Authentication Security

[Dale Glass]

On Saturday 29 September 2007 13:54:42 Nicholaz Beresford wrote:

> Intro:
>
> If people decide to trust an application or it's source,
> there is no need to pamper them. 99% of the people are
> using the official viewer.  Letting them jump through
> some extra hoops, is [... (insert your choice of word here)].
Agreed here

> Same goes to the security vulnerability of "Remember
> password" or using brain dead or weak passwords.  If
> people want to use it, let them (which is what you do
> anyway).
Slight disagreement here. You can't stop people from doing insecure things, 
but you can offer them alternatives that are less insecure.

For example, add support for password managers. This will allow people to 
use completely random passwords, different for each service (I do this). 
This way at least you stop dictionary attacks, and removes the motivation 
to use one password for everything, which can be very dangerous.

>
>
> So, here is my suggestion:
>
> 1) Let the current login mechanism remain (maybe with
> increased security like using CRAM-MD5 instead of MD5
> which would have avoided the recent exploit).
Agreed here.


> 2) If there is a need to offer increased security for
> those who want it, have an option to generate a one time
> password on the website and either copy/paste that into the
> viewer's password field or *optionally* launch it via
> secondlife:// viewer (for convenience, where that works).
>
> Offer to generate lists of such passwords for printing/storing,
> e.g. to take with you for use in internet cafes, for use on
> devices or situations where no trusted browser is available
> (trusted enough to go to the website to log in with the
> master password to generate a one time password) or where
> www.secondlife.com is simply down.
I like that. It must be noted though that this is still not very secure 
though. If you login on an untrusted computer, it can be easily be set up 
with a malicious viewer, or to hiddenly patch your if you bring your own 
copy.

It must not possible to replay a request, inject a request, or modify a 
request. Last one probably not really possible on untrusted hardware.

> This approach is tried and trusted in the bank sector
> (at least in Europe), where it is called TAN (transaction
> number).  You get lists of 50 or 100 of those, each of
> which  can only used once for a transaction like a money
> wires, address change, etc.

As you say, it's not enough to have a one time password to login in a cafe, 
it must be a one time password per transaction (money transfer say)

This gets complicated quickly if you want to allow good functionality on 
untrusted systems. 

My suggestion is: Make limited and function-dependent passwords. For 
example, you generate a list of 10 passwords, which are to be used only 
for L$ transfers, and each password has its own associated limit, for 
example, from $5 to $100.

Then when doing a transfer from a cafe, you enter the password that's got 
the closest limit to the amount needed. In the event that your computer 
happens to be compromised, the limit is the most you can lose.


Now, all this assumes usage of untrusted hardware. If you have a trusted 
computer (your laptop) on an untrusted network (open access point), all 
that is really needed is SSL everywhere it's important.

>
> Make this a *CHOICE*, which people could engage if they
> are dealing with clients they don't fully trust or when
> logging into accounts which have valuable assets.
Agreed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070929/a78e6f27/attachment.pgp