[JDEV] Account information storage, plaintext?

[Tijl Houtbeckers]

Robert Norris <rob at cataclysm.cx> wrote on 17-9-2003 0:53:23:
>
>> > Both Jabber's digest auth mechanism and SASLs DIGEST-MD5 (the best
>> > auth mechanisms we have to date) require both the client and the
>> > server to have access to the plaintext password. Thats enough 
>> > reason for me.
>> 
>> Isn't it true that not all SASL mechanisms require plaintext
>> passwords?  This should mean that a capable and properly configured
>> server would not need them.
>
>Actually, it seems the even DIGEST-MD5 might not require a plaintext
>password. See another post I made to this thread about this.
>

That was the conclusion of the last discussion on this subject. I'm 
talking about the "edigist" authentication method dizzy wanted to 
create. After we finally worked out with him a way to make it secure 
(the first method he proposed had some "issues" ;) and stpeter was 
ready to include it in a JEP, I think it was dizzy himself that pointed 
out that SASL's DIGEST-MD5 already did what we tried to do. 

>Personally, I hate iq:register, and would love it to die. At the very
>least, the interactions between it and SASL would be great to know. The
>SASL way to do in-band registration is usually via a password 
>transition - do a PLAIN auth, which gets stored. Then, next time, you 
>do DIGEST-MD5 or whatever - you don't even get offered PLAIN.

Well, in that case, and adaption of iq:register can still over more to 
the paranoid user than SASL. Since the only part that needs to be 
stored on the server is H( { username-value, ":", realm-value, ":", 
passwd } ), if you provide the client with the realm-value before 
registration, the client can calculate that hash and send it to the 
server. That way your password will *never* be exposed to the admin, 
neither will it ever be send over the wire. Music to the ears of the 
more paranoid users you'd think. 

However, let's not forget there is catch to all this. Even if you store 
H( { username-value, ":", realm-value, ":", passwd } ) on the server 
instead of the password itself, if someone has (or get's himself) read 
acces to your registration database, they can steal that H( { username-
value, ":", realm-value, ":", passwd } ) value, and use it to log into 
your account. Ofcourse the same goes if they sniff it of the wire 
during the registration process I described. So still get those read-
permissions right on your jabber-server, and it's still advisable to 
use SSL when you register with a server. 

Still there are some advantages to this method: "they", including that 
smelly admin you never really trusted, won't know your password, so 
they can't use it to break into other accounts (except in the same 
realm). But what kind of paranoid user like that would use the same 
password twice anyway? ;) (or is that what eventually makes a user this 
paranoid? That if you steal his password once you can use it to break 
in everywhere? :P) 

>
>But I'd really like to just do away with in-band registration
>altogether.

That's a bit drastic I think. What's so bad about it?

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands