Authenticating with Django without the password being sent to the server

[Chris Priest]

The way django's authentication system works is that when you register, you send the password to the server, then the server runs that password through some hashing algorithms, then the resulting hash is stored in the database. When the user logs in, the password again is sent to the server, and the hash is calculated and then compared to the hash that was calculated when they registered.

This results in the plain text password not being stored in the database, but the password is still being sent back to the server. A better way would be for the hash to be calculated on the front end, in javascript, and then sent back to be stored in the database. This way, the user *knows for sure* that the password isn't being saved in plain text because the server doesn't even know the plain text password.

Has anyone ever tried building an authentication system that worked this way? If someone built such a thing, could it get included in django contrib?

[Anthony King]

Chris, then the password is the hash itself. It doesn't really have any security benefits. 

Disclaimer: I'm not a security expert

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/440694cb-853e-4150-a356-1f176f59b3c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Markus Holtermann]

That's as correct, Anthony. Any you then want to hash the hash so that
you can't just login knowing the hashed password when the database is
leaked. Essentially you haven't won anything.

Second, how do you make sure the JavaScript is properly transmitted and
doesn't contain any code that sends off the credentials anywhere else?
TLS encrypted connections? Well, then I trust the encryption and can
just send the plain-text password. Or I don't trust the encryption and
I'm screwed either way.

/Markus

On 01/14/2017 07:32 PM, Anthony King wrote:
> Chris, then the password is the hash itself. It doesn't really have any
> security benefits.
>
> Disclaimer: I'm not a security expert
>
> On 14 Jan 2017 18:24, "Chris Priest" <cp36...@ohio.edu> wrote:
>
>> The way django's authentication system works is that when you register,
>> you send the password to the server, then the server runs that password
>> through some hashing algorithms, then the resulting hash is stored in the
>> database. When the user logs in, the password again is sent to the server,
>> and the hash is calculated and then compared to the hash that was
>> calculated when they registered.
>>
>> This results in the plain text password not being stored in the database,
>> but the password is still being sent back to the server. A better way would
>> be for the hash to be calculated on the front end, in javascript, and then
>> sent back to be stored in the database. This way, the user *knows for sure*
>> that the password isn't being saved in plain text because the server
>> doesn't even know the plain text password.
>>
>> Has anyone ever tried building an authentication system that worked this
>> way? If someone built such a thing, could it get included in django contrib?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to django-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.

>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/440694cb-853e-4150-a356-
>> 1f176f59b3c7%40googlegroups.com

>> <https://groups.google.com/d/msgid/django-developers/440694cb-853e-4150-a356-1f176f59b3c7%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

[Melvyn Sopacua]

On Saturday 14 January 2017 10:24:24 Chris Priest wrote:

> The way django's authentication system works is that when you

> register, you send the password to the server, then the server runs

> that password through some hashing algorithms, then the resulting

> hash is stored in the database. When the user logs in, the password

> again is sent to the server, and the hash is calculated and then

> compared to the hash that was calculated when they registered.

>

> This results in the plain text password not being stored in the

> database, but the password is still being sent back to the server.

 

The solution is to use SRP, originally coined by Stanford University. There used to be a Django enabled implementation, but it died a long time ago.

I don't know a well-maintained alternative and would welcome it in contrib.

--

Melvyn Sopacua

[Florian Apolloner]

I am not going to comment on the security side of things here, since as others already commented: you do not win much security wise. If you are worried about plaintext password leaks via MITM, use TLS - period

On Saturday, January 14, 2017 at 7:24:24 PM UTC+1, Chris Priest wrote:

Has anyone ever tried building an authentication system that worked this way? If someone built such a thing, could it get included in django contrib?

Yes, there are plenty of such systems out there. The chances of including that in django.contrib are roughly zero, first and foremost Django auth backends do not depend on frontend stuff, ie cannot rely on JS being available. And without sub-resource integrity and end-to-end visibility of that integrity there is no way I see such a system to be useful. TLS+cleartext password or SPNEGO are imo the way to go forward.

Cheers,
Florian

[Rob]

I'm not sure why you think that would be a better way?  Assuming you are already using TLS correctly (2048 bit keys, TLS v1.2, proper cipher suites, forward secrecy, etc. etc.) a simple way to achieve much higher security is to support two factor authentication.

There are a number of systems for doing what you at trying to achieve (SRP is mentioned in another thread) but all of those are attempts to deal with significant man-in-the-middle concerns, not general we security.

If you actually do have to deal with significant MITM concerns you really need a security expert on your team.

In actuality, if you are doing things right, the biggest security issues are exploits on the client side (viruses, phishing, key-loggers) and incursions into your infrastructure.

Rob.