Re: [Repoze-dev] repoze.what-pylons question
I'm not exactly sure, but I've done some similar things which have
worked, so I might be able to help out. First of all, instead of
using default, you should probably be using __call__, like in:
http://projects.mayle.org/hg/DVDev/file/c0c8da51a663/dvdev/controllers/mercurialgateway.py#l44
But what's more likely causing the problem is using the protect_action
instead of ControllerProtector, like in:
https://source.openplans.org/hg/communityalmanac/file/d5eaab92ec5c/communityalmanac/controllers/admin.py
#l20
Douglas Mayle
On Sep 16, 2009, at 9:14 AM, Iain Duncan wrote:
> Hi folks, not sure if this should be on pylons or here. I'm using the
> repoze.what pylons quickstart code, and I'm having problems with the
> fact that when @protect_action fails, it tries to call the login
> action
> *for the current controller*. This is causing me pain when my
> controller
> is a wsgi wrapper ( to a bfg app ) because I have routes that gobble
> all
> sub paths and pass them on to the bfg app. So instead of /login
> going to
> the route controller, it gets eaten up. I have hacked around it by
> having routes rules like so:
>
> map.connect('/admin', controller='admin', path_info='/', )
> # need next rule else third admin rule will catch /admin/login
> map.connect('/admin/login', controller='root', action='login')
> map.connect('/admin/
> {path_info:.*}',controller='admin',action='default' )
>
> but it doesn't seem so elegant. Can anyone tell me why the following
> tries to call /admin/login and not the root /login, and how to change
> that behaviour.
>
> ( here's the controller in question ):
>
> # longhanded way of wrapping dram so we can use repoze.what decorators
> class AdminController(BaseController):
>def __init__(self, *args, **kwargs):
>BaseController.__init__(self, *args, **kwargs)
>self.dram = DramApp(package=ymh.model, global_config=config)
>
>@protect_action(has_permission('administrate')
>def default(self, environ):
>response = self.dram(environ, self.start_response)
>return response
>
> So in the above when the protect_action fails, it tries to take me
> to /admin/login, which I don't want.
>
> let me know if this should have gone to pylons!
> iain
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Is it possible to integrate repoze.plone and Pylons in one WSGI application?
It depends on how basic your CMS needs are. The Pylons Book contains a simple CMS called SimpleSite that you could probably integrate, if your needs were light. http://pypi.python.org/pypi/SimpleSite/0.3.0 http://pylonsbook.com/en/1.0/starting-the-simplesite-tutorial.html http://pylonsbook.com/en/1.0/simplesite-tutorial-part-2.html http://pylonsbook.com/en/1.0/simplesite-tutorial-part-3.html Doug On Jun 18, 2009, at 2:03 PM, Edwin Chu wrote: Hi all I am working on a project using Pylons and I need to add CMS functionality to that Pylons project. I am looking for some existing CMS solution that can be integrated into Pylons WSGI pipeline. The requirements of the CMS are basic, like editing page content, menu and probably handling images. repoze.plone is the only CMS I can find using WSGI standard. Is it possible to add repoze.plone to Pylons's WSGI pipeline so that they can be ran in the same process? I googled a while but nothing useful was found. Thanks Regards Edwin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Identifier plugins...
I've been doing some testing of a new site, and I've used repoze.who and repoze.what for authentication, and authorization respectively. I did notice one unusual behavior with AuthTktCookiePlugin, however. If I log in to the site, I receive an auth_tkt cookie. Once I have that, I drop and recreate the database, as well as cleaning out any server side session data. Having done all that, I imagine that my environment is a clean slate, yet the predicate not_anonymous returns true, even though I haven't logged in yet. That's because the credential data coming from client cookie is entirely trusted. I was imagining some sort of collaboration between the client and server, such that the client cookie was just an index into a session. Now, I could just write an identifier that uses the session for storage, which would use the two in sync, but I wanted to make sure that: 1) This wasn't a known problem, or 2) there isn't already some other identifier plugin that satisfies my needs.. (The other possibility is just a stricter predicate, is_valid_user, I suppose, but then I'm still trusting the client to tell me who's logged in...) Thanks, Douglas Mayle ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle added the comment:
Chris, I actually wrote a mock (using import hooks) that would allow me to
simulate not being able to import a module, even if it's really available. This
should allow us to get a higher coverage. Unfortunately, without bcrypt
installed, we couldn't get full coverage...
As to backwards compatibility, the current implementation remains 100% backwards
compatibility, including an existing bug when using cleartext passwords. (Using
cleartext passwords, it is possible for a user to enter a password that has the
same format as a hashed password, making it impossible to login).
Using cleartext passwords is almost always a bad idea, and if you're doing so
and you absolutely insist on keeping them that way, this code won't try to
prevent you from doing so, and even offers an alternative to fix this bug...
(Prefixing all cleartext passwords with {clear} will prevent the bug from
occurring) The other possibility, not mentioned here is to hash all passwords
in the database, or as the users log in (since that gives you access to the
cleartext password, it is easy to change the hashes).
Ok, so that only covers the first half of your comments... I'll look at my code
for the rest...
Doug
__
Repoze Bugs
<http://bugs.repoze.org/issue85>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle added the comment: Any comments for me? Anything I need to do to get this accepted? I think it's pretty thorough, but I'm open to any criticism... __ Repoze Bugs <http://bugs.repoze.org/issue85> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Combining registration with login...
Thanks, that worked a treat! I've got comments in my code pointing to the issue. Hopefully it will be fixed for the next release... Doug On May 22, 2009, at 3:54 PM, Gustavo Narea wrote: > Hi, Douglas. > > Unfortunately it's not well supported. Here you'd find how to do it > for the > time being: > http://bugs.repoze.org/issue58 > > Cheers. > > - Gustavo. > > Douglas said: >> Hey everybody, >> I'm using repoze.who for authentication, and I've got the major part >> of it setup. Login works, as does logout. I just finished writing >> user registration, and was wondering if there was a way that I could >> automatically log the user in on successful signup? I'm currently >> using the redirectingform plugin and the sql authenticator. Will I >> have to write my own custom plugin, or is there something I can do >> out >> of the box? >> >> Thanks, >> Douglas Mayle >> ___ >> Repoze-dev mailing list >> Repoze-dev@lists.repoze.org >> http://lists.repoze.org/listinfo/repoze-dev > -- > Gustavo Narea . > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Combining registration with login...
Hey everybody, I'm using repoze.who for authentication, and I've got the major part of it setup. Login works, as does logout. I just finished writing user registration, and was wondering if there was a way that I could automatically log the user in on successful signup? I'm currently using the redirectingform plugin and the sql authenticator. Will I have to write my own custom plugin, or is there something I can do out of the box? Thanks, Douglas Mayle ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle added the comment: Hopefully, the last of the unit tests that don't work properly in Python 2.4 __ Repoze Bugs <http://bugs.repoze.org/issue85> __ repozewho_salted_hashes_with_bcrypt.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle added the comment: Whoops, bad unittest passed through because I was testing in Python 2.5 __ Repoze Bugs <http://bugs.repoze.org/issue85> __ repozewho_salted_hashes_with_bcrypt.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle added the comment: New version of the patch which also supports blowfish hashes when bcrypt is installed, and uses pycrypto on python < 2.5 for sha256 support. This patch superseded the previous two patches. __ Repoze Bugs <http://bugs.repoze.org/issue85> __ repozewho_salted_hashes_with_bcrypt.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue82] Add HashFormPlugin - JavaScript hashing
Douglas Mayle added the comment:
I've commented on this patch on the mailing list, but wanted to make sure my
concerns were recorded here:
* `if cleartext_password.startswith('{SHA}'):`
The hashing system is entirely optional at the client level, so
you don't provide password protection for all clients.
* The challenge used for verification is the challenge supplied by the
client. This defeats entirely the point of a challenge. I see you do
some calculations to restrict the range of possible challenges (based
on time), but a challenge response only works if the challenge is
random and server supplied. If not, then it's vulnerable to pre-
computation...
* You're performing an HMAC with the challenge as the key. The
purpose of an HMAC is to provide authentication of the message in the
case of a shared private key. In this case, the key is public (as
it's sent over the wire) and that means that there is no difference
between this HMAC and a standard hash.
* In the case of a hashed password, you perform an HMAC of the hashed
password. In a standard hashed password system, the user must know
the clear text password in order to log in. The point of the hash is
to prevent authentication in the case of a database leak. In your
system, the hashed password is sufficient to login, and so you've
removed the protection that password hashing provides.
* While it's true that using a different key per request means that
attackers who sniff the HMAC won't be able to use rainbow tables to
compute the password from the HMAC, the passwords are still stored as
standard hashed passwords, and that means that a db leak leaves all of
your accounts compromised. With salted hashes, that is not true...
--
topic: +repoze.who
__
Repoze Bugs
<http://bugs.repoze.org/issue82>
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] SQLAuthenticator Plugin...
I've had a look at your patch, and I've noticed a couple of security
holes... If your only desire is to prevent eavesdropping of
passwords, I suggest you use SSL, as this is a system that actually
works (if used correctly).
For each issue, I'll address the problem as if it stands apart to give
a clear idea of the problems:
* `if cleartext_password.startswith('{SHA}'):`
The hashing system is entirely optional at the client level, so
you don't provide password protection for all clients.
* The challenge used for verification is the challenge supplied by the
client. This defeats entirely the point of a challenge. I see you do
some calculations to restrict the range of possible challenges (based
on time), but a challenge response only works if the challenge is
random and server supplied. If not, then it's vulnerable to pre-
computation...
* You're performing an HMAC with the challenge as the key. The
purpose of an HMAC is to provide authentication of the message in the
case of a shared private key. In this case, the key is public (as
it's sent over the wire) and that means that there is no difference
between this HMAC and a standard hash.
* In the case of a hashed password, you perform an HMAC of the hashed
password. In a standard hashed password system, the user must know
the clear text password in order to log in. The point of the hash is
to prevent authentication in the case of a database leak. In your
system, the hashed password is sufficient to login, and so you've
removed the protection that password hashing provides.
* While it's true that using a different key per request means that
attackers who sniff the HMAC won't be able to use rainbow tables to
compute the password from the HMAC, the passwords are still stored as
standard hashed passwords, and that means that a db leak leaves all of
your accounts compromised. With salted hashes, that is not true...
Douglas Mayle
On May 20, 2009, at 12:07 AM, Paul Johnston wrote:
> Hi,
>
> Your timing is interesting, I'm just about to submit a patch to
> support JavaScript hashing of passwords, which interacts with this.
>
> If you use random per-user salts, which is the common approach, JS
> hashing requires an Ajax request at login. Not an enormous problem,
> but not ideal either.
>
> If the salt is hmac_sha1(master_salt, user_name) or some variant of
> this, you get the same benefits of salting, but avoid the ajax request
> at login. master_salt is a site-specific value.
This is only true as long as the secret is not known. As soon as the
secret is made available to the client (as in javascript hashing)
there are no longer any benefits to using an HMAC...
>
>
> Paul
>
>
>>> So, I've finished it off and submitted the patch to issue 85:
>>> http://bugs.repoze.org/issue85
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] SQLAuthenticator Plugin...
Okay, done... I recommend the base64 version, as it's backwards compatible and standards compliant... Doug On May 19, 2009, at 4:36 PM, Douglas Mayle wrote: > So, I've finished it off and submitted the patch to issue 85: > http://bugs.repoze.org/issue85 > > In absence of comments, I decided for backwards compatibility over > standards compliance and used hex storage for the data. I could > modify this to switch to base64 for both, since the unsalted SHA1 hash > is always 160 bits and would always end with an equals sign (which is > unambiguously not hex). This is not true for the salted version, so > it might be a lost opportunity to switch to standard compliance... I > think I'll update my patch to support both, and let you choose between > them... > > Douglas Mayle > > On May 19, 2009, at 3:03 PM, Douglas Mayle wrote: > >> On further inspection, it uses a hex form of the digest. Is there >> any >> preference between that and RFC 2307 schemes, which use base64 for >> encoding? >> >> Doug >> >> On May 19, 2009, at 1:57 PM, Douglas Mayle wrote: >> >>> Hello all, >>> I've noticed that the default_password_compare in sql.py uses >>> unsalted hashes, and so I was planning to submit a patch to fix >>> that. >>> I figured, however, that it might be a good idea to provide a >>> default_password_hasher so that users of repoze.who could just >>> import >>> that into their model and have the two work in conjunction. >>> Before I >>> did it, however, I wanted to make sure that there wasn't something I >>> was missing... >>> >>> Thanks, >>> Douglas Mayle >>> ___ >>> Repoze-dev mailing list >>> Repoze-dev@lists.repoze.org >>> http://lists.repoze.org/listinfo/repoze-dev >> >> ___ >> Repoze-dev mailing list >> Repoze-dev@lists.repoze.org >> http://lists.repoze.org/listinfo/repoze-dev > > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
Douglas Mayle added the comment: Adding a version of the patch that uses base64 encoding, to be more standards compliant. The default comparator supports reading the older hex based encoding as well... -- status: unread -> chatting __ Repoze Bugs <http://bugs.repoze.org/issue85> __ repozewho_salted_hashes_b64.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] SQLAuthenticator Plugin...
So, I've finished it off and submitted the patch to issue 85: http://bugs.repoze.org/issue85 In absence of comments, I decided for backwards compatibility over standards compliance and used hex storage for the data. I could modify this to switch to base64 for both, since the unsalted SHA1 hash is always 160 bits and would always end with an equals sign (which is unambiguously not hex). This is not true for the salted version, so it might be a lost opportunity to switch to standard compliance... I think I'll update my patch to support both, and let you choose between them... Douglas Mayle On May 19, 2009, at 3:03 PM, Douglas Mayle wrote: > On further inspection, it uses a hex form of the digest. Is there any > preference between that and RFC 2307 schemes, which use base64 for > encoding? > > Doug > > On May 19, 2009, at 1:57 PM, Douglas Mayle wrote: > >> Hello all, >> I've noticed that the default_password_compare in sql.py uses >> unsalted hashes, and so I was planning to submit a patch to fix that. >> I figured, however, that it might be a good idea to provide a >> default_password_hasher so that users of repoze.who could just import >> that into their model and have the two work in conjunction. Before I >> did it, however, I wanted to make sure that there wasn't something I >> was missing... >> >> Thanks, >> Douglas Mayle >> ___ >> Repoze-dev mailing list >> Repoze-dev@lists.repoze.org >> http://lists.repoze.org/listinfo/repoze-dev > > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue85] Repoze.who should support salted hashes for the sqlauthenticator
New submission from Douglas Mayle : The SQL Authenticator uses unsalted hashes by default which are susceptible to attacks like Rainbow tables. I'm including a patch to add support, with tests. In addition, it's useful to have a default implementation of the hash function, so I've added that. -- files: repozewho_salted_hashes.diff messages: 201 nosy: douglas priority: urgent status: unread title: Repoze.who should support salted hashes for the sqlauthenticator topic: repoze.who __ Repoze Bugs <http://bugs.repoze.org/issue85> __ repozewho_salted_hashes.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] SQLAuthenticator Plugin...
On further inspection, it uses a hex form of the digest. Is there any preference between that and RFC 2307 schemes, which use base64 for encoding? Doug On May 19, 2009, at 1:57 PM, Douglas Mayle wrote: > Hello all, > I've noticed that the default_password_compare in sql.py uses > unsalted hashes, and so I was planning to submit a patch to fix that. > I figured, however, that it might be a good idea to provide a > default_password_hasher so that users of repoze.who could just import > that into their model and have the two work in conjunction. Before I > did it, however, I wanted to make sure that there wasn't something I > was missing... > > Thanks, > Douglas Mayle > ___ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] SQLAuthenticator Plugin...
Hello all, I've noticed that the default_password_compare in sql.py uses unsalted hashes, and so I was planning to submit a patch to fix that. I figured, however, that it might be a good idea to provide a default_password_hasher so that users of repoze.who could just import that into their model and have the two work in conjunction. Before I did it, however, I wanted to make sure that there wasn't something I was missing... Thanks, Douglas Mayle ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
Douglas Mayle added the comment: As repoze.who fails to handle the WSGI spec, and I'm supplying a working patch, I'm bumping up the priority... -- priority: bug -> critical __ Repoze Bugs <http://bugs.repoze.org/issue71> __ issue71.diff Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
Douglas Mayle added the comment: This is a bug in repoze.who because of this paragraph in PEP 333: (Note: the application must invoke the start_response() callable before the iterable yields its first body string, so that the server can send the headers before any body content. However, this invocation may be performed by the iterable's first iteration, so servers must not assume that start_response() has been called before they begin iterating over the iterable.) I've got a wrapper working, I'll implement it into repoze.who and submit a patch __ Repoze Bugs <http://bugs.repoze.org/issue71> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
Douglas Mayle added the comment: The only way I can think to fix this is to create a new generator that wraps the previous one. It calls the wrapped generator once, caches that, and then yields that and any further responses. This allows the original generator to behave the way it did before, and repoze.who can take a look at the status code. -- status: unread -> chatting __ Repoze Bugs <http://bugs.repoze.org/issue71> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue71] repoze.who has problems with generator wsgi applications.
New submission from Douglas Mayle : If a WSGI application returns a generator expression, then default_challenge_decider in classifiers.py tries to call status.startswith, which blows up because status has not yet been decided (since the generator hasn't been called yet) -- messages: 173 nosy: douglas priority: bug status: unread title: repoze.who has problems with generator wsgi applications. __ Repoze Bugs <http://bugs.repoze.org/issue71> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
