[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Jean-Francois Roy]

On May 27, 2006, at 06:57, Michael Niedermayer wrote:

> Hi
>
> First, this is not intended as critique against how things are  
> setup but
> rather as a list of possible issues with svns challenge response auth
> with the intent to 1. confirm i/we understand the issues and 2. can  
> take
> precautions to avoid some possible sideeffects ...
>
> description of the challenge response auth
> 1. server send random salt to client
> 2. client takes random salt + password computes checksum of it and  
> send that
>    to the server
> 3. server takes random salt + password computes checksum of it and  
> compares it
>
>
> 1. passwords are stored in plaintext on the server this means everyone
> who has root or can get his hands on the servers harddisk knows  
> your password
> -> dont reuse any important password

It was my understanding mod_authz allowed one to use any  
authentication method supported by Apache 2. For instance, my  
Subversion repositories are served using Apache 2 / mod_dav_svn /  
mod_authz and my password file uses SHA1 hashing instead of plaintext  
passwords. One could potentially use more sophisticated methods, such  
as Kerberos, LDAP or other authentication systems.

>
> 2. someone who can listen to network traffic can get salt + md5 pairs
>    with which he can perform a offline bruteforce attack (never use  
> weak
>    passwords)

That is always, always good practice. However, referring to my  
comment above, if one uses Apache 2 / mod_dav_svn, one is able to use  
TLS to encrypt the entire communication pipe.

>
> 3. someone who can listen to network traffic and can inject packets
>    can hijack your connection and possibly inject some changes iam not
>    sure how easy this is in practice the problem is the connection  
> will
>    get reset unless the client is kept from participating (by DOS  
> or so)

See my comment above. It seems TLS encryption also solves this  
problem. Of course, one must make absolutely sure that the server  
certificate is the correct, and so forth.

>
> 4. someone who can listen and modify network traffic will trivially
>    be able to do anything he wants after authentication

Also see above, possibly.

>
> -- 
> Michael     GnuPG fingerprint:  
> 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any  
> book
> Today you'd get arrested for mere telling someone where the library is
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://mplayerhq.hu/cgi-bin/mailman/listinfo/ffmpeg-devel

Replying to Attila Kinali concerning:

> But there is one thread that is more serious than any of these
> above and a lot more likely to happen: If someone is able to
> overtake one of the machines of a developer, he can simply
> extract the svn password from the config files. Unlike with
> ssh-keys those files are not encrypted!
> The only way to protect against this case are full reviews
> of commits made to svn.

If you do not trust the security of your machine, you can disable  
credentials caching in your ~/.subversion/config file.

Jean-Francois Roy

--
Co-Founder of MacStorm
/dev/klog. You better pipe that through your mind.

http://www.devklog.net
http://www.macstorm.org
bahamut at macstorm.org

http://www.devklog.net/documents/Jean-Francois_Roy.gpgkey
Fingerprint: 06CD 6F7B 4BF0 2AC6 78B2 57A3 06BE 6CB3 0591 FA2D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060527/7abf3a8a/attachment.pgp>