[TYPO3-50-general] Proposal for a RSA authentication provider/mechanism

[Andreas Förthner]

Hi,

> Hi Andi and happy New Year!

thanks! Same to you.

>> - We cannot secure the browser; I see no simple solution against key 
>> loggers and so on. (Graphical keyboards are not very usable, right?)
> 
> Even though that would be nice, it will never be 100% possible and 
> hopefully nobody's gonna expect that..
> But it's an interesting topic and there are some interesting approaches 
> out there (e.g. https://myvidoop.com/videos/signin-to-account)

Yes that was my impression, too. You can make it harder, but never 
impossible. So it will be just harder for the "normal" user to interact 
with the system. The bad boy will crack the system anyway, even with 
some nice features like the above.

>> - Message 1-3 from above shouldn't make any problems if someone reads 
>> them, right?!
> 
> If you only send a positive feedback when a valid username was given, 
> this could be abused to discover BE usernames which might be problematic..

Yes, you are right. Maybe we should always respond to the username 
message. If the user is not existant, we could answer with some random 
value?

>> - Replaying message 4 won't authenticate the user, as the challenge is 
>> no longer valid.
> 
> How do you plan to assure that a challenge is only valid for one 
> request? And will you include some kind of identifier (OS, Browser, 
> Cookie) to make sure it's the same client?

What we can definitely do is, that the challenge is invalidated after 
the first response arrived at the server. Then we still have the problem 
if the message got blocked or the attacker was just faster. You never 
can be sure that it's the same client. Therefore you would need message 
authentication (HMAC), but we could use some data like IP, Browser ... 
The problem is, all that data can be spoofed, but it make the bad boy's 
life harder I think.

>> (Man-in-the-middle attack).
> 
> I remember we were talking about this during the Transition Days. If 
> there is a "man in the middle", he could simply provide you with a 
> "fake" login page anyways..

True. We'll leave that for the browser guys ;-)

>> The only thing to avoid that, would be message authentication (HMAC) 
>> but that requires a shared secret between client and server or client 
>> certificates, which is probably not manageable for most people.
> 
> It would be great to support client certificates as an optional feature, 
> but I have no idea how complex that'd be.

I will definitely look into that, but I think certificate authentication 
can be handled with a completly own mechanism. So this would be the next 
more secure authentication provider.

>> - We definitely need JavaScript, which might be a bit ugly for "FE" 
>> Logins.
> 
> Yeah, that's a pitty and we should definitely add an obvious 
> noscript-warning to the login page!
> But providing a fallback solution is probably similar to hiding a copy 
> of your hi-tech safety key under the doormat ;)

;-)

> Good luck with the implementation, I'll happily betatest anything!

Thanks!

Greets Andi