[pskmail] Re: Sorry, Wrong password.

  • From: Pär Crusefalk <per@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 07 May 2012 22:43:02 +0200

Thanks John,

If it resets the whole record then its fine. I have not looked at that
code yet so I'll know as soon as I see it ;-).

73, Per

tis 2012-05-08 klockan 05:23 +1000 skrev John Douyere:
> Hi Per,
> 
> 
> Just a note on this. My understanding was that a  RESETPASSWORD  would
> reset the whole client's record. 
> 
> 
> If that was the case, then the RESETPASSWORD would work as intended
> and would allow a client to recover a lost session password situation
> by re-updating the sever with his email settings and (a potentially
> new) session password.
> 
> 
> But it would prevent an attacker to gain access to the email. 
> 
> 
> In fact it should be called RESETRECORD or something equivalent and be
> in a drop down menu.
> 
> 
> The only "damage" then would be the inconvenience of having to perform
> a new "update server".
> 
> 
>  73, John
> 
> 
> 
> 
> On Tue, May 8, 2012 at 2:10 AM, Pär Crusefalk <per@xxxxxxxxxxxx>
> wrote:
>         Hi,
>         
>         I will have a look at this. I'm getting closer to a new
>         release and I
>         have just set up my bench test server to be able to test it. I
>         have
>         gotten around the password before by not entering any, not on
>         upload and
>         not later. It could be that we only need to clarify the
>         procedure better
>         or there could be some technical issue, I'll test it... Apart
>         from
>         fldigi I think this has been a real source of trouble lately.
>         
>         Regarding the security I think the procedure should be:
>         1. User uploads settings including session password.
>         2. Next time the user connects the server needs the session
>         password to
>         temporarily decrypt the email password and get email.
>         3. An "attacker" pretends to be a known user and connects,
>         server
>         requests session password to be able to get email etc. The
>         attacker
>         lacks that and gets no email (great so far).
>         4. "Attacker" tries to upload new settings but of course lacks
>         the
>         intended users email settings so gets nothing (good so far).
>         5. Attacker connects and requests that the server change the
>         session
>         password to some word the attacker knows. Here is where it
>         fails.
>         So, RESETPASSWORD, should be removed and last time I checked
>         it was.
>         The way to reset the password should be to reupload the proper
>         email
>         settings including a clever session password. Then it should
>         be fine.
>         
>         73, Per
>         sm0rwo
>         
>         
>         
>         mån 2012-05-07 klockan 22:02 +1000 skrev Steve:
>         > ~RESETPASSWORD resulted in a "Huh?? I don't understand
>         ~RESETPASSWORD"
>         > response. I'm trying :RESETPASSWORD now, but the
>         client/server talking
>         > over each other is stopping the command getting through.
>         >
>         > Even when FLDigi has registered a <SOH>, the server and/or
>         client will
>         > still transmit a second later. Does an application using
>         FLDigi not
>         > see this text real-time?
>         >
>         > I need to go to bed and look at it tomorrow when I'm in a
>         better frame
>         > of mind ;-)
>         >
>         > Steve.
>         >
>         >
>         > On 05/07/2012 09:31 PM, John Douyere wrote:
>         > > Hi Ian and Steve,
>         > >
>         > > The session password is there to prevent another user from
>         using
>         > > your stored details on a server to read your mail or send
>         email on
>         > > your behalf.
>         > >
>         > > The situation I believe you are in is that the session
>         password in
>         > > the client does not match the one in the server and
>         therefore does
>         > > not let you change the session password, which is logical
>         otherwise
>         > > it would defeat the purpose.
>         > >
>         > > The solution is either a manual delete of the client's
>         record in the
>         > > server with the rflinkserver.pl routine or a
>         ~RESETPASSWORD issued
>         > > from the client followed by an update server which should
>         update the
>         > > email details and the session password.
>         > >
>         > > If you want we can have a 600Ohms or Skype session to get
>         you going.
>         > >
>         > > 73, John
>         > >
>         > > On 07/05/2012 8:28 PM, "Ian Bennett" <ibennett@xxxxxxxxxx>
>         wrote:
>         > >         Group,
>         > >                Pardon my ignorance but why was the session
>         password
>         > >         feature implemented?? I maybe missing something
>         but all it
>         > >         seems to be doing is causing problems.
>         > >                I too am keen to get this working as it is
>         me whom
>         > >         Steve is trying to support on an upcoming trek.
>         > >
>         > >         Ian
>         > >         VK1IAN
>         > >
>         > >         On 07/05/12 20:03, Steve wrote:
>         > >                 Hello again,
>         > >
>         > >                 Server is 1.6.5
>         > >                 Client is 1.5.8
>         > >                 FLDigi 3.21.40 compiled from patched
>         sources from
>         > >                 pskmail download site.
>         > >
>         > >                 Problem 1:
>         > >                 The sorry, wrong password problem is still
>         there.
>         > >                 Initially I thought that a password was
>         optional, so
>         > >                 left it out. Always
>         > >                 got the "sorry, wrong password" without
>         it, so I set
>         > >                 it in the client
>         > >                 (preference -> edit -> user data ->
>         session
>         > >                 password) and did an update
>         > >                 server. I still get "sorry, wrong
>         password".
>         > >
>         > >                 So, I thought that maybe that part of the
>         client is
>         > >                 broken, so I just
>         > >                 tried via :SETPASSWORD. This time the
>         server
>         > >                 replied :-
>         > >                 Sorry, not allowed...
>         > >                 Password not changed!
>         > >
>         > >                 Obviously no one else is having this
>         problem, so
>         > >                 could someone point me
>         > >                 to the part of rflinkusers.pl this session
>         password
>         > >                 update is handled?
>         > >                 Is it actually called findupassword in the
>         code?
>         > >                 I'd like to do some debugging as this is
>         driving me
>         > >                 mad ;-)
>         > >
>         > >
>         > >
>         > >                 Problem 2:
>         > >                 I keep getting the server and client
>         talking over
>         > >                 the top of each other.
>         > >                 The server and client are right next to
>         each other
>         > >                 and the signal
>         > >                 strength is excellent. Any hints how to
>         stop this?
>         > >
>         > >                 I really want this to work :-(
>         > >
>         > >
>         > >
>         > >
>         > >
>         
>         
>         
>         
> 
>

Other related posts:

  1. Home
  2. pskmail
  3. Archive
  4. 05-2012