dhis2-users team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Edward,

For DHIS2, it makes no difference. The attacker needs no salt. He just
needs a simple curl call with the username and the guessed password (which
means he needs no custom dictionary) . The password is transmitted in the
clear from the browser, so the internal details of how it encoded (with
salt)  in the database makes absolutely no difference, thus the incredibly
important need for SSL.

However, I do agree with you. Better password enforcement through stronger,
implementer defined patterns, as well as the ability to force user password
changes are things which we have discussed for some time now. No reason why
it could not be implemented.

Regards,
Jason


On Wed, Sep 5, 2012 at 12:23 PM, Edward Ari Bichetero <ebichete@xxxxxxxxx>wrote:

> 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
> >>
> >
>
>
>
>
>