From: Hancock, D. (DHANCOCK) <DHA...@ar...> - 2017-01-31 18:58:51
|
Thank you the ideas on this thread. The idea of writing an auditor/reactor to check the passwords was the most appealing initially, but I ran into a problem. By the time userauditor gets to see the password from newvalues['password'] it's already been hashed: {PBKDF2}10000$GeodPG9LmZAwMCRrv79u7oVTHyg$ZYZaios16Kiq4wYB4zHHV1Lo00Q So my string-based checked for minimum length, letters, numbers, punctuation would pass for ANY password once it's hashed. Is there something I'm missing here? The userauditor.py approach fits my (small) brain. The other ideas were about connecting other authentication systems instead of using Roundup's, but we're trying to eliminate dependency on another system, and we've got everybody's information in Roundup already. Cheers! -- David Hancock | dha...@ar... |
From: Georg L. <jor...@ma...> - 2017-01-31 20:37:12
|
On 31/01/17 12:58, Hancock, David (DHANCOCK) wrote: > Thank you the ideas on this thread. The idea of writing an > auditor/reactor to check the passwords was the most appealing > initially, but I ran into a problem. By the time userauditor gets to > see the password from newvalues['password'] it's already been > hashed: > > {PBKDF2}10000$GeodPG9LmZAwMCRrv79u7oVTHyg$ZYZaios16Kiq4wYB4zHHV1Lo00Q > >So my string-based checked for minimum length, letters, numbers, punctuation > would pass for ANY password once it's hashed. > > Is there something I'm missing here? The userauditor.py approach fits > my (small) brain. > ... > -- > David Hancock | dha...@ar... You are not missing anything, I did, when I suggested the auditor approach, namely that they get called when the input is already processed. In fact the standard templates implement a simple form of input validation *before* submitting the form via the JavaScript function checkRequiredFields(), which can be found in html/help_controls.js. You could replace this function (in the right place/action) with one that checks the password strength too. Some Google hits on 'JavaScript password strength validation', selected for not pulling in big JavaScript libraries: http://stackoverflow.com/questions/948172/password-strength-meter https://martech.zone/javascript-password-strength/ Best Regards, Georg Lehner |
From: John P. R. <ro...@cs...> - 2017-01-31 22:31:06
|
In message <C97...@ar...>, "Hancock, David (DHANCOCK)" writes: >Thank you the ideas on this thread. The idea of writing an >auditor/reactor to check the passwords was the most appealing >initially, but I ran into a problem. By the time userauditor gets to >see the password from newvalues['password'] it's already been hashed: > >{PBKDF2}10000$GeodPG9LmZAwMCRrv79u7oVTHyg$ZYZaios16Kiq4wYB4zHHV1Lo00Q Crud, I was worried that may be the case. That makes sense since you are seeing the data that would be commited to the db. Hence hashed. >Is there something I'm missing here? The userauditor.py approach fits >my (small) brain. No, I don't think you are missing anything. I am wonding if it's possible to provide the unhashed password to the auditor somehow. >The other ideas were about connecting other authentication systems >instead of using Roundup's, but we're trying to eliminate dependency >on another system, and we've got everybody's information in Roundup >already. Fair enough. I'll try to trace the code and see what can be done. I have a feeling I may need to add a hook before the auditor code is invoked. I am also going to raise this on roundup-dev since it seems we have to do some core code changes. Another (less secure) way to skin this cat would be to add some javascript to the password setting page and validate it client side. YMMV, not recommended that you try this at home, server side validation rules etc. etc.... -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: Georg L. <jor...@ma...> - 2017-02-02 04:34:05
|
On 31/01/17 16:30, John P. Rouillard wrote: > In message <C97...@ar...>, > "Hancock, David (DHANCOCK)" writes: > ... > > No, I don't think you are missing anything. I am wonding if it's > possible to provide the unhashed password to the auditor somehow. > .. > > I'll try to trace the code and see what can be done. I have a feeling > I may need to add a hook before the auditor code is invoked. > > I am also going to raise this on roundup-dev since it seems we have > to do some core code changes. Wouldn't it be enough to inherit from the RegisterAction class, similar to the customization example of LDAPLogin? where the LoginAction is inherited and the new subclass is registered as 'login'. http://www.roundup-tracker.org/cgi-bin/moin.cgi/LDAPLogin2 The password check would be far more easier to implement then the LDAP authentication. > > Another (less secure) way to skin this cat would be to add some > javascript to the password setting page and validate it client > side. YMMV, not recommended that you try this at home, server side > validation rules etc. etc.... > Mhm... how would an attack be crafted on the assumption that you can inject an insecure password into the PBKDF2 encryption of roundup? Anyways, server side validation would require a two step process (if not deriving the Login class. 1. The template where a new user is created () is changed to call a "verifyLogin" action first, which might use the same or a different template. 2. The verifyLogin action checks the password (still in the clear) and eventually other data (username already exists, duplicate Email, ... and - either proceeds to the normal roundup 'register' action or - sets self.client._error_message which makes the error message inside this nice red textbox appear on top of the page. The setup of such a process, including a link to a step by step example is documented in: http://roundup-tracker.org/docs/customizing.html#defining-new-web-actions Best Regards, Georg Lehner |