Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Frackin script kiddies!!



On Wed, Aug 4, 2010 at 9:31 PM, Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>> Yes, I still contend that you've left a lot of my questions without
>> any satisfactory answer. So no, I'm not convinced. Regardless, I've
>> actually enjoyed the discussion, and I apologize for wasting your
>> time. :)
>
> Let's start with the simple one: what does SSL do. ?SSL protects the communications between browser and server. ?It keeps eavesdroppers off your back. ?That's all it does. ?In practice, it makes it very expensive for an attacker to sniff your login credentials. ?It does not prevent an attacker from launching an attack against a server in an attempt to guess those credentials.

Yep. Same as my bank's web site.

> In contrast, an authenticated communication link such as used by SSH PK auth denies direct attack against the server. ?As someone else noted, an attacker would have to attack both the key and the credentials. ?The attacks would need to be simultaneous because it is not obvious from the outside if one or the other is correct. ?They all need to be correct for positive authentication else the link is never established.

My bank doesn't provide me any ssh pk auth. Does yours?

> This is where X.509 certificate authentication comes into play. ?Certificates provide the same kind of PK authentication between client and server as SSH keys. ?You have to have one half of a key pair generated for you installed in your browser or you can't even talk to the server. ?As with SSH PK auth, an attacker needs to attack both the certificate and the credentials in order to even establish a link.

My bank also hasn't issued me an X.509 certificate, nor can I see
anywhere that they offer it. Just plain old SSL, with a username and
password login option. Which is essentially the same thing my mythweb
setup uses.

> Back to the financials. ?Big traders don't use SSL. ?They have dedicated lines connecting them directly to their trading systems. ?Attackers can't get in from the outside. ?They would have to attack the physical lines directly. ?Insert quip about data center infiltration here. ?So, really, who is vulnerable? ?You and me.

Who said anything about big traders? I'm talking about online banking
for individuals. But sure, yes, its *us* that are really vulnerable,
not the bank (aside from having to deal with the fallout of a
customer's account being accessed). I guess I lose my recordings and
have to handle the fallout of restoring the system too though. Not a
big deal, I've done it before, recovering from hardware failure.

> This is where intrusion detection systems come into play. ?The simplest example is locking the account after a number of consecutive failed login attempts.

So. Lets say I add logic around my ssl + auth digest setup that
blacklists (via iptables) an IP address after X number of consecutive
failed login attempts. Am I then "secure enough"? I'm fairly confident
nobody is going to guess my password within 3 tries. I can't even type
it correctly within 3 tries sometimes. ;) However...

> ?It is unlikely that an attacker will guess everything right the first three (say) times

...I presume you're aware that many authentication breaches these days
aren't from outright technical hacks, they're from social engineering.
Call up grandma, sweet-talk her into giving you her login credentials,
and you're in. I'm far less susceptible to this sort of attack than
grandma is. So on that level, my mythweb auth setup is less likely to
be breached than grandma's bank account is to be accessed online.
Mitnick had a grand old time going this route before he was caught.

> before an account gets locked and requires human intervention to regain access. ?Another simple example is throttling or rejecting excessive connection attempts from a single IP address.

Which I can do as well. (And which I already do for ssh).

> Let's assume that an attacker manages to get through all of that. ?These companies have neural networks monitoring activity patterns. ?They flag aberrations and put holds on accounts pending humans calling account owners to confirm the transactions.

An intelligent individual that gains access to people's bank accounts
knows how to avoid being flagged. They could siphon tiny amounts of
money from tons of accounts -- how many people wouldn't notice a
$10/mo payment to some shell company?

> Banks and such have many layers of security around them. ?Your MythTV has one.

Well, make up your mind. Earlier, you said it had zero, none, nada,
zilch, now you say one. ;)

But again. There are additional host-side protections, and just
because an attacker gets past auth, that doesn't mean they have free
run of the entire system, nor does it mean I won't discover the
breach. And I must reiterate: its a web and multimedia server at home,
not a banking system. Not even a small business server. The security
in place is sufficient to me for the value of what's on the system. Is
it as secure as it could possibly be? No. Do I think its worth
expending the energy and/or making it less user-friendly for me to
make it as secure as it could possibly be? No.

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org