[TYPO3-dev] Password handling (Regarding youngest security issues)

[ries van Twisk]

On Nov 14, 2008, at 4:37 PM, Daniel Pšötzinger wrote:

> Xavier Perseguers schrieb:
>> Hi,
>>
>>>> Ok.. these are my thoughts.
>>>>
>>>> I'd be glad to get some feedback.
>>>>
>>>> Sebastian G.
>>> Good idea:
>>> the Install tool has this option allready "Encryption key:"
>>> and its used for cHash atm.
>>>
>>> Maybe use crypt with a extra salt instead of md5 - because in theory
>>> there are algorithm that can "calculate" some origns for a md5  
>>> hash imho.
>>
>> The point for using md5 at all is that it is present as well as a
>> JavaScript library which allow this cool feature of encrypting  
>> password
>> the way to TYPO3 from the BE login (it should be, as said, the  
>> default
>> option for FE login too). Changing the encryption means to find a
>> compatible library in JS. As there is still no md6 library  
>> available, we
>> may stick to sha1 which should be available as JS.
>>
>> Now another point is the challenge response from the BE login form in
>> superchallenge mode for instance. The way it works is following:
>>
>> TYPO3 sends a challenge as part of the form, the "password" or hash  
>> that
>> is sent back is
>>
>> hash = MD5( username :: MD5( password ) :: challenge )
>>
> The "extra" security you get by the JS Hash generation is that by
> sniffing the HTTP you haven't the password itself. But by sniffing you
> still have the possibility to login - since you only need to send what
> you sniffed..
>
> But the extra salt check can be done serverside - I see no need for  
> JS:
>
> From client (browser):  sendedpassword=MD5( password )   is send like
> it is now.
>
> On Server:  Hash(sendedpassword,username-salt) is checked against the
> database password.
>


You can also make sure you hide the password in the database in the  
first place
by simply removing select privileges from the regular DB user on a  
password table.
and let the authentication be handled using a  stored procedure that  
has access
to that table and returns TRUE or FALSE.

This still doesn't solve the problem of an admin/shell user gaining  
access to your server.
if that happens you can basically throw you server away and install  
something new.

Ries