5 ms·
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), t
by vermilingua 11y ago
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.
- icebraining 11y agoIf 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.
- kuschku 11y agoExcept if you require hash of (password+timestamp modulo 60000)
- joopxiv 11y agoIn that case you can't just store the hash of the password, you will need to password itself.
- kuschku 11y agoHmm. Yeah. I’ve thought about it for the last few hours, and decided that the best solution is to just use RSA in client.
- joopxiv 11y agoHow 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.
- kuschku 11y agoWell, 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.
- kylegordon 11y agoIn addition, Filezilla supports more than just FTP