Re: [JDEV] Passwords
On Mon, Jun 25, 2001 at 11:27:31AM -0400, Tony Byers wrote: Hello, Could anyone tell me why the server needs to pass through authreg.c twice for a sign on? And why does it have the username but not the password on the first pass? Lastly, is there any way to get the password on the first pass? I would like to see if the user comes up as null, then do an automatic register (assuming they pass a kerberos check). If anyone knows of a better way to do this, I would really appreciate any advice. (1) twice, because of an iq-get to discover authentication methods available, followed by an iq-set to send the credentials (2) it only has the username on the first pass as this is the iq-get, and the username is needed (nothing else) to look up the user's spool data, so the auth modules can see if the appropriate data is stored for that user and that method (3) auto-register, comes up as null? - hmm. If a user doesn't exist, you get a 401 unauthorized, not a null, on an authentication (iq-set) attempt. One way would be to look into how iq:register works - e.g. if you try and register an *existing* user you get an error (409 Not Available, I think) whereas if the user doesn't exist, the registration is successful. I'm not sure this is a good idea anyway, I'm just thinking aloud. There's also the auth/ 'hack' which allows you to substitute your own-rolled authentication mechanism(s), which you might want to look into, as it would give you more control over things. Hope that helps dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords
Tony, I uploaded a RADIUS module to the contrib directory a couple months back that lets users register if they can be authenticated by a RADIUS server. I've been away for a while, and have 800 emails to catch up on, so I don't know if anyone has done anything with it or found problems, but it sounds similar to want you want to do. -Michael Tony Byers wrote: Hello, Could anyone tell me why the server needs to pass through authreg.c twice for a sign on? And why does it have the username but not the password on the first pass? Lastly, is there any way to get the password on the first pass? I would like to see if the user comes up as null, then do an automatic register (assuming they pass a kerberos check). If anyone knows of a better way to do this, I would really appreciate any advice. Tony ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords, zero-K and storage
At 12:54 AM 6/20/2001 +0100, you wrote: If someone really wants passwords to be secure, they need to use a secure method of account registration, authentication, and renewal in the case of 0k. Yes, this seems to be the weakspot of 0k in general, the user-initiated password setting and changing... I've never been too hot on the 0k stuff, but surely setting new passwords could be sequenced as requested in the initial jabber:iq:auth query when sent, therefore going in a hashed way rather than as plain-text, keeping the plain-text off the wire? Yeah. There are a ton of ways to do it. Most of this is just a matter of deciding on a standard method so that all the servers and clients can interoperate properly. For instance, if you just look at 0k from the docs page, you can't actually implement it even though the server and some clients are using it today... If you want to add it to your client, you pretty much have to reverse engineer the protocol or read the server source. ;( On the positive side, once the Foundation is setup and running, and the standards process gets into swing, I think we'll be seeing a very positive standards effort (heck I'm planning on putting some serious work in it) so this should only be a temporary situation. -iain _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords, zero-K and storage
At 12:15 AM 6/20/2001 +0100, you wrote: suppose we should wait until the Foundation/JEP/JIG etc is all settled first... *sigh*/side note I'm sure that this and other issues that may have fallen between the cracks will find a good home with the Foundation and the Jabelin project. I only wish my JabberC learning would go faster so I could help out more :-/ :) Yeah. I know how that goes. I'm looking forward to having the infrastructure in place so we can start organizing and looking for these lost pieces. Currently I'm constantly wondering, Is the spec right or did they change it in jabberd and not update the docs... *sigh* :) -iain _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords, zero-K and storage
On Fri, Jun 15, 2001 at 08:35:45PM -0500, Iain Shigeoka wrote: It would seem that the only real way of doing this is to store the plaintext password and user name _somewhere_ so you can move records from one authentication system to another. (storing plain passwords, hashes, or 0k sequences). At least with the current system. Now the implementation may encrypt all these passwords so only the server can access them, or perhaps a migration utility in the server, etc... but at some point, somewhere, the plaintext passwords will need to exist. Otherwise, when you plug in a next generation authentication system, you'll need to have everyone re-send or regenerate their password info. Am I missing something? I don't think so, but I've never spent that much time thinking about security. To me, requiring a password re-send is less heinous than storing the password in plaintext anywhere. ... So far this has not been an issue because we've always had the plaintext password on the server which served as the common data format for password information (method 1 with plaintext being the special password storage format... ha ha ha). It was easy to upgrade to 0k because we could upgrade people on the server using the plaintext password. However, I expect that many/most would like to use the 0k advantage of no plaintext password at all on the server. If this is the case, then the next auth protocol (if there will be one) is in for some trouble if we don't address things sometime. Sure. I guess the concept of wanting to be able to change from one method to another when the starting method is 'proper' 0k *without* involving the user simply does not compute. side noteIt would be nice nice for server's to be backward compatible and still support digest if not plaintext passwords. In this case, the I'm assuming that the plaintext storage is necessary for digest to ensure security over the wire (as opposed to on the server) - so that different tokens can be used to keep the digest 'fresh' and different. That I think is why mod_plain_digest is merely a 'parasite' on mod_plain_auth - it lets it do all the work, except for the glory-bit at the credential checking stage. suppose we should wait until the Foundation/JEP/JIG etc is all settled first... *sigh*/side note I'm sure that this and other issues that may have fallen between the cracks will find a good home with the Foundation and the Jabelin project. I only wish my JabberC learning would go faster so I could help out more :-/ dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords, zero-K and storage
On Mon, Jun 18, 2001 at 01:31:07PM -0600, David Waite wrote: If someone really wants passwords to be secure, they need to use a secure method of account registration, authentication, and renewal in the case of 0k. Yes, this seems to be the weakspot of 0k in general, the user-initiated password setting and changing... dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords, zero-K and storage
If someone really wants passwords to be secure, they need to use a secure method of account registration, authentication, and renewal in the case of 0k. Yes, this seems to be the weakspot of 0k in general, the user-initiated password setting and changing... I've never been too hot on the 0k stuff, but surely setting new passwords could be sequenced as requested in the initial jabber:iq:auth query when sent, therefore going in a hashed way rather than as plain-text, keeping the plain-text off the wire? -- Oliver Wing ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Passwords, zero-K and storage
Glad you brought up this point. I've been wondering about highly related issues that might as well get thrown in. At 11:52 PM 6/15/2001 +0100, DJ Adams wrote: there was a question in the jdev room about how to avoid storing usernames and passwords in the username.xml files on the server.[1] I blurted out 'zero-K!' for half the answer - a way of removing the liability of storing password on the server[2]. This was followed by another answer a couple of mins later which contradicted me. I tried it out on my server, and sure enough, even when the mod_auth_plain and mod_auth_digest modules were commented out of JSM's load list, a password in plain text was stored on the server as well as the zero-K stuff. ... [snip] Anyway, I would suggest that the snippet of code in mod_register_new() shown above is both redundant and wrong, and should be removed. The purpose of this code is served by mod_auth_plain and / or mod_auth_0k. Of course, I'm ready to be contradicted again; I'd like to hear what others think. I've tried this out (removing the snippet) on my test server and it solves the problem and doesn't cause any others, as far as my minimal testing has shown. Note: my comments are from a general server design standpoint and not specific to jabberd. I've been playing around with these issues and from a modular standpoint, the system seems a bit incomplete. Theoretically, when you plug in a new auth module, you should be able to use it to immediately authenticate new and existing accounts (accounts established and authenticated against older user records). For instance, I should be able to unplug digest and plug in 0k and keep on chugging. It would seem that the only real way of doing this is to store the plaintext password and user name _somewhere_ so you can move records from one authentication system to another. (storing plain passwords, hashes, or 0k sequences). At least with the current system. Now the implementation may encrypt all these passwords so only the server can access them, or perhaps a migration utility in the server, etc... but at some point, somewhere, the plaintext passwords will need to exist. Otherwise, when you plug in a next generation authentication system, you'll need to have everyone re-send or regenerate their password info. Am I missing something? This of course assumes that we need to worry about new auth protocols. If the existing 2 and a half (see side note at bottom) auth protocols are pretty much it, then I guess there's not much of an issue here. However, since I doubt that this is true, it seems to be a serious problem for upgrading existing servers that may have thousands of user accounts. I guess what I'm trying to say is, I would like to see the auth system build to support secure _and_ seamless upgrades of authentication systems. Method 1: My thought is either we establish a standard server-side password data format other than plaintext to provide a common seed password that can be used to generate passwords in whatever module we are using. So when we install a new module and the existing user accounts don't have password data in their format, they can ask the server, hey, give me a seed for this user, and use the data to generate its data. The reason we need it standardized is so that future auth algorithms can be designed to be compatible with the data. To avoid plaintext, we store the password in a way that the data displays certain mathematical properties that can be exploited for generating new passwords in new systems while preventing their use to generate current passwords with current systems. Probably not a trivial task. Method 2: Another approach is to establish yet another protocol to allow clients to authenticate with an existing auth module, then once logged in, generate new information with a new auth module to upgrade to that authentication scheme. This protocol can be very simple (e.g. force the client to auth twice: first with one module then with another) but the clients need to know about this in a standard (otherwise, only client A will work with server A). This approach is basically a let the client worry about it strategy. The client must know the plain text password, and can authenticate against both systems using it. The worry is that client's will have a lot of auth bloat having to be able to support all auth systems in order to seamlessly access any jabber server (versus only needing to know about one auth method and use it on any jabber server if the server's are responsible for making these conversions). So far this has not been an issue because we've always had the plaintext password on the server which served as the common data format for password information (method 1 with plaintext being the special password storage format... ha ha ha). It was easy to upgrade to 0k because we could upgrade people on the server using the plaintext password. However, I expect
Re: [JDEV] Passwords, zero-K and storage
Iain Shigeoka wrote: Method 2: Another approach is to establish yet another protocol to allow clients to authenticate with an existing auth module, then once logged in, generate new information with a new auth module to upgrade to that authentication scheme. This protocol can be very simple (e.g. force the client to auth twice: first with one module then with another) but the clients need to know about this in a standard (otherwise, only client A will work with server A). This approach is basically a let the client worry about it strategy. The client must know the plain text password, and can authenticate against both systems using it. The worry is that client's will have a lot of auth bloat having to be able to support all auth systems in order to seamlessly access any jabber server (versus only needing to know about one auth method and use it on any jabber server if the server's are responsible for making these conversions). I would say a third method should just be to have the authentication module handle authentication, not the server. Currently for all three methods (plaintext, digest, 0k), the server fetches data and compares internally - it should instead just *ask* some external authentication service whether or not the user is authenticated. This would not provide migration for users within jabber XDB to some service outside of xdb - but if you are authenticating against a system such as LDAP or kerberos, you don't want to do this anyways. So far this has not been an issue because we've always had the plaintext password on the server which served as the common data format for password information (method 1 with plaintext being the special password storage format... ha ha ha). It was easy to upgrade to 0k because we could upgrade people on the server using the plaintext password. However, I expect that many/most would like to use the 0k advantage of no plaintext password at all on the server. If this is the case, then the next auth protocol (if there will be one) is in for some trouble if we don't address things sometime. If someone really wants passwords to be secure, they need to use a secure method of account registration, authentication, and renewal in the case of 0k. The only secure registration method I've seen so far is Jabber-thru-SSL, and the server does not enforce any behavior based on the connection being through or not through SSL (such as limiting plaintext authentication, turning off registration, not allowing password changes). There is a lot of work left. -David Waite ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
RE: [JDEV] passwords
Hi Tony, I think the following will lead to resolution of your case. There is 2 rounds of I/O between client and server during authentication. During the first round the client learns what the server is expecting. During the second round client sends the actual values and the server performs the actual authentication. During the first round the value of password in NULL, which is logical and it is probably your case. As for the solution: You should check the value during JPACKET__SET subtype and not the JPACKET__GET which is the first round. Use this if statement to check the round of negotiation (which is the packet subtype). if (jpacket_subtype(m-packet) == JPACKET__SET) hope this helps zad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Byers Sent: Friday, May 11, 2001 9:43 PM To: [EMAIL PROTECTED] Subject: [JDEV] passwords Hello - I thought I had this figured out but I don't. Does anyone know how to obtain the password from the client in any of the mod_auth files. I've stuck the following line in many different places and password is always NULL. password = xmlnode_get_tag_data(m-packet-iq, password); I've commented out mod_auth_digest and mod_auth_0k in jabber.xml so I'm assuming that password verification must be done in mod_auth_plain_jane. Any information about the client password would be great. I'm totally lost at this point. Tony Byers ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] passwords
Hello - I thought I had this figured out but I don't. Does anyone know how to obtain the password from the client in any of the mod_auth files. I've stuck the following line in many different places and password is always NULL. password = xmlnode_get_tag_data(m-packet-iq, password); I've commented out mod_auth_digest and mod_auth_0k in jabber.xml so I'm assuming that password verification must be done in mod_auth_plain_jane. Any information about the client password would be great. I'm totally lost at this point. Tony Byers ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
