Authenticating with Django without the password being sent to the server

2017-01-14 Thread 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?

-- 
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+unsubscr...@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.

Re: Authenticating with Django without the password being sent to the server

2017-01-14 Thread 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

On 14 Jan 2017 18: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. 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-developers+unsubscr...@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.
>

-- 
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+unsubscr...@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/CALs0z1bHYebAL0DPxOiamtMJ%2B8YDXbepHN%2BUFVH0nXMbh6dZRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Authenticating with Django without the password being sent to the server

2017-01-14 Thread 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"  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-developers+unsubscr...@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.
>>
> 

-- 
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+unsubscr...@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/81461daa-0eae-06e2-fd60-ea0c6e30fb04%40markusholtermann.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Authenticating with Django without the password being sent to the server

2017-01-14 Thread 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[1]. There 
used to 
be a Django enabled implementation[2], but it died a long time ago.
I don't know a well-maintained alternative and would welcome it in contrib.
-- 
Melvyn Sopacua


[1] http://srp.stanford.edu/
[2] http://code.google.com/p/srp-js/

-- 
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+unsubscr...@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/10016853.7t4lGTIvWU%40devstation.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - January 14, 2017

2017-01-14 Thread Tim Graham 


Triaged

---

https://code.djangoproject.com/ticket/27689 - 
FileSystemStorage().get_valid_name() may return empty string (wonfix)

https://code.djangoproject.com/ticket/27703 - Template language type 
annotations (needsinfo)

https://code.djangoproject.com/ticket/27701 - Document that runserver 
bypasses middleware for static files (accepted)

https://code.djangoproject.com/ticket/27716 - FieldFile incorrectly returns 
bytes the first time it is opened with 'r' (duplicate)

https://code.djangoproject.com/ticket/27720 - Confusing error message when 
creating a model with unspecified attributes that have no defaults 
(needsinfo)

https://code.djangoproject.com/ticket/27724 - SelectDateWidget clears date 
and month if year is not selected (accepted)

https://code.djangoproject.com/ticket/16575 - Allow specifying custom 
"empty" values for SelectDateWidget (duplicate)

https://code.djangoproject.com/ticket/27706 - Session key is not set when 
trying to log in, when another user's session cookie is sent with the login 
request (invalid)

https://code.djangoproject.com/ticket/27727 - Exclude with many condition 
in the same related field's fields (duplicate)

Reviewed/committed

--

https://github.com/django/django/pull/7815 - Fixed #27705 -- Added 
protocol/server_cls attributes to runserver for extensibility.

https://github.com/django/django/pull/7794 - Fixed #27688 -- Made messages' 
add_message() request check use ducktyping.

https://github.com/django/django/pull/6980 - Fixed #26961 -- Made admin 
checks run when DEBUG=False.

https://github.com/django/django/pull/7780 - Fixed #27673 -- Prevented 
system checks for contrib.admin during registration.

https://github.com/django/django/pull/7830 - Fixed #27714 -- Fixed small 
visual artifact when clicking inline edit button in admin.

https://github.com/django/django/pull/7827 - Fixed #27712 -- Reallowed 
Input widget's attrs argument to set the input type.

https://github.com/django/django/pull/6507 - Fixed #24452 -- Fixed 
HashedFilesMixin correctness with nested paths.

https://github.com/django/django/pull/7587 - Refs #16614 -- Added 
server-side cursor support for QuerySet.iterator() on PostgreSQL.

https://github.com/django/django/pull/7828 - Fixed #27713 -- Clarified 
NoReverseMatch error message when no view is found.

https://github.com/django/django/pull/7834 - Fixed #27721 -- Added 
interface name to shell's IPython/bython import error.

https://github.com/django/django/pull/7835 - Fixed #27723 -- Set 
MultiWidget's subwidgets input type from attrs argument.

https://github.com/django/django/pull/7623 - Fixed #27518 -- Prevented 
possibie password reset token leak via HTTP Referer header.

https://github.com/django/django/pull/7727 - Fixed #27718 -- Added 
QuerySet.union(), intersect(), except().
https://github.com/django/django/pull/6478 - Fixed #27149 -- Added Subquery 
and Exists database expressions.

-- 
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+unsubscr...@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/bd1f4892-fd01-4810-a9b4-dd6364e6fbf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Authenticating with Django without the password being sent to the server

2017-01-14 Thread 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


-- 
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+unsubscr...@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/b7b49d53-6dc7-4e58-a2e6-0dfce2d1a0b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.