lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 14 Oct 2010 09:32:10 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: Ryan Sears <rdsears@....edu>
Cc: full-disclosure@...ts.grok.org.uk, Mutiny <mutiny@...inbeardsucks.com>
Subject: Re: Filezilla's silent caching of user's
	credentials

My point is, if you are granting access to this password file to everyone,
the security hassles you're going through are all useless.
I mean, ok, you might prevent script kiddies (or lazy hackers) from getting
to the passwords, but discrimination is not the point of security is it?

With regards to the handcuffs example, yes let's. They're no use if the
criminal with the handcuff is situated in the red district and won't budge
out of there.
I think it's the context that makes this work. Users/admins should be
limiting access to the passwords file in the first place.

So far the security flaws we've seen (with this bad practice of using
plaintext) is people happily handing out passwords.
OK, encrypting the file would have prevented this mess - somewhat.
Better still, they shouldn't be handing out the file in the first place.

@Chris/silky - I didn't ask for your comments - maybe you didn't realize,
yours are just as useless.
No not in the theoretical context you keep coming up with, they *are* really
useless.
I mean, arguments like "you are shit, without doubts", really won't get you
anywhere.

@Ryan - I don't need to take to anyone's defence. As you correctly said, any
security precaution might not work when put through certain conditions.
Maybe it's just my opinion, I don't know. But the problem I see is people
shouldn't be assuming something is safe and hand it out.
Sharing a whole hard drive with the web doesn't sound like a smart idea to
me.


Cheers,
Chris.




On Thu, Oct 14, 2010 at 9:16 AM, Ryan Sears <rdsears@....edu> wrote:

> Yeah I definitely have to go with silky on this one.
>
> Maybe if you elaborate on your point? I'm not sure I entirely grasp what
> you're trying to say, because if I am, then you share relatively the same
> view as the dev that's causing this problem. You can argue that any security
> measure "doesn't *work*" as you so put it, given the right circumstances.
>
> Take handcuffs for example, what good would they be if when you put them
> on, you could never get them off again? Sure they would "work", but there's
> no mechanism to UNsecure them, which is where vulnerabilities in security
> systems inherently exist. The handcuff design is flawed on a fundamental
> level as they can be easily shimmed by manipulating the way they lock into
> place. That's when the double-lock came into play, which is a very, very
> simple example of layered security. While the handcuffs are double-locked
> the teeth can't progress in any direction, because it locks that mechanism
> into place. This is undone by turning the key in the opposite direction to
> release the 'double-lock' then back forward to release the teeth. Call that
> two-factor authentication. That's all fair and well, but there are STILL
> ways to manipulate them to get out. What happens if you have a key (which is
> pretty much universal)? It's even been demonstrated that most handcuffs can
> be picked with a simple bobby pin. Are handcuffs pointless though? No.
> They've been demonstrated time and time again to be 'good enough'.
>
> My point is, the KISS principal doesn't really hold true here. Encryption
> schemes are MEANT to be complex in nature (at least one-way), because that's
> the only way to make sure that something is properly secured. Botg DID have
> encryption at some point, but he did away with it after people found it was
> easily reversed. (http://seclists.org/fulldisclosure/2005/Sep/50)
>
> The idea that just because an encryption scheme may be reversed at some
> point it shouldn't be used is *absolutely* terrible practice.  Shadow
> passwords are a great example, while they have the ability to be cracked,
> they're still a de facto standard for authentication in *any* unix
> environment. There's a reason for this. That's why people created the
> crypt() function, and that's why the windows API has stuff to do this
> natively as well.
>
> As for change proposals, I did the digging, and found that 90% of all this
> crap would be avoided with a single 0->1 change in the source code. If
> 'kiosk-mode' was enabled by default, you could at least have the OPTION to
> use piss-poor practices to store your passwords if you so choose. (
> http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932&start=15)
>
> I've made my final plea to botg on this issue, and if he's not going to
> budge I'll be forced to take measures into my own hands and change the damn
> source myself.
>
> Thankfully the rest of the world doesn't share your (& botg's) opinions,
> because if they did, hacking wouldn't be any fun.
>
> Ryan
>
> ----- Original Message -----
> From: "silky" <michaelslists@...il.com>
> To: "Christian Sciberras" <uuf6429@...il.com>
> Cc: full-disclosure@...ts.grok.org.uk, "Mutiny" <
> mutiny@...inbeardsucks.com>
> Sent: Thursday, October 14, 2010 2:46:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [Full-disclosure] Filezilla's silent caching of user's
> credentials
>
> On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras <uuf6429@...il.com>
> wrote:
> > > Not all attackers are created
> > > equally.
> >
> > I still see this a simple matter of violating KISS to introduce a layer
> of encryption.
> > The question is, to which end? Sure, an attacker might see the encrypted
> > file and think it's "too difficult" for him to get to the passwords.
> Another
> > might use a certain utility to decrypt the said file. The thing is, to
> which end are
> > we encrypting the data? Just for the sake of making it work like the N
> other programs?
> > I mean, if this doesn't *work*, why even *bother*?
>
> Sorry, but your comments are totally useless here and can't even
> really be addressed properly, given their quite ridiculous nature. You
> are missing the point of the encryption, and it is not my job to
> convince you, and any further comments with anyone other than the
> developer are useless.
>
>
> > > There is no question here. There is no discussion. It should be done,
> > > and if it is not, password saving should be stopped in FileZilla or an
> > > alternative program should be sought. It's that simple.
> >
> > Great. If it's so simple that it can be done in under 10 mins, go
> complain
> > to them.
>
> This email thread *is* a direct complaint to them, after bugs have
> been closed for years. I didn't start this thread. Do you even
> understand what is going on here? Your emails suggest you do not.
>
>
> > Cheers,
> > Chris.
>
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