digest_auth under 3.0beta

Having read http://www.ietf.o
rg/rfc/rfc2617.txt it is clear that digest
authentication is better than basic.

However, if you look at
http://www.cherrypy.org/browser/trunk/cherry
py/test/test_httpauth.py
(reccommended for 3.0) it seems to suggest that the
user/pass pairs
stored on the server for digest are normally stored in plain
text,
whereas for basic the passwords are stored hashed. Writing
down
passwords in plain text anywhere does not seem a good idea.

Maybe I've missed something.

Paul Hide


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups-beta.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

Hi Paul,

paulh wrote:
> Having read http://www.ietf.o
rg/rfc/rfc2617.txt it is clear that digest
> authentication is better than basic.
> 
> However, if you look at
> http://www.cherrypy.org/browser/trunk/cherry
py/test/test_httpauth.py
> (reccommended for 3.0) it seems to suggest that the
user/pass pairs
> stored on the server for digest are normally stored in
plain text,
> whereas for basic the passwords are stored hashed.
Writing down
> passwords in plain text anywhere does not seem a good
idea.
> 
> Maybe I've missed something.

Well digest_auth works that way because Digest does not
transmit the
password within the HTTP message. Instead the client forges
a message
based on a token sent by the server and the password
provided by the
client. The server uses the same algorithm with the same
token and the
server stored on the server. If the server computation
matches the one
sent by the client then the authentication is agreed.

The problem as you can see is that the server can only work
on the
password as the user will input it.

There would be two ways to workaround that however:

1. Keep your passwords encrypted and decrypt them on the fly
within the
function to retrieve them ('tools.digestauth.users'
parameter).

2. Change quite a lot the internal httpauth.py module
provided within
CherryPy so that instead of computing the H(A1) value we get
it from the
server. The H(A1) value is the hash value of the password,
realm and
password. The server could store that value.

Both solutions have their issues and I'm not usre which one
is best.

BTW, there is an ongoing discussuing over at IETF_HTTP-WG
regarding
updating RFC 2617 [1].

- Sylvain

[1] http://lists.w3.org/Archives/Public/ietf-
http-wg/2006JulSep/thread.html

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups-beta.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---

Hi Sylvain - thanks for the reply and suggested workarounds:
of the
two, I prefer the first. I have hacked around with bits of
cherrypy in
the past and I have generally made things worse for myself.

I looked at the discussion about changes to RFC 2617; looks
a long way
off to me.

I would be interested to hear from other cp users what is
regarded as
best practice for the storage of user/pass on a server.

Paul Hide

On Oct 17, 11:06 am, Sylvain Hellegouarch <s...defuze.org> wrote:
> Hi Paul,
>
> paulh wrote:
> > Having readhttp://www.ietf
.org/rfc/rfc2617.txtit is clear that digest
> > authentication is better than basic.
>
> > However, if you look at
> >http://www.cherrypy.org/browser/trunk/cherry
py/test/test_httpauth.py
> > (reccommended for 3.0) it seems to suggest that
the user/pass pairs
> > stored on the server for digest are normally
stored in plain text,
> > whereas for basic the passwords are stored hashed.
Writing down
> > passwords in plain text anywhere does not seem a
good idea.
>
> > Maybe I've missed something.Well digest_auth works
that way because Digest does not transmit the
> password within the HTTP message. Instead the client
forges a message
> based on a token sent by the server and the password
provided by the
> client. The server uses the same algorithm with the
same token and the
> server stored on the server. If the server computation
matches the one
> sent by the client then the authentication is agreed.
>
> The problem as you can see is that the server can only
work on the
> password as the user will input it.
>
> There would be two ways to workaround that however:
>
> 1. Keep your passwords encrypted and decrypt them on
the fly within the
> function to retrieve them ('tools.digestauth.users'
parameter).
>
> 2. Change quite a lot the internal httpauth.py module
provided within
> CherryPy so that instead of computing the H(A1) value
we get it from the
> server. The H(A1) value is the hash value of the
password, realm and
> password. The server could store that value.
>
> Both solutions have their issues and I'm not usre which
one is best.
>
> BTW, there is an ongoing discussuing over at
IETF_HTTP-WG regarding
> updating RFC 2617 [1].
>
> - Sylvain
>
> [1]http://lists.w3.org/Archives/Public/ietf-
http-wg/2006JulSep/thread.html


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at ht
tp://groups-beta.google.com/group/cherrypy-users
-~----------~----~----~----~------~----~------~--~---