The Doghouse: Passwordsafe.com

This isn’t my Password Safe. This is PasswordSafe.com. Password Safe is an open-source application that lives on your computer and encrypts your passwords. PasswordSafe.com lets you store your passwords on their server. They promise not to look at them.

Can I trust PasswordSafe?

As we mentioned, pretty much every function is automated, no-one here ever sees your information as it’s all taken care of by the programs and encrypted into the database. Again we’ll remind you, we do not recommend you store sensitive information at PasswordSafe. In house, we’ve used this service for many sites, banner programs, affiliate programs, free email services and much more.

Tags: , , ,

Posted on May 5, 2008 at 6:37 AM • 70 Comments

Comments

Paul Renault • May 5, 2008 6:55 AM

non-SSL “member” login? Yup, they’ve really spent a lot of time figuring out all the security angles…

Sigh.

Nicola • May 5, 2008 7:18 AM

I have a little suggestion.

Instead of passwordsafe.com use clipperz.com.
It has been created by two italians, it stores passwords and personal informations on its servers, but… all the framework is opensource, downloadable and test-proof. For Schneier: It uses also fortuna…
I hope Schneier could take a little time to review (or, at least, to give an outlook at) that service…

Guillaume • May 5, 2008 7:23 AM

At least, the login form accepts complex passwords, say like 1′ or ‘1’=’1

Matthias • May 5, 2008 7:29 AM

No exception, I’m afraid, unencrypted storage of sensitive data is today’s standard. Unencrypted, BTW, means not encrypted by the user. Some services, provider, etc. claim to encrypt the data themselves, but who knows. That’s one of the reasons why I don’t use DropBox but JungleDisk for the storage of my data in the cloud. And thanks to GnuPG, I can quite reliably encrypt my own data. It’s such a pity that PGP on the Mac just sucks! 🙁

Guillaume • May 5, 2008 7:36 AM

@Nicola
The trouble with those services isn’t the technology they are using. You have to be willing to give your passwords away to an entity you have no control over.

Clipperz talks about trust, and zero-knowledge and reviewing the source code. But I do I know that code is really used internally ? Will I have to take a hash of the client side javascript every time to make sure it is the version I reviewed ? Then start all over again at each revision ?

I think initiatives like OpenID will have more chances solving that problem one day.

Like the song says “It’s a matter of trust” !

Charles • May 5, 2008 7:37 AM

Ah, and it tells you whether the username you enter exists.

Clearly this is a company that takes security very seriously.

D0R • May 5, 2008 7:38 AM

My Ghod. If you really think that storing your passwords on a third-party server is a good idea, please contact me asap. I have the Eiffel Tower to sell you.

D0R • May 5, 2008 7:44 AM

Spotted in their Resources section:
“E-mail Worms 2004. Keep up with the latest worms and viruses here…”

🙂

Ed T. • May 5, 2008 7:49 AM

“The URL the form POSTs to is secure.”

However, if the URL that displays the form isn’t, then with a little DNS cache poisoning (or even just a bit of good old-fashioned social engineering), you could create the ULTIMATE PHISHING EXPERIENCE.

~EdT.

Brian • May 5, 2008 8:23 AM

Esp. depending on the use, wouldn’t a password be considered “sensitive information”? From that viewpoint, that looks like a self-defeating FAQ to me.

brett • May 5, 2008 9:06 AM

Notice the “The UserName is incorrect” and “The Password is incorrect” error messages.

Bunch of rookies.

Jim • May 5, 2008 9:23 AM

Bruce,

What a clever way to combine to recent blog entries!
Why just week you showed us some clever MySql injection attacks and now we have a site that we can try them out on! It seems the “Join Now” page on PasswordSafe.com uses Mysql to store this info. This is easy to see if you insert quoted mysql code in the ‘username’ field.

Cheers!
Jim

D0R • May 5, 2008 9:33 AM

The Seamonkey suite has a built-in Password Manager, too. It’s a very nice feature.

sooth_sayer • May 5, 2008 10:04 AM

I think you are too quick to send this to the doghouse for the reasons given.

Unless you one of the two:
1. A real security hole
2. A bad set of policies

