Re: [SM-USERS] One time password for SM

[Paul L. <pa...@sq...>]

On Tue, May 20, 2008 at 12:11 PM, Nick Owen <no...@wi...> wrote:
>>> I don't think so, but as I said, I could be wrong.
>>
>> I think you are.  WHY don't you think so?  If imapproxy decides it's
>> time to release the user's login session (sure, this depends on a
>> number of factors in the configuration of all the tools involved -
>> imapproxy, SM, PHP), the password is lost and your webmail session
>> dies unexpectedly.  If you have enough idle time configured into
>> everything and auto folder list refresh turned on, you might be able
>> to get away with it, but this relies on a user config setting (folder
>> refresh), which isn't ideal.
>
> ahh, you are correct - I mis-read your post (sorry - too many windows
> open literally and figuratively).  Imapproxy will time out a session
> forcing you to generate a new OTP.  However, I view that as a security
> feature and not as a problem. If you need two-factor authentication
> for webmail you also want to time-out the sessions - and so it should
> not be "unexpected".

Fair enough

>>> N.B: the version in the how-to uses radius, which is not part of the
>>> open source Community Version.  However, we have a PHP network client
>>> that could be integrated with the Community version.  Also, since I
>>> wrote that how-to for SM, we have added mutual https authentication
>>> that prevents network-based MITM attacks by validating the ssl cert
>>> for the user. You can find out more about that
>>> here:http://www.wikidsystems.com/learn-more/technology/mutual_authentication.
>>
>> Keep up the great work!
>
> Thanks!
>
>>
>>
>>>>>> OR are there other suggestions?  TIA
>>>>>
>>>>> A plugin hooked into the logout page of SquirrelMail could be used to
>>>>> create a new password if the system allows it, but I don't have any
>>>>> suggestions right now on how to do that in practise.
>>>>
>>>> I actually have a plugin sitting around that creates OTPs from within
>>>> the SM interface (they are ONLY *SquirrelMail* OTPs); the somewhat
>>>> insecure part of the puzzle being that SM actually takes the user's
>>>> real password and stores it in an encrypted file.  The encryption is
>>>> decent (any mcrypt-supported algorithm works), but it's still always
>>>> an iffy proposition for an application to store user passwords.  This
>>>> particular plugin is years old and needs a lot of face-lifting before
>>>> it would be ready for use.
>>