From: <pa...@bo...> - 2001-11-22 11:36:00
|
Tavis Rudd <ta...@ca...> wrote: > >Remember, this discussion is about a UserManagement system that can >be used for the various application ideas on the AppIdeas wiki page. >Most of those would fall into the 'large, complex' category. We >would really need to discuss the permissions system in the context of >each of those applications. But as none of them exist let's focus on >authentification for now. Yes, this is what I think we should be concentrating on - it doesn't matter how "rights" are managed until we know how people should be identified and recognised. Indeed, as I mention on the Wiki, there are classes of applications for which the users, groups, roles model is inappropriate. What we should do is define a framework for authentication and allow people to build "rights management" (to use a contentious term) on top. >What are people using at the moment to do their authentification? An aside: can we not call it authentication? I think you're the first person I've ever seen to use "authentification". >Notes: >* for authentification we only need to think in terms of users In more concrete terms, if a session identifier is used to associate a distinct but transient (temporary) identity, then a user is a persistent (permanent) identity which can be associated with one or many sessions at any given point in time. Through authentication, sessions become associated with users and, as a result, it should be possible to ask about the user who "owns" a session, although it is possible that no user owns a particular session because the session is only around to encapsulate the activities of a "client" (or "agent", "actor" or whatever we can call something which uses an application or service without actually being a registered user). >* I assume we are going to use sessions to store the authentification >info. As can be guessed from what I've just written, it makes sense to "extend" sessions to allow a user identity to be associated with them. But no more than that should be involved; certainly not what rights someone has. >Here's a summary of the important questions: > >* At what stage in the request-response cycle does authentification >take place (Adapter, Application, or Servlet)? >Doing it at the Adapter level means we can use the same mechanism to >protect content that isn't served via WebKit. Doing it at the >Application level means that we can also protect static content that >is served via WebKit. Doing it at the Servlet level means that we can >only protect servlets. This is a good question, and it's great to see someone else wondering about this as well. ;-) I think it's important that if the Adapter, Web server or Application performs authentication, then the WebKit components should obviously be aware of the identities of users of the system, even though no WebKit component will necessarily be managing any part of the authentication process; this would permit any "rights" or "roles" systems to be implemented at other levels in an application architecture. >* Assuming that we use sessions to store the authentification >details, how do we make sessions work with/without cookies? Extend >this to protecting static content via WebKit. This question is really only an issue for the work on extending the existing session mechanisms and using modified paths or hidden form fields. Authentication shouldn't necessarily have a huge impact on this work. >* How do we store authentification information in the user session? > >* How do we guard against session hijacking? I'm not really qualified to discuss these issues in depth, although the paper that someone referred to recently (I think it was Ian Bicking) is interesting for those interested in this area. >* How are password's stored internally? plain or hashed? They should absolutely *not* be stored as plain (clear?) text. For those implementing Web services, I find it unacceptable that users' passwords would be stored in such a way. Whether or not users should invent a new password for each service they use, I suppose that many people do use passwords which are identical from service to service; by not protecting passwords, service or application providers could potentially leave their users open to damage which would not be limited to within their own services or applications. In short, it shows a disrespect for their users' sensitive information. >* How do we interface with arbitrary stores of user information and >passwords (flat-file, BSD-DB, ZODB, relational database, LDAP, etc.) Provided a convenient plug-in architecture exists, this should satisfy most users. It would be nice to provide "out of the box" solutions for this and other parts of Webware, though. >* When Webware makes the shift to a multi-application framework, does >authentfication span applications? > >* How do we make the authentification system fall-back to a >semi-secure mechanism (e.g. md5 hashes via javascript) when SSL isn't >available. I think we should keep the door open to as many authentication technologies as possible. The fact that WebKit only supports cookies as a session identifier "transport" is potentially a worrying enough factor demonstrating weaknesses in terms of accessibility. >* Do we want to enable some sort of IP filtering or automatic >IP-userID mapping? > >* Are we going to block brute-force dictionary attacks with a failed >login time-out mechanism? These things should be configurable by the developer. >* Are we going to worry about multi-machine failover support? Well, I think we should worry about that *in general* for Webware first. ;-) What I would like to emphasise is that authentication is something that has been done before many times and, more importantly, authentication frameworks have also been well-covered in the past. For example, the whole PAM system is supposedly oriented around letting people decide which mechanisms are best in their own cases. Therefore, it's important to design something which leaves the door open for flexibility, although "ready to roll" solutions would obviously be nice for the novice Webware developer. Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
From: Tavis R. <ta...@ca...> - 2001-11-22 18:16:45
|
On Thursday 22 November 2001 03:35, pa...@bo... wrote: > Tavis Rudd <ta...@ca...> wrote: > >Remember, this discussion is about a UserManagement system that > > can be used for the various application ideas on the AppIdeas > > wiki page. Most of those would fall into the 'large, complex' > > category. We would really need to discuss the permissions system > > in the context of each of those applications. But as none of > > them exist let's focus on authentification for now. > > Yes, this is what I think we should be concentrating on - it > doesn't matter how "rights" are managed until we know how people > should be identified and recognised. Indeed, as I mention on the > Wiki, there are classes of applications for which the users, > groups, roles model is inappropriate. What we should do is define a > framework for authentication and allow people to build "rights > management" (to use a contentious term) on top. Agreed. ... I quite like that term. > >What are people using at the moment to do their authentication? > An aside: can we not call it authentication? I think you're the > first person I've ever seen to use "authentification". Hmmm, I should use a spell checker more often! > >Notes: > >* for authentification we only need to think in terms of users > > In more concrete terms, if a session identifier is used to > associate a distinct but transient (temporary) identity, then a > user is a persistent (permanent) identity which can be associated > with one or many sessions at any given point in time. > > Through authentication, sessions become associated with users and, > as a result, it should be possible to ask about the user who "owns" > a session, although it is possible that no user owns a particular > session because the session is only around to encapsulate the > activities of a "client" (or "agent", "actor" or whatever we can > call something which uses an application or service without > actually being a registered user). I guess we need to define this term as well. How about 'client' and 'authenticated client'? > >* I assume we are going to use sessions to store the > > authentification info. > > As can be guessed from what I've just written, it makes sense to > "extend" sessions to allow a user identity to be associated with > them. But no more than that should be involved; certainly not what > rights someone has. Totally agreed. Someone's 'rights' should not be stored using sessions. Although that's really up to the implementor of a particular 'rights management' system. > >Here's a summary of the important questions: > > > >* At what stage in the request-response cycle does > > authentification take place (Adapter, Application, or Servlet)? > >Doing it at the Adapter level means we can use the same mechanism > > to protect content that isn't served via WebKit. Doing it at the > > Application level means that we can also protect static content > > that is served via WebKit. Doing it at the Servlet level means > > that we can only protect servlets. > > This is a good question, and it's great to see someone else > wondering about this as well. ;-) I think it's important that if > the Adapter, Web server or Application performs authentication, > then the WebKit components should obviously be aware of the > identities of users of the system, even though no WebKit component > will necessarily be managing any part of the authentication > process; this would permit any "rights" or "roles" systems to be > implemented at other levels in an application architecture. > >* Assuming that we use sessions to store the authentification > >details, how do we make sessions work with/without cookies? > > Extend this to protecting static content via WebKit. > > This question is really only an issue for the work on extending the > existing session mechanisms and using modified paths or hidden form > fields. Authentication shouldn't necessarily have a huge impact on > this work. Authentication clearly defines what is needed in this area so I think it will have a 'huge impact'. For example, hidden form fields and javascript are totally out of the question for protecting static content. The only options I can see are: * cookies * an IP or MAC address based system * query strings * modified paths (ala Clarks path-based sessions) The last two would only work if this is happening through WebKit, rather than at the adapter/webserver level. Last time I checked there weren't any good apache modules for doing non-HTTP authentication. Has this changed recently? Here's some useful links I just found: http://sec.ure.org/apache_auth.shtml http://www.ime.usp.br/~nelio/apache/ http://www.frogdot.org > >* How do we store authentification information in the user > > session? > > > >* How do we guard against session hijacking? > > I'm not really qualified to discuss these issues in depth, although > the paper that someone referred to recently (I think it was Ian > Bicking) is interesting for those interested in this area. Anyone have a link to this? > >* How are password's stored internally? plain or hashed? > > They should absolutely *not* be stored as plain (clear?) text. For > those implementing Web services, I find it unacceptable that users' > passwords would be stored in such a way. Whether or not users > should invent a new password for each service they use, I suppose > that many people do use passwords which are identical from service > to service; by not protecting passwords, service or application > providers could potentially leave their users open to damage which > would not be limited to within their own services or applications. > In short, it shows a disrespect for their users' sensitive > information. Glad we agree on that ;) Now, how are they hashed? md5, crypt, or something else? > >* How do we interface with arbitrary stores of user information > > and passwords (flat-file, BSD-DB, ZODB, relational database, > > LDAP, etc.) > > Provided a convenient plug-in architecture exists, this should > satisfy most users. It would be nice to provide "out of the box" > solutions for this and other parts of Webware, though. > > >* When Webware makes the shift to a multi-application framework, > > does authentfication span applications? > > > >* How do we make the authentification system fall-back to a > >semi-secure mechanism (e.g. md5 hashes via javascript) when SSL > > isn't available. > > I think we should keep the door open to as many authentication > technologies as possible. The fact that WebKit only supports > cookies as a session identifier "transport" is potentially a > worrying enough factor demonstrating weaknesses in terms of > accessibility. > > >* Do we want to enable some sort of IP filtering or automatic > >IP-userID mapping? > > > >* Are we going to block brute-force dictionary attacks with a > > failed login time-out mechanism? > > These things should be configurable by the developer. We'd need to implement the hooks if we wanted to support them. > >* Are we going to worry about multi-machine failover support? > > Well, I think we should worry about that *in general* for Webware > first. ;-) This is tied to session management and management of the user database. mod_webkit (or was it just Terrel's modification of it) already has round-robin support for multiple AppServers. If the sessions and user database can be shared between machines then it seems we've got fail-over support. Sessions can be shared via NFS and the FileSessionStore or we can create a ZODBSessionStore / DBSessionStore. > What I would like to emphasise is that authentication is something > that has been done before many times and, more importantly, > authentication frameworks have also been well-covered in the past. > For example, the whole PAM system is supposedly oriented around > letting people decide which mechanisms are best in their own cases. > Therefore, it's important to design something which leaves the door > open for flexibility, although "ready to roll" solutions would > obviously be nice for the novice Webware developer. True. Flexibility and 'ready to roll' should go together if we get the design right. |
From: Tavis R. <ta...@ca...> - 2001-11-22 19:52:47
|
Here's an excellent summary http://www.wwnet.net/~janc/auth.html ! |
From: Tavis R. <ta...@ca...> - 2001-11-22 20:18:10
|
and here's a more technical paper on authentication: Title: Do's and Don'ts of Client Authentication on the Web http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf includes cases studies from 27 sites |
From: <ir...@ms...> - 2001-11-22 20:57:58
|
On Thu, Nov 22, 2001 at 11:26:59AM -0800, Tavis Rudd wrote: > > As can be guessed from what I've just written, it makes sense to > > "extend" sessions to allow a user identity to be associated with > > them. But no more than that should be involved; certainly not what > > rights someone has. > > Totally agreed. Someone's 'rights' should not be stored using > sessions. Although that's really up to the implementor of a > particular 'rights management' system. However, you are both right. "Rights" are semi-permanent information which belong in a User or Userrights object. The session only needs a user identifier. Of course, with Basic Authentication the user ID doesn't even need to be stored in the session, but Basic Authentication has its own tradeoffs (not being able to log out, not being able to re-log in as someone else). > > The fact that WebKit only supports > > cookies as a session identifier "transport" is potentially a > > worrying enough factor demonstrating weaknesses in terms of > > accessibility. No, it just demonstrates the immaturity of the current implementation. What would be worrying is if Webware were stagnant. But it's not: the need for non-cookie Session IDs and seamless switching has been discussed several times, and steps have been taken in that direction, most concretely, the path prefix Session ID patch. I and others have proposed porting PHP's seamless GET/cookie Session ID switching to Webware, although it's been postponed because of the amount of design work required. But the point is, work is progressing in this field, even if it happens intermittently coz it's not ppl's highest priority. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tavis R. <ta...@ca...> - 2001-11-22 21:22:31
|
On Thursday 22 November 2001 13:04, Mike Orr wrote: > On Thu, Nov 22, 2001 at 11:26:59AM -0800, Tavis Rudd wrote: > > > As can be guessed from what I've just written, it makes sense > > > to "extend" sessions to allow a user identity to be associated > > > with them. But no more than that should be involved; certainly > > > not what rights someone has. > > > > Totally agreed. Someone's 'rights' should not be stored using > > sessions. Although that's really up to the implementor of a > > particular 'rights management' system. > > However, you are both right. "Rights" are semi-permanent > information which belong in a User or Userrights object. The > session only needs a user identifier. Of course, with Basic > Authentication the user ID doesn't even need to be stored in the > session, but Basic Authentication has its own tradeoffs (not being > able to log out, not being able to re-log in as someone else). Hmm, I've changed my mind about liking the term 'rights management'. It implies 'rights' associated the 'user', where I'd prefer to have 'permissions' associated with the 'resource'. Anyway, that's something for later ... |
From: Darryl <da...@cs...> - 2001-11-23 01:42:44
|
I'd like to add that webware should keep it's user management abstract enough that when someone grafts a GUI onto their business and data objects they dont' have to re-invent the wheel. -Darryl |
From: Chuck E. <Chu...@ya...> - 2001-12-09 16:57:10
|
On Thursday 22 November 2001 05:42 pm, Darryl wrote: > I'd like to add that webware should keep it's user management > abstract enough that when someone grafts a GUI onto their > business and data objects they dont' have to re-invent the wheel. I agree wholeheartedly with that and have taken that approach with both UserKit and MiddleKit. TaskKit is like that as well. They can all be used from any kind of Python program. -Chuck |
From: <ir...@ms...> - 2001-11-22 21:33:58
|
On Thu, Nov 22, 2001 at 11:26:59AM -0800, Tavis Rudd wrote: > > >* How are password's stored internally? plain or hashed? > > > > They should absolutely *not* be stored as plain (clear?) text. Sorry, but that *is* a knee-jerk reaction. There are tradeoffs both ways, and it should be the app developer's/local administrator's choice. If passwords are hashed, it's impossible have an "I forgot my password; mail it to me" screen, because the program cannot unhash the password. You can say, "Oooh, that's unacceptable," but it all depends on what the password grants access to. If it's to my bank account, it better be hasned and behind 128-bit https: . But if it's just to post to a forum or edit an online profile/resume, maybe it doesn't matter that much and it's more important to provide convenience instead. Because forcing ppl to change passwords to something they didn't choose runs another risk: that they'll forget the password again. mod_auth_mysql has a particularly robust design. You can configure whether passwords are added in plaintext, DES, or MySQL PASSWORD() format. Then when checking passwords, you can configure several encryption schemes, so that it will try each scheme in order until one succeeds or they all fail. As for protecting passwords in a database, there are other strategies besides hashing them. For instance: 1) If the password database is on the public server, make sure the db doesn't accept TCP/IP connections from outside the localhost. Lock down login access to the machine and aggressively monitor for web script exploits. 2) If the password database is behind a firewall, the public server hashes the password and sends it to the private server. The private server makes a temporary hash of the control password and uses that for comparision. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Darryl <da...@cs...> - 2001-11-23 01:40:52
|
As for the hashed non-hashed password question. The forgot my password scenario in semi-secure systems is managed by "skill testing questions" which can then allow a new password to be generated and emailed to a stored email address. Then allow user to change to their password. I tend to think hashed passwords are a security minimum, but i guess there could be room to move on this. ----- Original Message ----- > On Thu, Nov 22, 2001 at 11:26:59AM -0800, Tavis Rudd wrote: > > > >* How are password's stored internally? plain or hashed? > > > > > > They should absolutely *not* be stored as plain (clear?) text. > > Sorry, but that *is* a knee-jerk reaction. There are tradeoffs both > ways, and it should be the app developer's/local administrator's choice. > If passwords are hashed, it's impossible have an "I forgot my password; > mail it to me" screen, because the program cannot unhash the password. > You can say, "Oooh, that's unacceptable," but it all depends on what the > password grants access to. If it's to my bank account, it better be hasned > and behind 128-bit https: . But if it's just to post to a forum or edit > an online profile/resume, maybe it doesn't matter that much and it's > more important to provide convenience instead. Because forcing ppl to > change passwords to something they didn't choose runs another risk: > that they'll forget the password again. > > mod_auth_mysql has a particularly robust design. You can configure > whether passwords are added in plaintext, DES, or MySQL PASSWORD() > format. Then when checking passwords, you can configure several > encryption schemes, so that it will try each scheme in order until > one succeeds or they all fail. > > As for protecting passwords in a database, there are other strategies > besides hashing them. For instance: > > 1) If the password database is on the public server, make sure the db > doesn't accept TCP/IP connections from outside the localhost. Lock down > login access to the machine and aggressively monitor for web script > exploits. > > 2) If the password database is behind a firewall, the public server > hashes the password and sends it to the private server. The private > server makes a temporary hash of the control password and uses that > for comparision. > > -- > -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) > http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Tavis R. <ta...@ca...> - 2001-11-22 22:51:27
|
On Thursday 22 November 2001 13:40, Mike Orr wrote: > On Thu, Nov 22, 2001 at 11:26:59AM -0800, Tavis Rudd wrote: > > > >* How are password's stored internally? plain or hashed? > > > > > > They should absolutely *not* be stored as plain (clear?) text. > > Sorry, but that *is* a knee-jerk reaction. There are tradeoffs > both ways, and it should be the app developer's/local > administrator's choice. If passwords are hashed, it's impossible > have an "I forgot my password; mail it to me" screen, because the > program cannot unhash the password. You can say, "Oooh, that's > unacceptable," but it all depends on what the password grants > access to. If it's to my bank account, it better be hasned and > behind 128-bit https: . But if it's just to post to a forum or > edit an online profile/resume, maybe it doesn't matter that much > and it's more important to provide convenience instead. Because > forcing ppl to change passwords to something they didn't choose > runs another risk: that they'll forget the password again. There's ways around this that don't require storage of passwords in clear text. For example, a fall-back challenge question can be used in combination with an email address. The user forgets their password, clicks 'send me a reminder', the server sends an email with a randomized URI the user can go to for the next 30 minutes and change their password. Once they go to the URI they must answer the challenge question correctly before changing their password. The response to the challenge question would also be hashed. The password change would only truly be secure if it was encrypted via SSL, but you could use the javascript implementation md5 to send a hash of the new password instead of clear text when SSL is not available. |
From: <ir...@ms...> - 2001-11-23 03:06:43
|
On Thu, Nov 22, 2001 at 04:01:42PM -0800, Tavis Rudd wrote: > > If passwords are hashed, it's impossible > > have an "I forgot my password; mail it to me" screen, because the > > program cannot unhash the password. You can say, "Oooh, that's > > unacceptable," but it all depends on what the password grants > > access to. If it's to my bank account, it better be hasned and > > behind 128-bit https: . But if it's just to post to a forum or > > edit an online profile/resume, maybe it doesn't matter that much > > and it's more important to provide convenience instead. > > There's ways around this that don't require storage of passwords in > clear text. For example, a fall-back challenge question can be used > in combination with an email address. The user forgets their > password, clicks 'send me a reminder', the server sends an email > with a randomized URI the user can go to for the next 30 minutes and > change their password. Once they go to the URI they must answer the > challenge question correctly before changing their password. The > response to the challenge question would also be hashed. The > password change would only truly be secure if it was encrypted via > SSL, but you could use the javascript implementation md5 to send a > hash of the new password instead of clear text when SSL is not > available. OK, but let's keep in mind that the main feature of Webware is flexibility. We don't want to presume to know what the best password-storage and password-recovery mechanism is for all sites; instead, we want to provide alternative schemes the appadmin can plug in or override as necessary. For instance, the fallback challenge question is good for users who frequent the site and have some level of commitment to it. It's less good for occasional users who maybe aren't sure about the site, to whom one more personal question may be too many (like I was about Yahoo's birthdate question), or who aren't thrilled about memorizing yet another piece of information (who did I say my favorite sports hero is, and how did I spell it?) -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tavis R. <ta...@ca...> - 2001-11-23 06:13:42
|
On Thursday 22 November 2001 19:13, Mike Orr wrote: > OK, but let's keep in mind that the main feature of Webware is > flexibility. We don't want to presume to know what the best > password-storage and password-recovery mechanism is for all sites; > instead, we want to provide alternative schemes the appadmin can > plug in or override as necessary. > > For instance, the fallback challenge question is good for users who > frequent the site and have some level of commitment to it. It's > less good for occasional users who maybe aren't sure about the > site, to whom one more personal question may be too many (like I > was about Yahoo's birthdate question), or who aren't thrilled about > memorizing yet another piece of information (who did I say my > favorite sports hero is, and how did I spell it?) Darryl's suggestion would deal with that level of informality, although I'd much rather send them an email linking to a randomized URL that will allow them to enter a new password during a certain time-window. Sending passwords via email leaves it totally open to sniffing. |
From: Chuck E. <Chu...@ya...> - 2001-12-09 16:48:00
|
On Thursday 22 November 2001 04:01 pm, Tavis Rudd wrote: > There's ways around this that don't require storage of passwords in > clear text. For example, a fall-back challenge question can be used > in combination with an email address. The user forgets their > password, clicks 'send me a reminder', the server sends an email > with a randomized URI the user can go to for the next 30 minutes and > change their password. Once they go to the URI they must answer the > challenge question correctly before changing their password. The > response to the challenge question would also be hashed. The > password change would only truly be secure if it was encrypted via > SSL, but you could use the javascript implementation md5 to send a > hash of the new password instead of clear text when SSL is not > available. While those are all interesting solutions, we still shouldn't preclude a web site developer from mailing the user their password. That is still more convenient to the user that the above solutions and for many sites, the most basic security is all that is required. -Chuck |
From: Chuck E. <Chu...@ya...> - 2001-12-09 17:02:54
|
On Thursday 22 November 2001 07:13 pm, Mike Orr wrote: > For instance, the fallback challenge question is good for users who > frequent the site and have some level of commitment to it. It's less > good for occasional users who maybe aren't sure about the site, to > whom one more personal question may be too many (like I was about > Yahoo's birthdate question), or who aren't thrilled about memorizing > yet another piece of information (who did I say my favorite sports > hero is, and how did I spell it?) How secure is the so-called "challenge question" anyway? I think it's real name should be "hinted password". If you have both a password and a hinted password, isn't your security as low as the lowest security of the two? If so, why have both? If I know your challenge question is "What is your favorite color?" then I'll probably have your account pretty quick. Unless you give a non-related answer, but then you may have trouble remembering that. If the question is "What is your zip code?" then as your coworker in the office, I'm in. This might be mitigated by choosing a more clever question, but then you've got to think it up and make sure you don't forget the response. Of course, I'll need to be able to intercept your e-mail to get the info, but that's no different than for the mail-the-password approach. -Chuck |
From: Ian B. <ia...@co...> - 2001-12-09 18:37:11
|
On Sun, 2001-12-09 at 11:02, Chuck Esterbrook wrote: > On Thursday 22 November 2001 07:13 pm, Mike Orr wrote: > > For instance, the fallback challenge question is good for users who > > frequent the site and have some level of commitment to it. It's less > > good for occasional users who maybe aren't sure about the site, to > > whom one more personal question may be too many (like I was about > > Yahoo's birthdate question), or who aren't thrilled about memorizing > > yet another piece of information (who did I say my favorite sports > > hero is, and how did I spell it?) > > How secure is the so-called "challenge question" anyway? If you are only allowed to reset the password after answering the challenge question, at least a person will be able to detect the intrusion. That helps a little. Ian |