you shouldn’t be condemning these guys.

The problem I see with this site is a set of data collection policies and not the basic paradigm.

FP • May 5, 2008 10:11 AM

For a free analysis of your passwords, just post them here. Please include the site URL, your user name and other relevant log-in information, so that we can objectively judge the strength of the password vs. the importance of the site (finance, personal blog, third-party comments).

moo • May 5, 2008 10:13 AM

@sooth_sayer:
You don’t see a problem with sending your password to a third-party server, from a non-secure POST on a site with MySql injection and XSS vulnerabilities? Maybe you can send it to me too, I have some vi@gra I want to sell you?

Free Market • May 5, 2008 10:36 AM

Time to goggle up the remaining free passwordsafe domain names! At this writing, at least a dozen have been taken.

D0R • May 5, 2008 10:44 AM

@ehmo:
I believe you are missing the point. Would you think it’s acceptable to tell all your logins/passwords (and hence give access to all your sensitive data) to these guys, just to avoid the burden of remembering it? If yes, you can send your passwords to me. I promise I won’t read your emails.

Pat Cahalan • May 5, 2008 10:48 AM

@ sooth_sayer

The problem I see with this site is a set of data collection policies and
not the basic paradigm.

Er, what difference does it make what tools you use if your policies stink on ice?

D0R • May 5, 2008 11:00 AM

If I were a phisher that’s exactly what I would do. I wouldn’t lose time crafting a single phishing web site. Instead, I’d set up a service like this one and happily harvest users’ logins/passwords for email, banking, PayPal, eBay, and other e-shop accounts.

Note that I do not accuse Passwordsafe.com to be fraudulent. Just pointing out that it’s too risky to have all one’s eggs in a single basket.

Grayputer • May 5, 2008 11:12 AM

(sigh) Even my non-tech brother can use a USB stick with TrueCrypt and keepass.

step 1 – format USB stick
step 2 – add TrueCrypt for all OSes you use
step 3 – create truecrypt container
step 4 – install keepass(s) to container using different password
step 5 – Remember to put USB stick in pocket

(sigh)
But I guess as usual the ‘ease of use’ ploy will club the ‘better security’ policy like a baby seal. And as usual there is always someone about to exploit/profit from that.

(poster goes back to pounding head on wall)

Jason Lefkowitz • May 5, 2008 11:21 AM

This site would make an awesome IQ test.

If you read all the copy and are still convinced that you should share your passwords with them, you fail 😀

Alfred • May 5, 2008 11:38 AM

Password Safe vs. PasswordSafe.com?

Sounds like Bruce would have a pretty strong trademark infringement suit. After all, that’s just what trademark law is for, to protect the reputation of good products and services against poor-quality imitators. Not all trademark suits are evil.

D0R • May 5, 2008 12:03 PM

@Andres:
Apparently with Clickpass.com you can store credentials for a limited (albeit large) set of websites.
But still, again, it’s the same problem. Someone gets your Clickpass password, or manages to gets the unencrypted database, and you’re in deep shit.

Mark • May 5, 2008 1:30 PM

@Matthias
Unencrypted, BTW, means not encrypted by the user. Some services, provider, etc. claim to encrypt the data themselves, but who knows.

They could use rot-13 (or another Ceaser Cypher varient) and be technically correct about encrypting the data. Thing is that cryptography from Roman times tends to be useless in the 21st century.

Even if they did use some cryptography which can be proven secure there are all sorts of issues about key managment and who can gain access to the keys. If the keys arn’t actually secure the cryptography can easily be irrelevent.

Another obvious issue is that the contact address of the company is in the US. Which has no data protection laws (outside of records relating to video rentals). Thus they can give you data to anyone they like whenever they like…

Nomen Publicus • May 5, 2008 1:31 PM

Er, if you are creating a service like this, why isn’t every page using https? If you’ve bought a certificate, why just use it on one page?

We are designing a new web farm facility and if I get my way (and I’m the primary designer) every hosted web service will have the option of using https using a CA which will be a part of the service.

Josh Turner • May 5, 2008 1:31 PM

