dhis2-users team mailing list archive
-
dhis2-users team
-
Mailing list archive
-
Message #01364
Re: Editing Usernames
Hello Jason,
Actually in the case where the username is the salt and there is a well known default super user
(such as "admin"), it is not a brute force attack. Not unless you randomly generate your password,
human-selected passwords have insufficient entropy.
When the attacker has access to the database it is simply a quick lookup in the relevant rainbow
table. Where the user doesn't have access to the database it is a dictionary attack, which is
significantly quicker than brute force for typical passwords.
I agree that encrypting the authentication sequence (via SSL/HTTPS) is important as well, but
we really should do better password hashing by default. Perhaps in the next release ? Or are there
factors I've overlooked in the codebase that prevent the addition of this feature.
- Edward -
________________________________
From: Jason Pickering <jason.p.pickering@xxxxxxxxx>
To: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
Cc: Edward Ari Bichetero <ebichete@xxxxxxxxx>; "dhis2-users@xxxxxxxxxxxxxxxxxxx" <dhis2-users@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 5, 2012 7:26 AM
Subject: Re: [Dhis2-users] Editing Usernames
The important issue is that even if an attacker was to get the encrypted password (which would generally require hacking into the database), and figure out how to decrypt it with a custom brute-force dictionary, it really makes no difference anyway, as they would have already gained access to the database and likely the machine. If they have access to the database and OS, well, then it does not really matter if you can hack in through the web interface with a brute force attack, as the game would be over. 99.9% of the time (at least) people are out for the server and not what is running on it.
So, in this case, regardless of the algorithm used to encrypt passwords, machine security and database security is of much more importance. If you have more serious requirements, use of certificates /VPN would dramatically increase the possibilities of brute force attacks.
Regards,
Jason
On Wed, Sep 5, 2012 at 1:26 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
Jason is right. The password is concatenated with a (weak) one way
>hash of the username (java.String.hashCode) and the md5 hash is
>calculated from that. It's not particularly cryptographically sound
>in today's day and age but is a legacy piece of code which we might
>and perhaps should consider updating for new passwords (whilst still
>supporting the existing ones).
>
>As a related aside, in Rwanda I advised system administrators to
>remove the "admin" user after they had created 2 or 3 users with
>superuser roles. Retaining an "admin" user simply increases your
>attack surface and encourages bad non-auditable practice.
>
>I do also agree with Jason that the larger risk is the security of the
>server and the network traffic.
>
>Regarding the number of attacks daily (particularly on ssh) I find
>that the simple measure of always moving sshd from port 22 to some
>other port reduces this number significantly.
>
>Bob
>
>
>On 4 September 2012 16:21, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
>> Hi Edward,
>>
>> It does not. There is not any random salt, but the password is salted with
>> the username. This method only attempts to prevent brute force attacks where
>> the user would have to develop a password dictionary for each user. A random
>> salt might be a better option, something to explore. However, the most
>> important issue with DHIS2 is that usernames/passwords must be transmitted
>> over SSL and that logs regularly monitored against brute force attacks.
>> Usually however, we see much more attacks on the server itself than the
>> application (usually dozens or hundreds a day).
>>
>> Regards,
>> Jason
>>
>>
>>
>>
>> On Tue, Sep 4, 2012 at 9:33 PM, Edward Ari Bichetero <ebichete@xxxxxxxxx>
>> wrote:
>>>
>>> Hello Bob,
>>>
>>> I hope the password hash uses a random component to 'salt' (permute) the
>>> hash in addition
>>> to the username, not just the username itself. Otherwise, this would
>>> present a cryptographic
>>> vulnerability into the system and any other systems where the user uses
>>> the same
>>> username/password combination. Especially, for usernames such as "root"
>>> and "admin".
>>>
>>> - Edward -
>>>
>>> ----- Original Message -----
>>> From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>> To: Muhire Andrew <muhireandrew@xxxxxxxxx>
>>> Cc: "dhis2-users@xxxxxxxxxxxxxxxxxxx" <dhis2-users@xxxxxxxxxxxxxxxxxxx>
>>> Sent: Thursday, August 30, 2012 12:22 PM
>>> Subject: Re: [Dhis2-users] Editing Usernames
>>>
>>> Hi Andrew
>>>
>>> A problem with modifying the username is that the password hash is
>>> also encoded and saved using the username as part of the hash
>>> algorithm. So in order to modify the username you would also need to
>>> reenter the password in order for it to be re-encoded. This might be
>>> problematic - even superusers don't necessarily know the passwords of
>>> the users.
>>>
>>> Bob
>>>
>>> On 30 August 2012 08:29, Muhire Andrew <muhireandrew@xxxxxxxxx> wrote:
>>> > Hi all,
>>> >
>>> > Dear dhis2 Users, i would suggest in DHIS2 to give
>>> > administrator/superusers
>>> > rights for modifying the existing username. At the moment its not
>>> > possible.
>>> > I think this can be helpful in case you need to make modifications on
>>> > some
>>> > usernames without deleting the whole staff.
>>> >
>>> > NB: only superusers, Because other users can make it worse. since most
>>> > of
>>> > these usernames are created with central level system administration
>>> > standards.
>>> >
>>> > Thanks!
>>> >
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-users
>>> Post to : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>
Follow ups
References