New default: disable scramble password option

Bug #197323 reported by sander
2
Affects Status Importance Assigned to Milestone
Coccinella
New
Low
Mats

Bug Description

The option to scramble the password should be disabled by default. Otherwise it is not possible to connect to some servers that require plain text passwords.

sander (s-devrieze)
Changed in coccinella:
assignee: nobody → matsben
importance: Undecided → Low
Revision history for this message
Mats (matsben) wrote : Re: [Bug 197323] [NEW] New default: disable scramble password option

But scrambling password gives at least a very basic security. Not sure
if this is a good idea. Sending plain text password over an open
network isn't a good idea.

Revision history for this message
sander (s-devrieze) wrote :

What about trying to use SASL+TLS first as a default? With SASL/TLS
enabled, this isn't a risk.

Revision history for this message
Mats (matsben) wrote :

Yes, this can be the time to make this switch.

Revision history for this message
sander (s-devrieze) wrote :

Did you still thought about this? What about changing this option so that it only tries with a plaintext password when the connection is secured? If the connection is not secure it should use the scrambled password. If this fails it should ask the user with a warning dialog if it should try again with a plaintext password.

So, it should work like this:
if connection is encrypted; use plaintext password
else; use scrambled password
  if connection fails; show warning dialog and ask user to connect in an unsafe way

PS: the text in the warning dialog should suggest the user to contact its server admin regarding the security leak in his server.

Related: "Note! You have to enable plain password authentication in your Jabber client to connect to the Tigase server with Drupal database" (from: http://www.tigase.org/tigase-for-drupal-setup )

Revision history for this message
Mats (matsben) wrote : Re: [Bug 197323] Re: New default: disable scramble password option

On Sun, Jun 22, 2008 at 9:38 AM, sander <email address hidden> wrote:
> Did you still thought about this? What about changing this option so
> that it only tries with a plaintext password when the connection is
> secured? If the connection is not secure it should use the scrambled
> password. If this fails it should ask the user with a warning dialog if
> it should try again with a plaintext password.
>
> So, it should work like this:
> if connection is encrypted; use plaintext password
> else; use scrambled password
> if connection fails; show warning dialog and ask user to connect in an unsafe way

SASL has its own way of sending the password that has nothing to do
with "plain text password" option. That option only applies to the old
jabber way of connecting to servers. Perhaps I shall put the SASL/TLS
tab first in order. Then the question of failbacks:
If tls fails I think the whole connection process fails, but can't
find a server right now
without TLS. Ahh, my own, of course. So if SASL/TLS fails fallback to SASL.
And if that fails, fallback to old jabber way with message as indicated.
In the old jabber world "scramble password" always worked. There is no
need to have a fallback from this.

>
> PS: the text in the warning dialog should suggest the user to contact
> its server admin regarding the security leak in his server.

In that case I don't wont to be a server admin :-)

>
>
> Related: "Note! You have to enable plain password authentication in your Jabber client to connect to the Tigase server with Drupal database" (from: http://www.tigase.org/tigase-for-drupal-setup )
>
> --
> New default: disable scramble password option
> https://bugs.launchpad.net/bugs/197323
> You received this bug notification because you are a bug assignee.
>

Revision history for this message
sander (s-devrieze) wrote :

> In the old jabber world "scramble password" always worked. There is no
> need to have a fallback from this.

I believe it does not work for tigase.org

Revision history for this message
Lukáš 'Spike' Polívka (lukas-polivka) wrote :

I suggest options “Allow plaint text password over secured connection”, “Always”, “Never”, with the first one to be default (exactly like Psi). Also, if server offers non-plain-text and plain-text, prefer the former.

Then if StartTLS is used, it should work with most servers, including Tigase.org and Google Talk (these services don't store plain-text, readable passwords like most ejabberd etc., only hashes, so they can use only plain-text password exchange).

Revision history for this message
Lukáš 'Spike' Polívka (lukas-polivka) wrote :

Exact options from Psi:

Encrypt connection: Always / When available* / Never / Legacy SSL
Allow plaintext authentication: Always / Over encrypted connection* / Never

* Default

(Sorry I didn't check right away.)

Revision history for this message
Mats (matsben) wrote :

I think that I need a new kind of abstraction for the connection
options in this case. I wasn't too happy with the existing one which
reads:

# -digest 0|1 (means if password
should be hashed in old jabber way)
# -secure 0|1 @@@ Change this to -xmpp ?
# -method ssl|tlssasl|sasl

#
# o Note the naming convention for -method!
# ssl using direct tls socket connection
# it corresponds to the original jabber method
# tlssasl in stream tls negotiation + sasl, xmpp compliant
# XMPP requires sasl after starttls!
# sasl only sasl authentication
#
# o @@@ Perhaps a better way is to use a -xmpp switch that sets
# the main mode of operation, and then use whatever as
sub switches.

As I indicated above, perhaps it would be better using another
abstraction where I first decide if connecting using old jabber way
(-xmpp 0) or the xmpp way (-xmpp 1), and then have switches that pick
the details of each mode like SASL, TLS etc. But the user should never
bother picking the mode, just the degree of security wanted. Need to
think...

Revision history for this message
Mats (matsben) wrote :

I should add that this potentially also changes the profiles saved in
the prefs files since each connection setting is saved with each
profile. If I'm going to change the format I could change the
    {name1 {server1 username1 password1 ?-key value ...?} ...
to
    {name1 {JID1 ?-key value ...?} ...
at the same time. Password could be made an option: -password secret

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.