I really don’t recommend anyone storing passwords in this manner. Problem is, now-days we have so many security holes and vulnerabilities we are welcoming anyone to come in and steal our password information. I would like to see more comparisons listed. What are the legal ramifications of the same name?

Ted • May 5, 2008 2:51 PM

@ D0R
“I have the Eiffel Tower to sell you.”

No you don’t. I bought it last week, and I have the sales receipt (in French) to prove it.

anonymoose • May 5, 2008 5:53 PM

according to their page, they are owned by SingleStep Publishing, but if you google that company, they dont really appear to exist…

Bubba • May 5, 2008 8:26 PM

I wouldn’t leave any password I cared about on a computer, whether or not its encrypted, in my head or nowhere at all!

Why is marijuana still illegal in the land of the free?

D0R • May 6, 2008 1:33 AM

Well, KYPS is interesting in the way it uses one-time passwords and proxies, so you can safely login to your accounts even from compromised terminals. But, again, it’s still the same problem.

Those who have used this kind of service are requested to write 100 times on the chalkboard:
I WILL NOT STORE MY PASSWORD ON A THIRD-PARTY SERVER
I WILL NOT STORE MY PASSWORD ON A THIRD-PARTY SERVER
I WILL NOT STORE MY PASSWORD ON A THIRD-PARTY SERVER
I WILL NOT STORE MY PASSWORD ON A THIRD-PARTY SERVER
I WILL NOT STORE MY PASSWORD ON A THIRD-PARTY SERVER

Nostromo • May 6, 2008 4:38 AM

And get into the doghouse yourself, Bruce, for releasing your own “Password Safe” as a Microsoft-only program.

Jens • May 6, 2008 4:43 AM

Btw, I’m still looking for a password safe version for my S60v3 based phone (j2me would be fine, too). I can’t believe there’s no way to read pwsafe files on my phone.

Also, password gorilla has compatibility issues with the official java password safe, despite claiming it should be compatible. Any other way to get truly cross-platform, open source storage for my passwords, cc numbers, etc. (at least OSX, Linux, S60/j2me)?

SteveJ • May 6, 2008 4:55 AM

I assume that’s a joke, but just in case…

At a brief glance, Spynote doesn’t look very useful to me. It appears to encrypt using javascript on the client, which is a good start. But the javascript is delivered over http. To be secure you would have to first verify or trust that the code is good, and then manually verify each time you use it that you really have downloaded the correct javascript.

Otherwise some web proxy or other mitm could serve you a modified javascript which encrypts using an attacker’s key instead of the one you enter, and the attacker could decrypt your message at his leisure. This is unlikely (not impossible) on your home or office network, but if you ever use public Wifi you should care a lot about end-to-end encryption.

You cannot rely for security on code delivered over an insecure channel and then not somehow verified.

Spynote says it is “open source”, suggesting that you might verify the code yourself for correctness rather than trusting Spynote to get it right. But even if you did that, and even if it were delivered over SSL, you’d still have to trust the Spynote server to send you the same script every time. That’s a big assumption compared with doing the sensible thing, which is to store your cryptography software on your own machine.

So, Spynote is only useful if you trust:
1) Their programmers to get the code right (this isn’t a big one, since the code is available for public review).
2) Their server to always deliver the same code (I’d say this requires a similar level of trust to storing your secrets unencrypted on a third party’s server and trusting them not to read them).
3) The intermediate network not to modify traffic from their server to you (oops).

007 • May 6, 2008 5:13 AM

@SteveJ:
Take a closer look at Spynote and you’ll understand were you’ve miss the point and went to wrong conclusions.

Scripts modification is pointless. If anything changes scripts in-the-middle then user would not be able even to access his data to divulge it to the attacker in a first place. The user would immediately notice the attack.

This is only one missed point; there are few more. A premature judgement is as bad as a premature ejaculation.

D0R • May 6, 2008 5:31 AM

@007:
Spynote.com = Blowpass.com = Passpack.com = Clipperz.com = PasswordSafe.com
You give your passwords to them. Bad Thing.

Paeniteo • May 6, 2008 5:47 AM

