[Repoze-dev] [issue89] AuthTktPlugin fails with Opera, if non-standard port used
Paul Johnston added the comment: This could be a dupe of issue66 -- status: unread -> chatting __ Repoze Bugs <http://bugs.repoze.org/issue89> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue89] AuthTktPlugin fails with Opera, if non-standard port used
New submission from Paul Johnston : To reproduce: 1) Create a simple app using repoze.who, with FormPlugin and AuthTktPlugin, running on 127.0.0.1:8000 2) Using Opera, browse to the app and login with valid details 3) You will be redirected back to the login screen, despite the login being valid Looking at the headers, Opera isn't sending the cookie. This is something to do with the way AuthTktPlugin issues three set-cookie headers. If I recode it to only generate the set-cookie header with no domain, the problem disappears. -- messages: 241 nosy: paj priority: bug status: unread title: AuthTktPlugin fails with Opera, if non-standard port used __ Repoze Bugs <http://bugs.repoze.org/issue89> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] JSCrypto
Hi, Ok, I have created repoze-who-jscrypto, a separate plugin to repoze.who that does JavaScript cryptography. As a few people have pointed out, this isn't as strong as SSL, but IMHO it is better than no encryption. It's on Googlecode at http://code.google.com/p/repoze-who-jscrypto/ No plans to put it on PyPI just yet. At the minute it only supports challenge-response. But we can add other plugins to this, e.g. for SRP. Don't think I'll need any changes to repoze.who core, so I'm gonna drop off this list now. Enjoy, Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Timeouts for AuthTktCookie
Hi, I've put a patch on the ticket http://bugs.repoze.org/issue83 To avoid the issue of the default to set, and for backward-compatibility, this patch defaults to no timeout. Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue83] Timeout for AuthTktCookiePlugin
Paul Johnston added the comment:
Ok, I've produced a patch for this, let me know what you think.
--
status: unread -> chatting
__
Repoze Bugs
<http://bugs.repoze.org/issue83>
__Index: repoze/who/plugins/tests/test_authtkt.py
===
--- repoze/who/plugins/tests/test_authtkt.py (revision 5195)
+++ repoze/who/plugins/tests/test_authtkt.py (working copy)
@@ -29,7 +29,8 @@
def _makeTicket(self, userid='userid', remote_addr='0.0.0.0',
tokens = [], userdata='userdata',
-cookie_name='auth_tkt', secure=False):
+cookie_name='auth_tkt', secure=False,
+time=None):
from paste.auth import auth_tkt
ticket = auth_tkt.AuthTicket(
'secret',
@@ -37,6 +38,7 @@
remote_addr,
tokens=tokens,
user_data=userdata,
+time=time,
cookie_name=cookie_name,
secure=secure)
return ticket.cookie_value()
@@ -115,6 +117,14 @@
result = plugin.identify(environ)
self.assertEqual(result, None)
+def test_identify_bad_cookie_expired(self):
+import time
+plugin = self._makeOne('secret', timeout=2, reissue_time=1)
+val = self._makeTicket(userid='userid', time=time.time()-3)
+environ = self._makeEnviron({'HTTP_COOKIE':'auth_tkt=%s' % val})
+result = plugin.identify(environ)
+self.assertEqual(result, None)
+
def test_remember_creds_same(self):
plugin = self._makeOne('secret')
val = self._makeTicket(userid='userid')
@@ -250,6 +260,20 @@
('Set-Cookie',
'auth_tkt="%s"; Path=/' % new_val))
+def test_remember_creds_reissue(self):
+import time
+plugin = self._makeOne('secret', reissue_time=1)
+old_val = self._makeTicket(userid='userid', userdata='', time=time.time()-2)
+environ = self._makeEnviron({'HTTP_COOKIE':'auth_tkt=%s' % old_val})
+new_val = self._makeTicket(userid='userid', userdata='')
+result = plugin.remember(environ, {'repoze.who.userid':'userid',
+ 'userdata':''})
+self.assertEqual(type(result[0][1]), str)
+self.assertEqual(len(result), 3)
+self.assertEqual(result[0],
+ ('Set-Cookie',
+ 'auth_tkt="%s"; Path=/' % new_val))
+
def test_forget(self):
plugin = self._makeOne('secret')
environ = self._makeEnviron()
@@ -301,3 +325,9 @@
plugin = make_plugin(secretfile=path)
self.assertEqual(plugin.secret, 's33kr1t')
+def test_timeout_reissue(self):
+try:
+self._makeOne('userid', timeout=1)
+self.assertEqual(1, 2)
+except ValueError, e:
+pass
Index: repoze/who/plugins/auth_tkt.py
===
--- repoze/who/plugins/auth_tkt.py (revision 5195)
+++ repoze/who/plugins/auth_tkt.py (working copy)
@@ -1,6 +1,7 @@
from codecs import utf_8_decode
from codecs import utf_8_encode
import os
+import time
from paste.request import get_cookies
from paste.auth import auth_tkt
@@ -25,11 +26,17 @@
}
def __init__(self, secret, cookie_name='auth_tkt',
- secure=False, include_ip=False):
+ secure=False, include_ip=False,
+ timeout=None, reissue_time=None):
self.secret = secret
self.cookie_name = cookie_name
self.include_ip = include_ip
self.secure = secure
+if timeout and (not reissue_time or reissue_time > timeout):
+raise ValueError('When timeout is specified, reissue_time must '
+ 'be set to a lower value')
+self.timeout = timeout
+self.reissue_time = reissue_time
# IIdentifier
def identify(self, environ):
@@ -50,6 +57,9 @@
except auth_tkt.BadTicket:
return None
+if self.timeout and timestamp + self.timeout < time.time():
+return None
+
userid_typename = 'userid_type:'
user_data_info = user_data.split('|')
for datum in filter(None, user_data_info):
@@ -126,7 +136,8 @@
old_data = (userid, tokens, userdata)
new_data = (who_userid, who_tokens, who_userdata)
-if old_data != new_data:
+if old_data != ne
Re: [Repoze-dev] SQLAuthenticator Plugin...
Hi, > 1. The author of the patch clearly thinks that security consists of > sprinkling magic SHA-1 HMAC challenge response pixie dust over the code > in a random fashion. This means that any revised patch must be viewed > with suspicion. > I don't know why you feel the need to be so rude. Let me assure you that this "pixie dust" is not random and is in fact carefully considered. Anyway, you have some interesting points, so I will overlook your attitude. > The next best thing to do is to use SRP. It's the only thing that lets > you have secure passwords on the server and secure transmission of > passwords from the client. There's a Javacsript library available at > http://sourceforge.net/projects/clipperz > This is actually the first I'd heard of SRP, and I'll be looking into it some more. A quick look at the code in Clipperz suggests this is JavaScript RSA with a 256-bit key. This is something that has been suggested in the past; previously considered too slow, but computers are faster now and JS engines better. I also don't now how easy it is to factor a 256-bit number; I will certainly be investigating this some more. If this is how it works, a great feature is that it defeats brute force attacks as well as storing the password securely. After feedback on ticket 82 I will be creating a standalone library, something like repoze.who-jscrypto. This can be a place to experiment with such approaches - we can have challenge-response login and SRP. Or ditch challenge-response if SRP comes out clearly superior. I will be submitting a patch to add timeouts to AuthTktCookiePlugin, in the next week or so. I hope this patch is less controversial. Best wishes, Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue79] [patch] Some tests fail on Windows
Paul Johnston added the comment: Yep, works a treat __ Repoze Bugs <http://bugs.repoze.org/issue79> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue79] [patch] Some tests fail on Windows
Paul Johnston added the comment: Nearly there... you hit the same problem I did. We need to close the log file. ERROR: test_sample_config_w_log_file (repoze.who.tests.test_config.TestConfigMid dleware) -- Traceback (most recent call last): File "C:\code\repoze.who\repoze\who\tests\test_config.py", line 337, in tearDo wn shutil.rmtree(self.tempdir) File "c:\python25\lib\shutil.py", line 180, in rmtree onerror(os.remove, fullname, sys.exc_info()) File "c:\python25\lib\shutil.py", line 178, in rmtree os.remove(fullname) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\docume~1\\paul\\locals~1\\temp\\tmpwtmexf\\who.log ' -- Ran 206 tests in 2.688s FAILED (errors=1) __ Repoze Bugs <http://bugs.repoze.org/issue79> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] SQLAuthenticator Plugin...
Hi, > 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). Although it has limitations, some people want this feature. I'm not proposing this be the default authentication method; if you don't want it, don't use it in your applications. The risks are well understood; you may like to read my site for more information http://pajhome.org.uk/crypt/md5/ > The hashing system is entirely optional at the client level, so you don't > provide password protection for all clients. Sure. We could potentially have a server-side option allow_disabled_js, with the html tweaked so the submit button only appears when js is enabled. Not something for the first attempt though, and in fact, I expect almost everyone would rather allow users without javascript. > * 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 Sure. Instead of seeing a plaintext password, a sniffer sees a hash that they can replay in a given time window, and try to brute force the password against. That's better than them seeing a plaintext password. The session key is going plaintext on the wire anyway, so replay attacks are a risk anyway. > * 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 That's one purpose of an HMAC. Here, we're using HMAC differently, as an alternative to sha1(password + challenge). I don't think there's any great cryptographic advantages to this, but it is the recommended way - I communicated with one of the authors of the HMAC RFC about this a few years ago. Not got the mail to hand now. > * 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 Good point. This is a serious enough weakness that the docs should mention it, and I can look at revising the patch. But with salted hashes, it keeps the main benefit of hashing - that a captured password database doesn't let the attacker use your customers' password on other sites. Remember, if an attacker has your password database, they're pretty far into your app already. Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Patch - HashFormPlugin
Hi, Ok, as promised, here's the patch to add JavaScript hashing http://bugs.repoze.org/issue82 Hope someone can look at this soon, Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue79] [patch] Some tests fail on Windows
Paul Johnston added the comment: Ok, here's a patch. test_sample_config_w_log_file in test_config does now leave the log file existing; can't see a way to fix that. -- title: [patch] test_sample_config fails on Windows -> [patch] Some tests fail on Windows __ Repoze Bugs <http://bugs.repoze.org/issue79> __ windows_fails.patch 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
Paul Johnston added the comment:
Here's a test app you can use to try it out
__
Repoze Bugs
<http://bugs.repoze.org/issue82>
__import webob as wo, wsgiref.simple_server as wrs, sqlite3, sha
def simple_app(environ, start_response):
req = wo.Request(environ)
resp = wo.Response(request=req, content_type="text/html; charset=UTF8")
if 'REMOTE_USER' in environ:
resp.body = 'hello world'
else:
resp.status = 401
return resp(environ, start_response)
from repoze.who.middleware import PluggableAuthenticationMiddleware
from repoze.who.classifiers import default_request_classifier
from repoze.who.classifiers import default_challenge_decider
from repoze.who.plugins.auth_tkt import AuthTktCookiePlugin
from repoze.who.plugins.hashform import HashFormPlugin
from repoze.who.plugins.sql import SQLAuthenticatorPlugin,
default_password_compare
db = sqlite3.connect(':memory:')
db.execute('create table users (name varchar, password varchar)')
db.execute('insert into users values (?, ?)', ('paj',
'{SHA}'+sha.new('test').hexdigest()))
db.commit()
sqlauth = SQLAuthenticatorPlugin('select name, password from users where name =
:login', lambda: db, default_password_compare)
auth_tkt = AuthTktCookiePlugin('secret', 'auth_tkt')
form = HashFormPlugin('__do_login', rememberer_name='auth_tkt', stored_sha=True)
identifiers = [('form', form),('auth_tkt',auth_tkt)]
authenticators = [('sqlauth', sqlauth)]
challengers = [('form',form)]
mdproviders = []
middleware = PluggableAuthenticationMiddleware(
simple_app,
identifiers,
authenticators,
challengers,
mdproviders,
default_request_classifier,
default_challenge_decider
)
if __name__ == "__main__":
wrs.make_server('', 8000, middleware).serve_forever()
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue79] [patch] test_sample_config fails on Windows
Paul Johnston added the comment: Just updated to latest code base and the problem is a bit worse. working on a new patch -- status: unread -> in-progress __ Repoze Bugs <http://bugs.repoze.org/issue79> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue82] Add HashFormPlugin - JavaScript hashing
Paul Johnston added the comment: Ok, here's a patch. Potential bad interaction with ticket 85. __ Repoze Bugs <http://bugs.repoze.org/issue82> __ hashform.patch 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
Paul Johnston added the comment: Ok, here's the patch. Potential bad interaction with ticket 85 - see discussion on list __ Repoze Bugs <http://bugs.repoze.org/issue82> __ hashform.patch Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] SQLAuthenticator Plugin...
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. 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
[Repoze-dev] Tickets
Hi, Just created a bunch! First, two that I hope can be comitted with minimal fuss; patches included: 79 - test_sample_config fails on Windows 80 - doc change for include_ip Now, two that I will work on (already getting somewhere with JS hashing): 82 - HashFormPlugin - JavaScript hashing 83 - Timeout for AuthTktCookiePlugin Finally, one that I think is an important feature, but I'm not volunteering to work on this: 84 - Brute force lockouts Enoy :-) Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue84] Brute force lockouts
New submission from Paul Johnston : There should be some form of lockouts, to avoid brute force password attacks. I'm not volunteering to work on this feature though. -- messages: 200 nosy: paj priority: feature status: unread title: Brute force lockouts __ Repoze Bugs <http://bugs.repoze.org/issue84> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue83] Timeout for AuthTktCookiePlugin
New submission from Paul Johnston : This plugin should check the timeout on the cookie; otherwise the cookie is a password equivalent. I will work on this, not started yet. -- assignedto: paj messages: 199 nosy: paj priority: feature status: unread title: Timeout for AuthTktCookiePlugin __ Repoze Bugs <http://bugs.repoze.org/issue83> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue82] Add HashFormPlugin - JavaScript hashing
New submission from Paul Johnston : I'm working on the patch for this - some success so far -- assignedto: paj messages: 198 nosy: paj priority: feature status: in-progress title: Add HashFormPlugin - JavaScript hashing __ Repoze Bugs <http://bugs.repoze.org/issue82> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue81] [patch] advise against using include_ip
Paul Johnston added the comment: Got 500 internal server error when submitting the bug -- status: unread -> resolved __ Repoze Bugs <http://bugs.repoze.org/issue81> __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue81] [patch] advise against using include_ip
New submission from Paul Johnston : Suggest add this note to doc on AuthTktCookiePlugin advising against using include_ip BTW, the 3% figure comes from here: http://westpoint.ltd.uk/advisories/Paul_Johnston_GSEC.pdf -- files: include_ip.patch messages: 196 nosy: paj priority: feature status: unread title: [patch] advise against using include_ip __ Repoze Bugs <http://bugs.repoze.org/issue81> __ include_ip.patch Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue80] [patch] advise against using include_ip
New submission from Paul Johnston : Suggest add this note to doc on AuthTktCookiePlugin advising against using include_ip BTW, the 3% figure comes from here: http://westpoint.ltd.uk/advisories/Paul_Johnston_GSEC.pdf -- files: include_ip.patch messages: 195 nosy: paj priority: feature status: unread title: [patch] advise against using include_ip __ Repoze Bugs <http://bugs.repoze.org/issue80> __ include_ip.patch Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue79] [patch] test_sample_config fails on Windows
New submission from Paul Johnston : One unit test fails on Windows - problem with the test, not the code base. -- files: test_sample_config.patch messages: 194 nosy: paj priority: bug status: unread title: [patch] test_sample_config fails on Windows __ Repoze Bugs <http://bugs.repoze.org/issue79> __ test_sample_config.patch Description: Binary data ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] JS Hashing - Initial Thoughts
Hi, > From a usability point of view, I think rounding up considerably on > numbers makes sense. Ok, happy with that. At some point we're going to just have to pick a number, maybe I'll go for 2 hours. > Is the issue dictionary attacks? If that's the case, a one-minute > lockout would serve the purpose, wouldn't it? Kind of, it's all a trade-off between preventing brute force attacks and preventing denial of service attacks. > problematic. It would add some increased security if you were able to > see that the IP changed, and test if the change is acceptable (using > the GeoIP library to see the new and old location, and acceptable > changes should be regionally similar -- an IP should never switch from > the US to Russia, for instance). Ok, this sort of functionality has more recently been added to online banking sites - services like RSA PassMark do this. Not appropriate for our kind of sites I think. > What is the advantage of "hmac_sha1(master_salt, user_name)" over > "master_salt+username"? Minimal, it's just HMAC is specifically designed for combining two values in a hash like this. Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] JS Hashing - Initial Thoughts
Hi, Ok, I've had a little look at how I could implement the JavaScript hash login. I'll create a HashFormPlugin that is a challenger and an identifier. As for the Authenticator, maybe I'll create a new SQLHashAuthenticatorPlugin, or maybe I'll just provide a default_hash_compare function to pass to SQLAuthenticatorPluig. (any opinions from here welcome). I noticed that AuthTktCookiePlugin does not check the timestamp. This is a problem actually, it makes the cookie a "password equivalent" and negates most of the benefits of hashing the password. I realise apps could check the timestamp themselves, but I doubt many do. What I'd suggest is adding two configuration parameters to AuthTktCookiePlugin: Timeout - default 15 mins, if timestamp is older than this, cookie is treated as invalid ReissueTime - default 5 mins, if timestamp is older than this, a new cookie is issued, with the current timestamp While this arrangement is not perfect, it's quite simple and solves the main problem. I will produce a patch for this at some point. I also noticed that repoze.who does not do lockouts. Usually I recommend that if there are three incorrect logins that the account is locked for one hour. Again, this isn't perfect, but it's simple and solves the main problems. I'm not going to implement this myself, but I think you should put it on your development plans (sorry if there's already a ticket, I've not checked trac). A few other minor things to consider: I suggest you include a warning in the docs not to use the include_ip option on AuthTktCookiePlugin. I did some experiments a while ago and found that around 3% of web users change IP address during a session. So turning this on will cause problems. Add a StatefulAuthCookiePlugin, where the session is saved in a database. This allows strong logout where the cookie is invalidated on the server. The redirect after login does not check the referrer is on the same site. While it's unlikely this could enable any practical attacks, putting in a check would be good practice. By default, passwords are stored in the database without a salt. Usual practice is to use a salt, to make things harder for an attacker, just in case your password database is captured. The scheme I favor is storing hmac_sha1(hmac_sha1(master_salt, user_name), password). master_salt is a per-site value. None of these issues are major, but if I was security testing an app based on repoze.who, I'd flag them as low-risk issues. To be fair though, I don't think anyone's been proposing using repoze.who to protect the nuclear launch codes :-) Ok, that's it for now, let me know what you think. Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] JavaScript Hash for Login
Hi, I am going to have a go at adding a new authentication method to repoze.who. It's like the standard forms authentication, but uses JavaScript hashing to protect the password as it is transmitted. There's information about the scripts here, explaining how the system works, how it avoids replay attacks, copes with js being disabled, ensures that the password is protected when stored on the server, and why SHA1/MD5 are ok to use, despite the more recent weaknesses. http://pajhome.org.uk/crypt/md5/ I know many people are using my scripts, so I think this would be a good feature for repoze.who. I've not used repoze.who so far, so lets see how I get on. If anyone would like to lend a hand, just let me know. Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
