Re: Filezilla's silent caching of user's credentials

[Jeffrey Walton <noloader () gmail com>]

> If the encryption key stays on the same PC, there is absolutely no security
> in that. Given that this is open source, security through obscurity can't
> even start working (-> encrypting local files with a local key / using
> custom algo == security through obscurity).
Linux [apparently] has not caught on to the fact that applications
could use help in securing secrets. Microsoft has DPAPI and iOS has
KeyChain (one of the bug reports stated about the same). OS assisted
persisted secrets has the added advantage that it is often more
difficult to compromise the OS than it is a user account/session, so
the attack surface should be reduced.

Plus, with the adoption of TPM, an open source OS assisted system
should get stronger. I'm making the leap that the kernel will be able
to offer stronger services using TPM. For example, a simple copy/paste
attack (from an unattended terminal): (1) tied to a user password the
bad guy can mount a dictionary attack. (2) Tied to a TPM, a dictionary
attack is not feasible.

Without help of the Operating System, applications only have a
password based encryption system. Regarding PBC (in the context of
Microsoft's BitLocker):

    "BitLocker has a number of 'Recovery' scenarios that we
    can exploit", and "BitLocker, at its core, is a password
    technology, we simply have to get the password..." [1]

The "recovery scenarios" discussed in the slides don't apply to TPM
based locking.

Finally, Morris and Thompson give a nice history of security and the
Unix password file long before the environment got hostile and went
toxic: Password Security: A Case History [2]. Its a shame that lessons
learned over 30 years ago are being punned (and helps to explain why
password based security could use some help from the OS).

> Fortunately, for the poor souls out there that allow read access to their
> drives, computer forensics haven't caught up yet...
A quick look at 3 [stock] Ubuntu machines and user's home folders:
755. And 755 includes all subfolder - anything created and Documents.
755 seems a bit loose to me (perhaps 755 on public). Its probably not
the only distribution in the Linux community that's doing it. So much
for a "secure machine" when the vendor is shipping the images with an
insecure configuration.

Jeff

[1] Exploration of Windows 7, Advanced Forensics Topic,
http://thibault.rouat.com/security-doc/Windows/WIN7-BITLOCKER-EFS-RMS-Draft-V1.pdf
[2] Password Security: A Case History,
http://wolfram.schneider.org/bsd/7thEdManVol2/password/password.pdf


On Wed, Oct 13, 2010 at 7:57 PM, Christian Sciberras <uuf6429 () gmail com> wrote:
> If the encryption key stays on the same PC, there is absolutely no security
> in that. Given that this is open source, security through obscurity can't
> even start working (-> encrypting local files with a local key / using
> custom algo == security through obscurity).
> I think it ought to stay plaintext and people limit access to this file
> whenever possible.
> It's hardly a trivial matter to delete this file....if an attacker can
> search for and read this file, a user could search for the same file and
> delete it.
> Fortunately, for the poor souls out there that allow read access to their
> drives, computer forensics haven't caught up yet (and probably won't in the
> near future).
> My 2 cents.
> Chris.
>
> [SNIP]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/