@007: “Scripts modification is pointless. If anything changes scripts in-the-middle then user would not be able even to access his data to divulge it to the attacker in a first place. The user would immediately notice the attack.”

Script modification could easily work in a way that whatever the user types is transmitted to a third server in addition to whatever is sent to spynote’s machine (encrypted or not).
(Almost) no way to notice and to defend against.

“A premature judgement is as bad as a premature ejaculation.”

The worst thing is to ignore the basic, well-known and evaulated safety precautions (or to think that one can do better than established practice).

Jeremy Duffy • May 6, 2008 6:09 AM

Not a chance. It would be better to use TrueCrypt and have them on your hard drive. Once passwordsafe.com has enough passwords and becomes a tempting enough target, bribe a worker to modify the code to store the passwords in the clear.

Or just dump the password logs to a file and apply a patient algorithm to break them. Chances are, people are feeling so safe about the passwords there that they won’t change them so it won’t matter how long it takes to crack them. Especially since people are still likely to choose dictionary based passwords.

SteveJ • May 6, 2008 9:13 AM

@007:

Classic mitm is when each end thinks it’s talking to the other end, when in fact they are both talking to a machine in between the two. Conveniently for attackers, that’s pretty much how TCP/IP works – zero or more untrusted agents exist between the endpoints, but the sockets API abstracts them away. That’s why SSL is needed, as it provides end-to-end encryption and (together with PKI) identification.

So, a full mitm attack on Spynote would be to supply the user with a script which communicates with EvilServer instead of Spynote’s server: EvilSever is sitting on the network between the user and Spynote. Perhaps it’s a router somewhere (if you’re running a public Wifi point it’s especially easy to get into this position), in which case the user’s browser will ‘think’ it is Spynote’s server.

User types their credentials into something that looks like Spynote. Script sends them to EvilServer, which uses the credentials to access and decrypt their secret data from Spynote and supply it back to the modified script. User changes the note, script sends it unencrypted to EvilServer. EvilServer uses the supplied credentials to update Spynote. Pretty much undetectable unless you check the javascript your client is running.

You’re correct that the attack I was thinking of originally isn’t quite this sophisticated. I imagined someone creating a new note, after an attacker supplied them with a modified script that caused them to create the note such that only the attacker will be able to read it back later.

A subtle change to the AES javascript would suffice to encrypt using a different key from the one the user supplies (or encrypt using something other than AES – perhaps no encryption at all), so you really do have to look very carefully at the script you’ve downloaded. Decryption need not necessarily be affected, so the user can still get their data from Spynote.

But with more blatant script changes (or more clever obfuscation) a modified script working on behalf of an attacker can do anything javascript can do.

If I have missed something (I didn’t read the whole scripts) then please explain the counter-measures which Spynote uses to prevent all the above attacks.

I’m sure Spynote is fine as a toy for non-critical data, and it certainly has a certain amount of security through obscurity – I suspect nobody currently plans to attack it. But that’s more caveats then you generally want from a security product.

joe • May 6, 2008 9:20 AM

Re: PasswordSafe.com

Can someone please explain why anyone would use an online server/service to store there psswds? I just don’t get it? What is the benefit of this over using an encrytped psswd repository on your harddrive?

johndoe • May 6, 2008 9:27 AM

maybe its OK for having a helping hand when traveling and having to use an untrustworthy computer – then one cannot count on being able to (safely) execute one’s own software on the computer….

joe • May 6, 2008 9:37 AM

hmm…I get the sales pitch, but can’t see any valid reason for using a non-trustworthy system to access sensitive info. At least can’t see the frequency to justify the risk anyway:)

Ilya • May 6, 2008 10:19 AM

Must say, I’m surprised to see Spynote popped up here. Well, let me comment a bit because of my involvement in that project.

Spynote is a niche product. It has never been positioned or seen as a universal and ultimate unbreakable silver bullet. Spynote does have few limitations and tradeoffs which the authors are perfectly aware about. Regardless of how stupid it may look to you at the first glance, every aspect in Spynote’s design has a rationale behind it. Everything there the way it is because it was found the best option to provide balance between goals, risks and demands.

