[Ffmpeg-devel] SVN challenge response authentication weaknesses
Sat May 27 15:35:56 CEST 2006
On May 27, 2006, at 06:57, Michael Niedermayer wrote:
> 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
> 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
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
> 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:
> In the past you could go to a library and read, borrow or copy any
> Today you'd get arrested for mere telling someone where the library is
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
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.
Co-Founder of MacStorm
/dev/klog. You better pipe that through your mind.
bahamut at macstorm.org
Fingerprint: 06CD 6F7B 4BF0 2AC6 78B2 57A3 06BE 6CB3 0591 FA2D
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
More information about the ffmpeg-devel