Hacker News new | comments | ask | show | jobs | submit login

As far as the password storage goes, you are not up-to-date. They are stored base64-encoded now.

Yes, much better.

FTP passwords can't be hashed. The right solution would be to support platform keyrings but ... https://trac.filezilla-project.org/ticket/1373

Someone explained that after he got some malware on his computer and subsequently all his websites were hacked. The response?

Once you've got malware on your computer, you've lost already, game over. You need to prevent the infection in the first place.


That's correct though. Even if the passwords weren't stored at all, malware could just install a keylogger and record them when you typed them in.

The fact that there are ways to obtain passwords even when they are not stored unencrypted is not really a reason to make it as easy as possible for malware to get every password on your system.

No, you're wrong. If you've run malware on your machine then it's not your machine anymore.

This is exactly the thing that Google spent months trying to tell people when it was refusing to include password access to the password list. That extra password does nothing to increase security, and may be counter productive.

Encrypting stored passwords gives users a misleading false sense of security.

> botg: All third-party offers can easily be declined. Nothing unwanted is being installed without your consent.

Talk like that can only mean that they know about the malware bundling.

Extremely interesting in combination with that quote of yours. Essentially: "the malware we install on your machine will get access to your passwords anyway."

Looks like Filezilla will not die a hero's death.

Why can the passwords not be hashed?

FTP is inherently insecure, everything is transmitted in plaintext. Because the server cannot check a password against a hash (due to the limitations of FTP), the client needs to store the password, and can't keep only a hash.

That being said, Base64 is woefully inadequate, just google 'base64 decode'; and this response (from someone who appears to be a contributor) is just not a defence.

If the server checked against a client-provided hash, the hash would become the password, and the attacker could just use the hash as-is to login to the server. Hashing on the client solves nothing.

Except if you require hash of (password+timestamp modulo 60000)

In that case you can't just store the hash of the password, you will need to password itself.

Hmm. Yeah.

I’ve thought about it for the last few hours, and decided that the best solution is to just use RSA in client.

How would that work? If you would use a private key to authenticate to the server you would still need to protect this key with a password. Otherwise stealing the private key will get an attacker access to the server just as simple.

Well, you’d be 100% safe of MitM.

And you could use a hardware key auth.

Like the German eID, where the key is signed by the government and on a special chipcard.

The software requests the card to sign, you need to type in your PIN on the reader itself, and the request will be signed with RSA.

The public key is world-readable on the card, so you can just send that to the server.

In addition, Filezilla supports more than just FTP

The client needs them in plain text to be able to connect. "Remember password" is a feature, there. Like I said, correct solution is to use the keyring, but the dev team is incompetent, so ...

Or a master password if using the keyring is too complicated for them.

Oh, I thought we were talking about the server. Never mind, thanks.

The application needs the original password so that it can pass it on to the FTP server.

I'm confused...who said they could be hashed?

That's nowhere near sufficient for 2015. rot13 at the very least.

Was about to post the same thing. If this crap is posted by a contributer I'm moving away from it as fast as possible.

It is.

Would a "master password" (a la Firefox/Thunderbird) be the way to go (as input to an encryption routine)?

It seems like any credentials that can be automatically used after a program loads without the user authenticating are at risk for malware harvesting.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact