[pskmail] Re: Sorry, Wrong password.

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Tue, 8 May 2012 05:23:16 +1000

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