[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Filezilla a security risk



On Fri, 29 Jun 2012 18:13:11 +0200, Denis Witt wrote:

> On 29.06.2012 17:13, Camaleón wrote:
> 
>>> The point is that software can't be 100% secure. So when possible it
>>> is a good idea to have more than one security layer.
> 
>> Even if that extra layer is of no help because you leave your computer
>> open and accessible to anyone? Then you're wasting your time and your
>> computer resources, security has to sit between useful and
>> effectiveness, otherwise you're losing the battle.
> 
> FileZilla could use a Master-Password to encrypt the Account-Passwords.
> So if you start FZ you enter the Master-Password (and may define a time
> so that FZ will forgot the Master-PW after some time, when it's still
> open).

Yes, they can as well as they can also encrypt the current user settings 
from the XML file but they don't want to. Period and full stop.

There are another solutions out there you can go with if you don't feel 
confident enough on the Filezilla approach :-)
 
(...)

> What I'm trying to say is that our machines are pretty much very complex
> and it is very easy to overlook things.

It has been always so, Filezilla is not inventing nothing anew.

>> Good thing for a corner case. But the bad thing here is that someone
>> can access your Filezilla settings from you Apache, though.
> 
> Sure. But if there is a bug (or misconfiguration) it might be possible
> to do so. If it was a misconfiguration it is your own fault, of course.

What if... or what if...? 

We can spend the remaining day elucubrating about possible case scenarios 
but we all know about them. This is nothing more than a developer and 
user election.

>> You change the password for your FTP user accounts and that's all. Gee,
>> I wonder in what way users are using their linux systems that don't
>> store any important data on them, only for multimedia playing? :-P
> 
> No, but the really important data is encrypted in a way so even if my
> machine is running all the time the container isn't accessible all the
> time.

Well done but I'm afraid you fit the 1% of the users that do so. I, by 
the way, store thousand of plain text based e-mail messages (mbox) 
containing passwords for many Internet services. If I were paranoid 
enough, I'd only use hard disk encryption but this is still not in my to-
do list.

>> I do check the files I donwload from the web, regardless they are going
>> to be opened from windows or linux, e-mails are also scanned by means
>> of ClamAV and USB keys are not anutomatically mounted thus can be also
>> easily analyzed first.
> 
> That's the scenario I tried to point out above.

And despite all the precautions I take, I have no problems with having a 
password stored in clear text ;-)
 
>> Curiously enough is not only Filezilla who takes the path for not
>> encrypting the user credentials so there has to be a reason in behind
>> for that to happen so often...
> 
> Laziness? Why did last.fm stores the passwords of their users as
> MD5-Hash without salting them?

No, developers are not lazy but practical: they simply don't want to use 
weak methods to handle this.

>> Anyway, aren't most of us still using plain pop3 and smtp connections
>> with no message encryption at all? Who are we blaming? >;-)
> 
> Most of my messages are not encrypted because the receiving end isn't
> capable of that. But my Credentials will only be transmitted when the
> connection is secure (even if the MTA is in the same network).

Again, you must pertain to the 1% of the users that do that ;-)

Anyway, if the recipient does not use a secure protocol to download the 
data (pop3s/imaps), the security chain is broken and thus useless, you 
see now why devels are not lazy? Because you can't just take control of 
all ;-)

>>> SSL/SSH Keys should have a password or should be stored in some kind
>>> of encrypted container.
> 
>> IIRC you have to remove the password so Apache can make use of it so
>> finally the security relies on the file perms (only root can read it).
> 
> This is true for Apache SSL but in fact I don't care a lot about my
> HTTPS keyfiles, if they got compromised I revoke them. And if you really
> want to fake a certificate you might can have this easier through
> companies like DigiNotar.
> 
> SSL is pretty much snakeoil nowadays, but it's better than nothing.

That's the kind of reasoning software developers do: "if there's no 100% 
secure system, why should *I* bother"?

>>> An encrypted container wouldn't help a lot here, because I assume your
>>> MUA is running most of the day, right? So the container has to be open
>> all the time and any malware could read
>>> the file.
> 
>> In my case it is launched on demand. My main MUA is Thunderbird.
> 
> Do you use a Master-Password? 

Nope. How annoying...

> If so, then guess what? All your passwords stored in TB are saved
> encrypted. Nice feature, isn't it? ;)

I really don't care. If I were in a windows machine, I'd be a bit 
worried ;-)

>> There's still dangerous USB flash drives and the always evil CD/DVD and
>> floppy disks... you never know.
> 
> Of course you have to get rid of those drives as well. Also your USB,
> Firewire and Thunderbolt ports. eSATA? Well, that's evil. Are there any
> known typewriter security holes? ;)

And don't forget the BIOS!

Okay... I better return back to my cave, dust my typewritting machine and 
problem solved.

> I know at least two companies where no machine has optical/floppy drives
> and USB ports. Also you can't send them E-Mails with ZIP-Files, etc.
> attached. It's a f*cking nightmare and I really don't know how they can
> work like this.

When you work in a corporate environment, disabling the external devices 
is a must. The biggest hole in a computer system is always the user. 
Always.

> Anyway I think we're going pretty much offtopic. My point is that it
> would be a nice feature for FZ (and other tools) to store passwords more
> secure. And I don't like the attitude of the developers saying that it's
> not their problem if someone could read the file who isn't allowed to.
> At least as such a feature is rather easy to implement and won't affect
> the user experience in a bad way.

Nah, developers are made of different stuff and they rarely listen to 
their users... and hey, it's open source! You can hire a programmer, make 
a fork ("FileZilla-S" for secure) and add all the enhancements you want ;-
P

Greetings,

-- 
Camaleón


Reply to: