authentication in cherrypy
James
I'm trying to set up an authentication scheme in my CherryPy webapp.
I've seen both simple and complex snippets of code in the Wiki, such
as:
http://tools.cherrypy.org/wiki/AuthenticationAndAccessRestrictions
http://tools.cherrypy.org/wiki/CustomSessionAuth
http://tools.cherrypy.org/wiki/NewAuth
http://tools.cherrypy.org/wiki/VeryVerySimpleAuthFramework
http://tools.cherrypy.org/wiki/MultiAuth
I've always found security to be a bit of a conundrum. I'm working on
a web application that requires some reasonable level of security. The
passwords are stored as a double-md5-hashed value in a database. I
don't have any issues "getting" the password out of the database, but
am curious as to the best method for creating and enforcing user
sessions when working on webapps. I remember reading many years ago
when studying PHP that setting sessions when working with web
applications is important: you shouldn't set the password in the
session, but setting the username only may result in weak security.
Does anyone have any opinions on the best way to attack security in a
CherryPy web application?
Thanks!
-j
Pete H
On Jul 8, 12:37 am, James <j...@nc.rr.com> wrote:
> All,
>
> I'm trying to set up an authentication scheme in my CherryPy webapp.
> I've seen both simple and complex snippets of code in the Wiki, such
> as:
>
> I've always found security to be a bit of a conundrum. I'm working on
> a web application that requires some reasonable level of security. The
> passwords are stored as a double-md5-hashed value in a database. I
> don't have any issues "getting" the password out of the database, but
> am curious as to the best method for creating and enforcing user
> sessions when working on webapps. I remember reading many years ago
> when studying PHP that setting sessions when working with web
> applications is important: you shouldn't set the password in the
> session, but setting the username only may result in weak security.
>
> Does anyone have any opinions on the best way to attack security in a
> CherryPy web application?
>
> Thanks!
> -j
help if your app is designed on RESTful lines. Though your mention of
sessions implies that may not be the case. It should be possible to
hook it into CherryPy's Sessions tool if you really can't avoid
sessions.
The tool uses expiring nonces to allow things like logout, forcible
logout after a set time, one-time access (ie force re-authentication
on every access), access control depending on the HTTP method, and a
simple role based authorisation scheme.
It's subject to most of the limitations of Digest Authentication,
except that replay attacks are limited by the nonce expiration
mechanism.
All the other attack possiblities are mitigated by using SSL, which
you will be in any case if you want any sort of security.
If I could work out how to add a new page to the Wiki I would - but it
doesn't seem to be possible to edit the Tools List page where the link
should go.
I can add a link to the Start page, but that's no use. How is it
supposed to be done?
Pete
It doe
Robert Brewer
> If I could work out how to add a new page to the Wiki I would - but it
> doesn't seem to be possible to edit the Tools List page where the link
> should go.
> I can add a link to the Start page, but that's no use. How is it
> supposed to be done?
http://tools.cherrypy.org/wiki/RestfulAuth gives me a 'Create this page'
button once I log in using the guest account. Do you not get that?
Robert Brewer
fuma...@aminus.org
Pete H
On Jul 8, 5:31 pm, "Robert Brewer" <fuman...@aminus.org> wrote:
> Pete H wrote:
> > If I could work out how to add a new page to the Wiki I would - but it
> > doesn't seem to be possible to edit the Tools List page where the link
> > should go.
> > I can add a link to the Start page, but that's no use. How is it
> > supposed to be done?
>
>
> Robert Brewer
So _that's_ what it means in the 'Steps to Add a New Wiki Page' item 3
in the Wiki Help.
<quote>
1. Choose a name for your new page. See WikiPageNames for naming
conventions.
2. Edit an existing page and add a hyperlink to your new page. Save
your changes.
3. Follow the link you created to take you to the new page. Trac
will display a "describe PageName here" message.
4. Click the "Edit this page" button to edit and add content to
your new page. Save your changes.
5. All done. Your new page is published.
</quote>
Seems step 2, which is where I got stuck, is irrelevant.
Thanks Robert, I'll get on and create a new page.
Pete
James
How hard is it to create a basic authentication scheme? I'm certainly
not a security guru and I'm aware that making one mistake could result
in a security hole. Some folks have indicated to me (privately) that I
should simply create a form, get the returned variables and then
compare the password to the database. If everything checks out I can
simply create a session and proceed with letting the user in to the
private sites.
Thoughts?
-j
arjuna
arjuna
--
Best regards,
arjuna
http://www.brahmaforces.com
James
That's one of the things I like about web frameworks like Django and
TurboGears; they seem to make it very easy to set up simple
authentication so that credentials are required to view certain pages.
I have poured over quite a bit of CherryPy documentation and haven't
really found any "great" article on how to write something simple,
very secure and straightforward...
Thoughts?
arjuna
There are some very simple examples. Like if you go to tools in the wiki the following seem quite straightforward:
Sylvain Hellegouarch
>
> I would also like to know.
>
> That's one of the things I like about web frameworks like Django and
> TurboGears; they seem to make it very easy to set up simple
> authentication so that credentials are required to view certain pages.
Except it isn't always as easy as you'd like when you need to extend it (I
had to write specific authentication support for Django and it hasn't been
an easy task because their documentation assumes only the easy path and
their code is not always straightforward).
>
> I have poured over quite a bit of CherryPy documentation and haven't
> really found any "great" article on how to write something simple,
> very secure and straightforward...
Because CP is just low-level. I mean what is secure to you might not be to
someone else. Basic auth+SSL is considered today as a default secure
mecanism for the web, is that good enough for you? Probably not.
What are your requirements? How do you consider security?
Eventually it'd be probably be great to have on single resource that
discuss all the options but that hasn't happened yet :)
- Sylvain
--
Sylvain Hellegouarch
http://www.defuze.org
Pete H
On Jul 9, 2:54 am, arjuna <brahmafor...@gmail.com> wrote:
> Hi James,
> Couple of years ago I had created a simple authentication. I am now looking
> to put the 'right' authentication from a security, simplicity and elegance
> point of view...Maybe we could share ideas, code and research to get a good
> authentication system up on our websites, as we go along. This could also
> help with the problem solving...
>
> On 7/9/08, James <j...@nc.rr.com> wrote:
>
>
>
>
>
> > Wow! Sounds like you went all out on your code. :)
>
> > How hard is it to create a basic authentication scheme? I'm certainly
> > not a security guru and I'm aware that making one mistake could result
> > in a security hole. Some folks have indicated to me (privately) that I
> > should simply create a form, get the returned variables and then
> > compare the password to the database. If everything checks out I can
> > simply create a session and proceed with letting the user in to the
> > private sites.
>
> > Thoughts?
> > -j
>
> > On Tue, Jul 8, 2008 at 5:47 AM, Pete H <pe...@ssbg.zetnet.co.uk> wrote:
>
> > > On Jul 8, 12:37 am, James <j...@nc.rr.com> wrote:
> > >> All,
>
> > >> I'm trying to set up an authentication scheme in my CherryPy webapp.
> > >> I've seen both simple and complex snippets of code in the Wiki, such
> > >> as:
>
> Best regards,
> arjunahttp://www.brahmaforces.com
I've added a Wiki page for my RESTfulAuth tool. All comments
(especially about bugs!) gratefully received.
Pete
arjuna
Also how does one transfer a password accepted in a form to a mysql database (request) securely. ie it has to be encrypted. Are the tools
tools.encode and tools.decode meant for this purpose?
arjuna
arjuna
1) Letting the server do it for you: I assume the server would handle the encryption decryption at each stage.This is the benefit. But pop up windows and other fixed functionality of the server would have to be tolerated.
2) Do it yourself: Encrypt using javascript on the client side (if this is possible) send it to the database encrypted or encrypt the whole user request containing the passowrd (can tools.encode be used for this?) Then do the enryption and decryption each time you read/write to mysql.
Any ideas on a simple valid approach to accomplishing a secure password back and forth to the server using cherrypy?
Sylvain Hellegouarch
> Does basic_auth also throw up a popup? On searching basic_auth in the wiki
> i
> dont find any documentation. Is there any documentation on using basc_auth
> or digest_auth (thats if they dont throw up a pop up box)
Nope. Well actually you can if you do it via XHR (Ajax to sound foxy) but
if the user doesn't put the valid credentials the popup will show up
anyway. Basically it's due to the way browsers implement RFC 2617.
<shamelessplug>
I had explained that in CherryPy Essentials actually ;)
Look there for some code on that subject:
https://code.cherrypyessentials.com/trunk/Chapter_8/
</shamelessplug>
- Sylvain
Robert Brewer
> Also how does one transfer a password accepted in a form
> to a mysql database (request) securely. ie it has to be
> encrypted. Are the tools tools.encode and tools.decode
> meant for this purpose?
No; tools.decode and enecode are for translating 7-bit HTTP strings to
unicode and back.
You probably want to encrypt passwords using md5 (or better).
Robert Brewer
fuma...@aminus.org
Pete H
On Jul 11, 12:08 pm, arjuna <brahmafor...@gmail.com> wrote:
> Thinking aloud, there could be two ways to authenticate. 1) let the server
> do it for you 2) do it yourself.
>
> 1) Letting the server do it for you: I assume the server would handle the
> encryption decryption at each stage.This is the benefit. But pop up windows
> and other fixed functionality of the server would have to be tolerated.
slightly different
depending on which browser is being used. Tha's one of the thinks
people don't like about
RFC2617 authentication.
>
> 2) Do it yourself: Encrypt using javascript on the client side (if this is
> possible) send it to the database encrypted or encrypt the whole user
> request containing the passowrd (can tools.encode be used for this?) Then do
> the enryption and decryption each time you read/write to mysql.
standard way?
And doing _anything_ at the browser in javascript that you can't or
don't completely verify at the
server is a seriously bad security lapse since it's trivially easy to
compromise at the client.
SSL/TLS is the proper tool for encrypting the packet stream between
client and server. Don't even
think of rolling your own.
<snip>
Pete
Sylvain Hellegouarch
>
>
> On Jul 11, 12:08 pm, arjuna <brahmafor...@gmail.com> wrote:
>> Thinking aloud, there could be two ways to authenticate. 1) let the server
>> do it for you 2) do it yourself.
>>
>> 1) Letting the server do it for you: I assume the server would handle the
>> encryption decryption at each stage.This is the benefit. But pop up windows
>> and other fixed functionality of the server would have to be tolerated.
>
> The popup window is actually provided by the browser, so it looks
> slightly different
> depending on which browser is being used. Tha's one of the thinks
> people don't like about
> RFC2617 authentication.
I don't think RFC 2617 specifies the login has to be requested bia a
popup. I think it's an implementation detail.
There are however issues with RFC 2617 nonetheless (the fact Digest is
hardly fully implemented correctly anywhere, questions with encoded
unicode data, etc.)
- Sylvain
Jim Jones
http://tools.cherrypy.org/wiki/AuthenticationAndAccessRestrictions
so far.
It provides common form based authentication with decorators.
The examples on that page will give you a good idea. It's very similar
to what TurboGears and django have, except that you get to implement the
actual authentication functions yourself. No ties to a specific database
scheme or even a database at all.
-jj
pko...@gmail.com
>> 2) Do it yourself: Encrypt using javascript on the client side (if this is
>> possible) send it to the database encrypted or encrypt the whole user
>> request containing the passowrd (can tools.encode be used for this?) Then do
>> the enryption and decryption each time you read/write to mysql.
>
> Why do it yourself when browser vendors have done it for you in a
> standard way?
out, Basic sends the password in the clear, digest is flaky...
>
> And doing _anything_ at the browser in javascript that you can't or
> don't completely verify at the
> server is a seriously bad security lapse since it's trivially easy to
> compromise at the client.
You are supposed to do validation serverside anyway.
>
> SSL/TLS is the proper tool for encrypting the packet stream between
> client and server. Don't even
> think of rolling your own.
Given you have enough resources for TLS (one IP for each domain, proper
cert from verisign and friends, CPU cycles). If you don't, doing client
side md5(password) is a proper solution.
cheers
Paul
Pete H
On Jul 12, 9:28 pm, "pkoe...@gmail.com" <pkoe...@gmail.com> wrote:
> >> 2) Do it yourself: Encrypt using javascript on the client side (if this is
> >> possible) send it to the database encrypted or encrypt the whole user
> >> request containing the passowrd (can tools.encode be used for this?) Then do
> >> the enryption and decryption each time you read/write to mysql.
>
> > Why do it yourself when browser vendors have done it for you in a
> > standard way?
>
> I humbly disagree. Basic/Digest auth has bad karma, i.e. you can't log
> out, Basic sends the password in the clear, digest is flaky...
>
password in clear - only to be used in conjunction wit SSL or for
cases where you don't really care if the password gets lost.
Why is Digest flaky? There were problems with older browsers, in
particular IE which would always use Basic if you gave it the choice,
but modern IE versions seem to handle it OK (>IE5.01).
>
>
> > And doing _anything_ at the browser in javascript that you can't or
> > don't completely verify at the
> > server is a seriously bad security lapse since it's trivially easy to
> > compromise at the client.
>
> You are supposed to do validation serverside anyway.
'validation' can't be trusted.
>
>
> > SSL/TLS is the proper tool for encrypting the packet stream between
> > client and server. Don't even
> > think of rolling your own.
>
> Given you have enough resources for TLS (one IP for each domain, proper
> cert from verisign and friends, CPU cycles). If you don't, doing client
> side md5(password) is a proper solution.
Jim Jones
> > SSL/TLS is the proper tool for encrypting the packet stream between
> > client and server. Don't even
> > think of rolling your own.
> Given you have enough resources for TLS (one IP for each domain, proper
> cert from verisign and friends, CPU cycles). If you don't, doing client
> side md5(password) is a proper solution.
Argh!
If you do client-side password hashing like that then you
can just send the password in the clear.
-jj
Eric Larson
>
>
>>> 2) Do it yourself: Encrypt using javascript on the client side (if this is
>>> possible) send it to the database encrypted or encrypt the whole user
>>> request containing the passowrd (can tools.encode be used for this?) Then do
>>> the enryption and decryption each time you read/write to mysql.
>>
>> Why do it yourself when browser vendors have done it for you in a
>> standard way?
> I humbly disagree. Basic/Digest auth has bad karma, i.e. you can't log
> out, Basic sends the password in the clear, digest is flaky...
>
One huge benefit of Basic/Digest is that many http libs support it out
of the box (httplib2 for example). As for logging out, if you resend
the 401 and stop accepting the authorized header, then the user is
effectively logged out.
>>
>> And doing _anything_ at the browser in javascript that you can't or
>> don't completely verify at the
>> server is a seriously bad security lapse since it's trivially easy to
>> compromise at the client.
> You are supposed to do validation serverside anyway.
>
I think one important point here is that you rely on browsers to
handle the actual logging in instead of dealing with forms, error
messages, etc. This may not be that advantageous if you want a slick
login form, but in the same way you might trust a library to support
some function, you can let the browser support this client side
action. Hopefully, you can rely on the experience, testing and
maturity of the browsers to handle things instead of doing everything
yourself.
>>
>> SSL/TLS is the proper tool for encrypting the packet stream between
>> client and server. Don't even
>> think of rolling your own.
> Given you have enough resources for TLS (one IP for each domain, proper
> cert from verisign and friends, CPU cycles). If you don't, doing client
> side md5(password) is a proper solution.
You bring up a good point. Yet, even if you don't have a signed cert,
it doesn't mean you are out of luck with encrypting the packet stream.
Again, if you have a client that is not a browser, something like
verisign certs may mean nothing.
One aspect I think is really helpful is that by using HTTP based
authentication, you can potentially benefit from many available tools.
I personally don't see why an HTTP auth dialog is so terrible, but
that doesn't it isn't to some people. That said, even if you are
rolling your own authentication scheme, it seems very helpful to
provide a standard HTTP based authentication pattern in order to
support non-browser clients easily.
Just my two cents!
Eric Larson
>
> cheers
> Paul
>
> >
>
James
don't believe it's possible for me to use it if the user passwords are
stored in a 'special' way in a database (such as a doubly-hashed
password, as I mentioned in my initial post).
Or am I wrong?
I hate to reinvent the wheel (it'd be great to simply call a cherrypy
function that ends up relying on http-based authentication), but I
don't see an alternative in my solution.
-j
--
"Do not meddle in the affairs of wizards, for they are subtle and
quick to anger."
-Tolkien
arjuna
>Nope. Well actually you can if you do it via XHR (Ajax to sound foxy) but
>if the user doesn't put the valid credentials the popup will show up
>anyway. Basically it's due to the way browsers implement RFC 2617.
>handle the actual logging in instead of dealing with forms, error
>messages, etc. This may not be that advantageous if you want a slick
>login form, but in the same way you might trust a library to support
>some function,
What is insecure about the following:
1) Accept a password in a form
2) Encrypt in javascript using MD5 (better than passing a clear text password)
3) Store in mysql encrypted either using the same MD5 or mysqls naitive encryption
4) When validating do the same as the above and check against database password.
Yes I could use ssl to transfer between the browser and server when i purchase the cert, but till then...This is better than passing clear text passwords.
I am great with using digest except for the popup login form assuming it would take care of security. is there any way around the pop up form?
arjuna
arjuna
Sylvain Hellegouarch
> The pop up is the problem. And if it is so standard, howcome none of the
> heavy weight sites dont use browser based authentication. For if they
> did, there would be pop up windows on gmail, amazon, facebook? Since
> there is no pop up it seems that most industrial websites dont use
> browser based authentication...?
They use home made authentication scheme. Have you looked at OpenID or
OAuth so that you rely on third-party providers to handle the
authentication?
- Sylvain
arjuna
Paweł Stradomski
> Hi All,
>
> What is insecure about the following:
>
> 1) Accept a password in a form
> 2) Encrypt in javascript using MD5 (better than passing a clear text
> password)
It's the same as sending it in the clear. If somebody intercepts the message,
then he does not need to know the real password, as it is sufficient to
resend the same md5 sum. To make it more secure you'd need to use some kind
of challange-response mechanism, where the md5 depends not only on the
password, but also on some one-use random token.
> 3) Store in mysql encrypted either using the same MD5 or mysqls naitive
> encryption
> 4) When validating do the same as the above and check against database
> password.
You'd be effectively just comparing value stored in the database to the value
sent over the network, without any encryption, as both would already contain
md5 of the password.
>
> Yes I could use ssl to transfer between the browser and server when i
> purchase the cert, but till then...This is better than passing clear text
> passwords.
Not much really.
--
Paweł Stradomski
pko...@gmail.com
cache ;(
cheers
Paul
arjuna
Tim Roberts
> How does PHP handle it? They dont have pop up login forms so I assume
> they are not using the protocol RF.. associated with digest. They must
> have custom foundation code to handle authentication. Cant we get
> something like this going for cherrypy, since everyone needs it. I
> know it would not be part of the core, but as a tool maybe...
How does PHP handle what? There are no automatic login forms built-in
to PHP. You have to create your own, or steal someone else's, just like
in CherryPy.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Jason Earl
> W liście arjuna z dnia wtorek 15 lipca 2008:
>> Hi All,
>>
>
>> What is insecure about the following:
>>
>> 1) Accept a password in a form
>> 2) Encrypt in javascript using MD5 (better than passing a clear text
>> password)
> It's the same as sending it in the clear. If somebody intercepts the message,
> then he does not need to know the real password, as it is sufficient to
> resend the same md5 sum. To make it more secure you'd need to use some kind
> of challange-response mechanism, where the md5 depends not only on the
> password, but also on some one-use random token.
This illustrates a very important point. Encryption is really easy to
get completely wrong. If you need something that is truly secure, you
probably need to borrow something that someone else has written.