[Blink] Blink stores plain word passwords in its config file?

Tomasz Muszynski thom at union.waw.pl
Wed Nov 24 17:13:49 CET 2010


Wiadomość napisana przez Dan Pascu w dniu 2010-11-24, o godz. 16:16:
> On 24 Nov 2010, at 14:18, Tomasz Muszynski wrote:
>> Wiadomość napisana przez Dan Pascu w dniu 2010-11-24, o godz. 10:09:
>>> On 24 Nov 2010, at 01:08, Adrian Georgescu wrote:
>>> 
>>>> This is technically possible. Implementing keychain support in the configuration framework
>>> 
>>> actually things are not that simple. sipsimple's configuration framework is platform agnostic, we cannot simply add keychain support there as it is only available on the mac.
>> 
>> switch(platform)
>> {
>> case "OSX": // use keychain
>> case "Linux": // probably use sherlock
> 
> Or probably kwallet. Or should that be gnome-keyring instead? Or maybe all?
> Are you kidding me? Linux is probably the messiest of all considering how many different implementations of a keyring system are out there.

This was only an example :)

> 
>> default: // use plain file
> 
> So Windows (which probably has the most users of all systems) is left out in the cold. Good solution indeed.

I mean, plain file with encrypted password ofcourse.

> 
>> }
>> 
>> Come on! That's not so hard to implement!
> 
> I'm awaiting your patches with interest.

I'm not Python programmer :)

> 
>> 
>>> plus as I said, having keychain support doesn't mean that the password cannot be logged after it was obtained from keychain. blink has a fundamental difference from other applications that come with your mac: it is available with the full source, which makes modifying it trivial. The point is that unless you completely trust anyone that uses your system, you have no guarantees of security.
>> 
>> I disagree. That way, You shouldn't use any tools like KeePass, that's because your filesystem is "very secure" and You don't need any other protection like not using root account or giving your computer to anyone... Also, every software written in Java or .Net (or any other jit based language) would be very unsecure as using reflection you can get source code from it's byte code. Thats not true. And finally, there are hackers that can restore any password from any place... so, let don't protect any software and don't hash any passwords as always someone can crack it :)
> 
> As it was already said here, this is not high on our priority list, but patches are welcome. :)
> 
>> As I've read in specification, SIP uses MD5 passwords. So, why not to store that encrypted password? If user changes authentication method then he will need to reenter the password, but again, it's stored locally in already encrypted form.
> 
> So what? Someone can use the encrypted form as well as the plaintext password once it gets a hold of it. You can use it to build your MD5 challenge responses, what makes you think someone else can't? Who cares if I have the original password or the hashed form as long as I can build correct responses to challenge requests from the server.

Ok, pure MD5 still may be not enough - I was thinking about that after posting my previous email, but was too late :)

Anyway, plain password is bad think. Especially in case of unpatched Windows (which is very common in unaware user), it's quite easy to get "any" file from virused machine.

tm




More information about the Blink mailing list