Take for example an https issue (since it was brought by the commenters already). One may think it is a full ignorance and plain stupidity of not using it until he realizes that:
* there are demands to access Spynote from a harsh network environment were only an http port is available
* there are demands to be able to access Spynote thru various public proxy servers to prevent anyone at the server to find out user whereabouts by IP address
* https does not solve the problem of trusting the operational staff at Spynote
Basically it is much simple and effective to avoid https as long as there are some other means to prevent ITM attacks. Paid users may easily verify the integrity of scripts by using the provided tools. Ugh, anyone may actually. It is not a rocket surgery – there are plenty of available utilities to notify you about changes on a Web site.

I believe it would be impolite to Bruce for me to go for a long essay here thus I’ll put the rest of stuff offline. If anyone interested in those then please contact me, I’ll be happy to elaborate.

bob • May 6, 2008 10:27 AM

I would prefer a PDA with strong encryption (NSA approved for use on gov systems would be great) and a really gnarly password, maybe salted with a biometric, that then could hold all my account names and pws independent of any network.

SteveJ • May 6, 2008 1:13 PM

@Ilya: “there are plenty of available utilities to notify you about changes on a Web site”

OK, but the Spynote website doesn’t state the limitation (at least, I don’t see anything in the FAQ). So Spynote isn’t suitable for users who wouldn’t figure it out for themselves. The “About Spynote” section says why you can trust the app, but it doesn’t say under what circumstances you can’t trust it.

Btw, in my analysis I didn’t mean to imply that Spynote’s design is “stupid”, just that I don’t see it as useful for securely storing data online. If it’s intended for some very specific purpose, not for general storage of data, then my analysis might not be applicable.

In practice it’s no easier to validate that the Spynote code is unchanged than it is to keep a copy of a “known safe” version of the same (or similar) javascript. If I’m going to carry around a utility to check that the scripts haven’t changed (or securely access it in a way which ensures code integrity), I could just as easily simplify things by carrying around (or securely accessing) the crypto scripts themselves.

Kenny • May 6, 2008 4:30 PM

Bruce. Almost every article of yours that I have read has been intelligent and often insightful, whereas your blog posts are becoming more of the “this sucks” flavor every time I stop by. Instead of passing judgement on all around you, how about doing what you do best, provide analysis and suggest solutions when presented by a problem or poor implementation. Just think, there are people out there that would value your input.

To all of you that posted solutions, alternatives and positive thoughts, thank you. To those negative posters, the dark side of the force does no one any good, post questions and suggest solutions, even if you don’t fully understand the problem.

SteveJ • May 6, 2008 4:58 PM

@Jonesy:

How do Yodlee’s finance apps actually work? I can’t find a demo.

I don’t know about you, but my bank, pension provider, and share proxy account all say that I must not divulge my credentials except at the relevant site – I can’t reveal them directly to the employees of the company in question, let alone to a third party, even if that third party would normally be considered trustworthy with data of that value.

I’m pretty sure they’d take a dim view if I stored those credentials on a third-party server somewhere, no matter how secure it is, simply because they (or their subcontractors) can’t control or audit what happens to the data.

As against that, the site mentions working with Vodafone. If Yodlee has an incarnation as a piece of software which sits on my mobile phone (or any device for that matter) and uses my credentials to access the information I ask for, then in that sense it’s comparable to my browser or my OS. So if Yodlee are working together with (say) the mobile phone manufacturer or operator, and if I would be prepared to use the phone’s built-in browser for banking, then why not use Yodlee for banking?

Personally, if I felt that I had the problem Yodlee is trying to solve (which I don’t), then I would probably contact customer support for each of the sites I was thinking of accessing with it, and ask them whether they authorise use of Yodlee. If they say no, then don’t use it: it’s then Yodlee’s problem to convince them otherwise, not yours.

Summary: when you can’t judge someone’s trustworthiness yourself, leave the decision to somebody who (a) you’re forced to trust anyway, (b) has their own security decisions regulated and audited, and (c) is liable for losses through procedures they approve 😉

JardaP • May 7, 2008 12:30 AM

