From: Serge D. <se...@dr...> - 2009-07-29 21:51:29
|
Hello All, I have a setup of squirrelmail which uses one time passwords. However at logon time I get an error from avelsieve, that it cannot authenticate. This, of course makes sense, as the one time password is already 'used up' by squirrelmail. Thus my question: How can I prevent avelsieve from becoming active when a user logs on using a otpw? If possible if should be removed from the plugins list for such a session. I find out about this cindition in redirect.php. Any help would be appreciated. Serge |
From: Paul L. <pa...@sq...> - 2009-07-30 02:19:59
|
On 7/29/09, Serge Droz <se...@dr...> wrote: > Hello All, > > I have a setup of squirrelmail which uses one time passwords. > However at logon time I get an error from avelsieve, that it cannot > authenticate. > This, of course makes sense, as the one time password is already 'used > up' by squirrelmail. > Thus my question: How can I prevent avelsieve from becoming active when > a user logs on using a otpw? If possible if should be removed from the > plugins list for such a session. > I find out about this cindition in redirect.php. I don't use such a system, so don't exactly understand why avelsieve would be using your OTP apart from the normal IMAP login. But what I can say is that there should be no way for SquirrelMail to know if the password is one time or not -- all it does, after all, is pass the username and password to the IMAP server for authentication. That's it. If the password works, the user is logged in. Doesn't matter if it's OTP or not. Most IMAP servers aren't going to reply back to you telling you it was OTP or was not. Are you sure the problem isn't that SquirrelMail logs in more than once itself during the login process (and at least once again for most subsequent page requests)? > Any help would be appreciated. If *YOU* know of a way to inspect the password and know the difference between OTP and non-OTP or know of a way to ask the IMAP server about it, then you can code a plugin that does this detection during the login_before or login_verified (the latter is preferred if possible) and then you can clear avelsieve out of the $squirrelmail_plugin_hooks array or use the Compatibility plugin's remove_plugin() function to do it for you. Or you can take a test drive of the OTP plugin I have developed (not released yet), which manages OTPs in SquirrelMail (slightly less secure than doing it in the IMAP server itself). That plugin can be configured to turn off certain functionalities (including plugins) when a user is logging in with a OTP (although in that context, I'm not sure you'll have the same problem with avelsieve). -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php |
From: Serge D. <se...@dr...> - 2009-07-30 06:28:07
|
Hello Paul, thanks for the quick answer. Maybe I should have explained a bit more how we implement this. All the OTPs start with a certain prefix (eg ####). This is what I check for. After all the users enters tha password into the webinterface. The Imapserver can use this password exactly once, so you have one go. alvelsieve needs to authenticate against managesieve, it does this using the same credentials. As the otpw has been used before to log into the imap server this won't work. > If *YOU* know of a way to inspect the password and know the difference > between OTP and non-OTP or know of a way to ask the IMAP server about > it, then you can code a plugin that does this detection during the > login_before or login_verified (the latter is preferred if possible) > and then you can clear avelsieve out of the $squirrelmail_plugin_hooks > array or use the Compatibility plugin's remove_plugin() function to do > it for you. That's why I want to disable this. I'll try to follow up on you suggestion > > Or you can take a test drive of the OTP plugin I have developed (not > released yet), which manages OTPs in SquirrelMail (slightly less > secure than doing it in the IMAP server itself). That plugin can be > configured to turn off certain functionalities (including plugins) > when a user is logging in with a OTP (although in that context, I'm > not sure you'll have the same problem with avelsieve). > I'd certainly like to look at this and test this out and provide feedback. Thanks again Serge |
From: Alexandros V. <av...@no...> - 2009-07-30 07:43:21
|
On Thu, 30 Jul 2009 08:27:49 +0200 Serge Droz <se...@dr...> wrote: > alvelsieve needs to authenticate against managesieve, it does this > using the same credentials. As the otpw has been used before to log > into the imap server this won't work. Say we take Squirrelmail out of the equation and assume that the user is using, for instance, Thunderbird with its ManageSieve add-on. How would OTP authentication work _then_, server-side? Is your ManageSieve daemon aware of the auth scheme? Would the user need to provide the new / next OTP? |
From: Paul L. <pa...@sq...> - 2009-07-30 07:54:59
|
On 7/29/09, Serge Droz <se...@dr...> wrote: > Hello Paul, > > thanks for the quick answer. > > Maybe I should have explained a bit more how we implement this. > > All the OTPs start with a certain prefix (eg ####). This is what I check > for. > After all the users enters tha password into the webinterface. > The Imapserver can use this password exactly once, so you have one go. You need to re-read what I wrote, then. SquirrelMail is a web application, which means it is nearly stateless. It logs into the IMAP server a lot more than once. I don't think your scheme will work no matter if avelsieve is part of it or not. > alvelsieve needs to authenticate against managesieve, it does this using the > same credentials. As the otpw has been used before to log into the imap > server > this won't work. > > >> If *YOU* know of a way to inspect the password and know the difference >> between OTP and non-OTP or know of a way to ask the IMAP server about >> it, then you can code a plugin that does this detection during the >> login_before or login_verified (the latter is preferred if possible) >> and then you can clear avelsieve out of the $squirrelmail_plugin_hooks >> array or use the Compatibility plugin's remove_plugin() function to do >> it for you. > > That's why I want to disable this. I'll try to follow up on you suggestion > >> >> Or you can take a test drive of the OTP plugin I have developed (not >> released yet), which manages OTPs in SquirrelMail (slightly less >> secure than doing it in the IMAP server itself). That plugin can be >> configured to turn off certain functionalities (including plugins) >> when a user is logging in with a OTP (although in that context, I'm >> not sure you'll have the same problem with avelsieve). >> > I'd certainly like to look at this and test this out and provide feedback. Sent offlist. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php |
From: Serge D. <se...@dr...> - 2009-07-30 08:11:48
|
> > You need to re-read what I wrote, then. SquirrelMail is a web > application, which means it is nearly stateless. It logs into the > IMAP server a lot more than once. I don't think your scheme will work > no matter if avelsieve is part of it or not. > No, it does wokk perfectly well without the avelsievplugin, if you use it together with imapproxy http://www.imapproxy.org/. Essentially imapproxy remembers that session and keeps it open, so you can "reuse" the OTPW here. So this is how it works 1. Connection: SM --(un,pw) -> imapproxy -> autenticate -> imapd 2. Connection: SM --(un,pw) -> imapproxy <- reuse exisiting session -> imapd ... n. logout -> imapproxy -> logut imapd Cheers Serge |
From: Paul L. <pa...@sq...> - 2009-07-30 09:30:39
|
On 7/30/09, Serge Droz <se...@dr...> wrote: >> >> You need to re-read what I wrote, then. SquirrelMail is a web >> application, which means it is nearly stateless. It logs into the >> IMAP server a lot more than once. I don't think your scheme will work >> no matter if avelsieve is part of it or not. >> > > No, it does wokk perfectly well without the avelsievplugin, if you use it > together with imapproxy http://www.imapproxy.org/. > Essentially imapproxy remembers that session and keeps it open, so you can > "reuse" the OTPW here. But you are making a bad assumption that the imapproxy session won't expire. They *can* and *do* expire in the middle of a SquirrelMail session which does not expire (imapproxy restarts another session seamlessly for the user... but that would break in your case). > So this is how it works > > 1. Connection: SM --(un,pw) -> imapproxy -> autenticate -> imapd > 2. Connection: SM --(un,pw) -> imapproxy <- reuse exisiting session -> imapd 3. imapproxy session times out 4. SM makes another page request 5. imapproxy tries to create a new session with the same password as given by SM 6. IMAP rejects the password, as it's already been used once 7. SM tells the user the password is bad and logs the user out unexpectedly -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php |
From: Serge D. <se...@dr...> - 2009-07-30 10:19:55
|
>> So this is how it works >> >> 1. Connection: SM --(un,pw) -> imapproxy -> autenticate -> imapd >> 2. Connection: SM --(un,pw) -> imapproxy <- reuse exisiting session -> imapd > > 3. imapproxy session times out > 4. SM makes another page request > 5. imapproxy tries to create a new session with the same password as given by SM > 6. IMAP rejects the password, as it's already been used once > 7. SM tells the user the password is bad and logs the user out unexpectedly > That's correct, and it's not nice, I agree. But I accept that if I can read my mail from an insecure place. On the plus side I really have nothing to store on the server, that could be a problem. By the way we use: http://www.cl.cam.ac.uk/~mgk25/otpw.html adapted to a virtual environment Serge |
From: Alexandros V. <av...@no...> - 2009-07-30 08:46:40
Attachments:
signature.asc
|
Serge, I assume you use Cyrus IMAP server-side, and you've configured Cyrus SASL to use OTPs, right? Cyrus has different processes that listen for imap and sieve connections. They are completely unrelated to each other, in the sense that one can connect to either one of these completely independently and with no shared "session" information between them. I don't have any 1st-hand experience with OTPs, but because of the fact I mentioned, I'm guessing that the connection to the sieve daemon will require the _next_ password in the list of OTPs. But avelsieve tries to connect with the password stored within squirrelmail, which has already been used -- to be precise, it is still currently in use by imapproxy, but I guess it has expired. I can think of some solutions to your problem, some of them more realistic than the others: * a similar program such as imapproxy, but working on behalf of the sieve daemon, that maintains and caches the connection to port 2000 without re-submitting auth credentials. Who's going to write that? :-) Actually a generic protocol proxy which knows a bit about some common protocols could be written, or Perdition ( http://www.vergenet.net/linux/perdition/ ) or imapproxy being extended to support ManageSieve. * your cyrus-sasl + otp scheme being reconfigured to allow loose expiration towards the sieve daemon. Perhaps you should look into this. Can you fine-tune your otp scheme to allow this? * avelsieve programmed to re-require authentication when needed, but this would mean switching to "conservative" mode. This will allow you to make any changes "offline" (i.e. without actually connecting to managesieve for _each_ and every one) and save them once, so two password inputs would be needed then. I don't particularly like this, as it requires some work on current avelsieve code :-) * Apache/PHP supporting sockets that remain open across http requests :-P Perhaps someone else with experience with OTPs can pitch in in case I'm making any mistake. And there might be some better real-world solution that I can't think of right now (not much caffeine in my veins as of yet today). -- Alexandros Vellis National & Kapodistrian University of Athens Network Operations Centre |
From: Paul L. <pa...@sq...> - 2009-07-30 09:34:21
|
On 7/30/09, Alexandros Vellis <av...@no...> wrote: > Serge, I assume you use Cyrus IMAP server-side, and you've configured > Cyrus SASL to use OTPs, right? > > Cyrus has different processes that listen for imap and sieve > connections. They are completely unrelated to each other, in the sense > that one can connect to either one of these completely independently > and with no shared "session" information between them. > > I don't have any 1st-hand experience with OTPs, but because of the fact > I mentioned, I'm guessing that the connection to the sieve daemon will > require the _next_ password in the list of OTPs. But avelsieve tries to > connect with the password stored within squirrelmail, which has already > been used -- to be precise, it is still currently in use by imapproxy, > but I guess it has expired. > > I can think of some solutions to your problem, some of them more > realistic than the others: > > * a similar program such as imapproxy, but working on behalf of the > sieve daemon, that maintains and caches the connection to port 2000 > without re-submitting auth credentials. Who's going to write > that? :-) Actually a generic protocol proxy which knows a bit > about some common protocols could be written, or Perdition > ( http://www.vergenet.net/linux/perdition/ ) or imapproxy being > extended to support ManageSieve. > > * your cyrus-sasl + otp scheme being reconfigured to allow loose > expiration towards the sieve daemon. Perhaps you should look into > this. Can you fine-tune your otp scheme to allow this? > > * avelsieve programmed to re-require authentication when needed, but > this would mean switching to "conservative" mode. This will allow you > to make any changes "offline" (i.e. without actually connecting to > managesieve for _each_ and every one) and save them once, so two > password inputs would be needed then. I don't particularly like this, > as it requires some work on current avelsieve code :-) > > * Apache/PHP supporting sockets that remain open across http > requests :-P I like that one! :-) The other option is to use the OTP plugin I developed for SM, which would work out of the box for this case. > Perhaps someone else with experience with OTPs can pitch in in case I'm > making any mistake. And there might be some better real-world > solution that I can't think of right now (not much caffeine in my veins > as of yet today). -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donations.php |