SplashID crypto fail(bluebottle.net.au)
bluebottle.net.au
SplashID crypto fail
http://www.bluebottle.net.au/blog/2010/splashid-sucks
4 comments
A HUGE sign of incompetence is if a company tries to "hide" the way their algorithms work. If they don't know enough about crypto and security to know that this is pointless, they CERTAINLY don't know enough to write secure software.
FAIL indeed... watch it unfold: http://search.twitter.com/search?q=splashid
On that note, I am sure a lot of you use ssh keys. Do you password protect them? What about keys used for automated server administration tasks? Surely you can't password protect those. (Do you see the init process typing in a password? ;)
I think USER-CENTRIC KEY MANAGEMENT will be a big trend in the coming years. Not just for key management, but for login to any web service.
Imagine a future where all the "social network" does is transfer opaque encrypted packets from one place to another. The User, with his "keychain" (held on his machine) can browse the "social network" from anywhere and decrypt the messages intended for him.
Using current technology it would be quite inefficient: sharing a new photo would mean encrypting a copy for each of my friends thus transferring an order of magnitude more traffic. Perhaps new crypto is needed? Maybe we use AES for the data and send an auxiliary crypto header with 100 copies of the AES key encrypted for each of the 100 friends you wanted to share the picture with.
Research plug: Stefan Brands has invented a very cool upgrade to the basic public-key signature schemes. His protocols allow for "partial disclosure" of only certain parts of a certificate signed by a third party. (unlike the current sertif. schemes in which I have to show you my entire certificate cleartext so you can hash to check the signature)
He has a free book on the theory: http://www.credentica.com/the_mit_pressbook.html
His company Credentica was acquired by Microsoft and I think he is leading the team there to make this idea practical.
On that note, I am sure a lot of you use ssh keys. Do you password protect them? What about keys used for automated server administration tasks? Surely you can't password protect those. (Do you see the init process typing in a password? ;)
I think USER-CENTRIC KEY MANAGEMENT will be a big trend in the coming years. Not just for key management, but for login to any web service.
Imagine a future where all the "social network" does is transfer opaque encrypted packets from one place to another. The User, with his "keychain" (held on his machine) can browse the "social network" from anywhere and decrypt the messages intended for him.
Using current technology it would be quite inefficient: sharing a new photo would mean encrypting a copy for each of my friends thus transferring an order of magnitude more traffic. Perhaps new crypto is needed? Maybe we use AES for the data and send an auxiliary crypto header with 100 copies of the AES key encrypted for each of the 100 friends you wanted to share the picture with.
Research plug: Stefan Brands has invented a very cool upgrade to the basic public-key signature schemes. His protocols allow for "partial disclosure" of only certain parts of a certificate signed by a third party. (unlike the current sertif. schemes in which I have to show you my entire certificate cleartext so you can hash to check the signature)
He has a free book on the theory: http://www.credentica.com/the_mit_pressbook.html
His company Credentica was acquired by Microsoft and I think he is leading the team there to make this idea practical.
You can/should use SSH agent forwarding to handle automated administration stuff.
Use KeePass + DropBox or a network share. That's what my company does. KeePass is really solid software.
http://keepass.info/
http://keepass.info/
Keepass has two levels of access control: "you can access this database" and "you can't". You can use a single database per access group, but once you go beyond two or three groups that's infeasible. You really need a system with a highly granular ACL built-in.
In this sense does anyone know if KeePassX is any good?
I'm interested in password storage but I have both windows and linux machines.
I'm interested in password storage but I have both windows and linux machines.
[deleted]
Works well for me - we then sync our password file between us using Dropbox. It creates a lock file that also syncs and stops multiple people from editing simulaneously and messing things up.
I don't have Windows, but use KeePassX and KeePassDroid to share the password DB between Linux and my Android phone (via Dropbox) and it works great.
I've been using it for the past 2 years on a Linux box, it's rock-solid and format-compatible with KeePass 1.x
For extra safety, go to the database settings and tell it use 2148000000
rounds for the master password.
I've been using 1Password's beta for Windows[1]. Anybody know if it's got any problems like this?
[1] http://agilewebsolutions.com/onepassword/win
[1] http://agilewebsolutions.com/onepassword/win
Been using 1Password across a PC and a couple of Macs myself and I love it.
As per [1] their data format is pretty open and based on the OSX Keychain format. Uses PBKDF2 to generate unique salts/encryption keys per password. Like any password management system, if you lose your master password, you’re still screwed… But (format being open and based on solid standards) it doesn’t appear (to me [2]) to be vulnerable to a similar attack (i.e, an unintentional backdoor password of sorts).
The Windows version must use some implementation of the same backend, since the data file works across platforms (they’re big on the Dropbox sync support).
[1] http://help.agile.ws/1Password3/agile_keychain_design.html
[2] i.e., with my limited experience with information security, knowledge of some best practices for password storage, and my interpretation of the data format
As per [1] their data format is pretty open and based on the OSX Keychain format. Uses PBKDF2 to generate unique salts/encryption keys per password. Like any password management system, if you lose your master password, you’re still screwed… But (format being open and based on solid standards) it doesn’t appear (to me [2]) to be vulnerable to a similar attack (i.e, an unintentional backdoor password of sorts).
The Windows version must use some implementation of the same backend, since the data file works across platforms (they’re big on the Dropbox sync support).
[1] http://help.agile.ws/1Password3/agile_keychain_design.html
[2] i.e., with my limited experience with information security, knowledge of some best practices for password storage, and my interpretation of the data format
egad