BTW, is there some Password Safe for Linux? Preferably compatible with Password Safe for Windows to easily copy the database file.

bart • May 7, 2008 6:12 AM

@JardaP:
“BTW, is there some Password Safe for Linux? Preferably compatible with Password Safe for Windows to easily copy the database file.”

Yes. I don’t know about compatibility, I don’t use Windows nor do I use a Password Safe program:

$apt-cache search passwordsafe
mypasswordsafe – Easy-to-use password manager
pwsafe – command line encrypted password database manager
…………………………………
$apt-cache show mypasswordsafe

Description: Easy-to-use password manager
MyPasswordSafe is a straight-forward, easy-to-use password manager that
maintains compatibility with Password Safe files. MyPasswordSafe has the
following features:
.
– Safes are encrypted when they are stored to disk.
– Passwords never have to be seen, because they are copied to the clipboard.
– Random passwords can be generated.
– Window size, position, and column widths are remembered.
– Passwords remain encrypted until they need to be decrypted at the dialog
and file levels.
– A safe can be made active so it will always be opened when MyPasswordSafe
starts.
– Supports Unicode in the safes.
– Languages supported: English and French.
.
Homepage: http://www.semanticgap.com/myps/
…………………………………………
$apt-cache show pwsafe

Description: command line encrypted password database manager
pwsafe is a unix commandline program that manages encrypted password
databases.
.
Features:
– Pure command-line operation if desired (good for remote access over ssh)
– or can interact with X11 selection & clipboard.
– Portable, endianess-clean, misaligned-access-free C++.
– Compatible with CounterPane’s PasswordSafe Win32 program versions 2.x
and 1.x. See http://passwordsafe.sourceforge.net/
………………………………………….
This was just a search for passwordsafe, see also TrueCrypt.org and other solutions in containing any cached passwords, encrypted or not, you should store them in a container.
…………………………..

Thomas Pollet • May 7, 2008 9:30 AM

Kenny,

when you provide security services, you better make sure you have everything right, hackers look for the weak link. If you want to store ALL user passwords UNENCRYPTED in your database, you don’t want to be cracked.

From your site:

We noticed a number of “paswordsafe hacks” have shown up on the net recently, all claiming to have breached the security of the site. While one did on fact get a popup to happen, none of these attacks are anything more than an annoyance. On the flip side it has been a great opportunity to catch and block a good number of hackers and “bad netorks” so all in all, it’s been a good thing

pffffft, you simply don’t get it.
I suggest you go design a useful site about gardening or something.

melic • May 9, 2008 2:21 PM

This is the message I just got visiting passwordsafe.com:

An appropriate representation of the requested resource / could not be found on this server.

I guess their webserver needs checking out too.

Bob • May 9, 2008 5:47 PM

Kenny your “hack attempt detection” has turned a mere XSS attack into a very obvious invitation for an SQL injection attack: Database error: Invalid SQL: INSERT INTO hackattempt SET remote_ip =’xxx.xxx.xxx.xxx’, fulluri = ‘/join/?UFirstName=Click%20me…

Dave • May 16, 2008 4:28 AM

Isn’t PasswordSafe just a somewhat more primitive version of what OpenID does? Both train users to hand out their credentials for processing and storage by arbitrary third parties, yet for some reason OpenID is cool while PasswordSafe is bad.

how to prevent premature ejaculation • February 28, 2014 2:12 AM

It is the ideal time to produce a very few strategies to the long term and it’s a chance to feel special. I’ve discover this upload of course, if I might simply I wish to would suggest an individual a number of exciting issues as well as suggestions. You could possibly could possibly publish following content articles about it write-up. I need to find out even more troubles about this!

Karen • March 18, 2017 8:28 AM

Hi there. I used passwordsafe.com for all my logons for most of the last decade. I just went there to change one of them and it’s not the same site!!

You wouldn’t happen to know what happen with them? Geez, I had all my access information on there. I sort of encrypted them by using clues instead of the actual passwords, so i feel that if it was hijacked, then I’m okay. But darn it I don’t know what some of those passwords are that I really need. I was hoping you could give me some insight. I’m not comfortable giving any information to the current site. Thanks!

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.