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

[Andreas Förthner]

Hi all,

finally I’ve set up a protocol draft for the new RSA authentication 
mechanism. As it is always a good idea that many eyes look at security 
related topics I'll give you a detailed overview of my ideas:

Data stored on the server:

- In the user record (DB for TYPO3 4.x): username, public key, random 
number (salt), md5 hash of password+salt (No rainbow tables should exist 
for that hash?! ...hopefully)
- Somewhere else ;-) : The private key of a user. The so called 
WalletService is responsible for managing the private key data and all 
RSA cryptography on the server.


Login process:

1. Login screen is loaded and the client can input username and password.
2. The form first sends only the username to the server (probably an 
AJAX request).
3. The server responds with the corresponding public key for the given 
username and a random number (challenge).
4. The client encrypts password+challenge with the given public key 
(this is possible with JavaScript) and sends it to the server.
5. The Login Controller hands over the following data to the 
WalletService: username, current challenge, encrypted password+challenge 
string from the client, the hash from the user record, and the salt for 
this hash.
5.1. The WalletService knows the appropriate private key for the given 
user, decrypts the given password string, compares the challenge and if 
it's correct it generates md5(decryptedPassword+givenSalt) and compares 
it to the given value from the user record. If they're also equal, it 
sends back an OK to the login controller. -> Authentication succeeded.
5.2. In any other case, authentication failed.

Note:

- The challenge has to be valid for exactly one request.
- The idea behind the WalletService is to decouple the private data. I 
plan to provide an external binary, which handles the data out of the 
PHP/Webserver scope. Of course there has to be a fallback version for 
those not able to execute the binary on their server.


Possible attack vectors (All I could imagine, please tell me everything 
you see a problem with):

- We cannot secure the browser; I see no simple solution against key 
loggers and so on. (Graphical keyboards are not very usable, right?)
- Message 1-3 from above shouldn't make any problems if someone reads 
them, right?!
- Noone can decrypt message 4.
- Replaying message 4 won't authenticate the user, as the challenge is 
no longer valid.
- We have no chance to secure the communication between the 
Login-Controller and the WalletService from the PHP scope, so this is 
part of the OS.
- If someone can read the data from the user record, the salt should 
protect the password hash.
- The whole thing is about authentication, no protection of the session 
itself. So session hijacking is still a problem.
- If someone is able to block message 4, or read it and is faster than 
the original sender, he can authenticate himself once with that data 
(Man-in-the-middle attack). 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.
- The private key data (WalletService data) has to be protected with 
your life ;-), as soon as this data is stolen the security system is 
broken. However, it is not enough to have the private key and/or the 
data from the user record to authenticate. You need a valid 
authentication message (message 4) to decrypt the password string.
- DoS: As RSA implies very expensive calculations it is needed to set 
timeouts for each authentication request. Another idea would be client 
puzzles, but this is perhaps kind of overkill, as we don't decrypt too 
much data.


Advantages:

- The data in the user record is not directly usable for authentication 
(SQL-Injections)
- You need to break the WalletService (which is quite hard, if an 
external binary is used) AND need to sniff an authentication message.


Problems:

- We definitely need JavaScript, which might be a bit ugly for "FE" Logins.
- We need two messages from the client for authentication (message 2 and 
4) which leads to AJAX requests or a two-step authentication process.


So this was quite a lot. Please comment on it, ask every security expert 
you can reach, to make the login process more secure in the future. This 
is your chance ;-)

Thanks to all!

Greets Andi