Re: de-peering for security sake
On Dec 25, 2015, at 22:16 , Dan Hollis <goemon@anime.net> wrote:
On Fri, 25 Dec 2015, Owen DeLong wrote:
Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position.
At what point do you cut the wire? How abusive is acceptable?
IMHO, you never cut the wire. You may filter selectively, but cutting the wire comes with far more collateral damage than actual useful effect. Owen
How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong" <owen@delong.com> To: "Dan Hollis" <goemon@anime.net> Cc: "Mike Hammett" <nanog@ics-il.net>, "NANOG" <nanog@nanog.org> Sent: Saturday, December 26, 2015 1:00:35 AM Subject: Re: de-peering for security sake
On Dec 25, 2015, at 22:16 , Dan Hollis <goemon@anime.net> wrote:
On Fri, 25 Dec 2015, Owen DeLong wrote:
Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position.
At what point do you cut the wire? How abusive is acceptable?
IMHO, you never cut the wire. You may filter selectively, but cutting the wire comes with far more collateral damage than actual useful effect. Owen
On 12/26/2015 06:19 AM, Mike Hammett wrote:
How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix?
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32. When I get lots of SSH probes across a range of a /24, I block the /24. When I see that the bad traffic has caused me to block multiple /24s, I will block the entire allocation. By "lots" I mean hundreds or more. When the criminals try to bust my door down, I take stops to stop them. Ditto with attempts to relay mail through my mail servers. My goal isn't to reduce traffic. My goal is to stop irresponsible people from finding a rat-hole to do things I don't authorize them to do. Defense in depth. This is in addition to selecting the TCP and UDP ports carefully that I expose to the outside world. Indeed, I have separate ACLs for inbound, outbound, and DMZ ports. So, I've limited service from the inside to the outside to this:
# ---originated by LAN host to Internet FORWARD_TCP="ftp ssh snmp telnet smtp smtps submission domain http https ntp nicname rwhois pop3 pop3s imap imaps radius" FORWARD_TCP="$FORWARD_TCP 465 8008 webcache 8443 8888 snpp rsync" # xmpp-client FORWARD_TCP="$FORWARD_TCP 5222 5223 8002" # Microsoft Notification Protocol (msnp) [Messenger] FORWARD_TCP="$FORWARD_TCP 1863" # Microsoft PPTP FORWARD_TCP="$FORWARD_TCP 1723" # Timbuktu client, Service Ports 1-4 FORWARD_TCP="$FORWARD_TCP 407 1417:1420" # memoq FORWARD_TCP="$FORWARD_TCP 2705" # FORWARD_UDP="domain ntp snmp 407 443 500 1419 1701 1812 4500 snmp 3389 10000 55555 "
Your client base and my client base differ. I make NNAP difficult to use against the world from my people. But I don't hamstring them; if they want access to an outside service, they have but to ask. I also terminate spammers.
On 26 December 2015 at 16:09, Stephen Satchell <list@satchell.net> wrote:
On 12/26/2015 06:19 AM, Mike Hammett wrote:
How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix?
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32. When I get lots of SSH probes across a range of a /24, I block the /24.
Do you people have nothing better to do than scan firewall log files and insert rules to block stuff that was already blocked by default? Hint: if ssh probes spams your log then move your ssh service to a non standard port. Regards, Baldur
1) Automation is your friend. 2) If a host is compromised and doing an SSH scan, it's likely going to also be attempting SMTP, WordPress, home router, etc. attacks. Use a canary to block that host altogether to better your network. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" <baldur.norddahl@gmail.com> To: nanog@nanog.org Sent: Saturday, December 26, 2015 9:19:15 AM Subject: Re: de-peering for security sake On 26 December 2015 at 16:09, Stephen Satchell <list@satchell.net> wrote:
On 12/26/2015 06:19 AM, Mike Hammett wrote:
How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix?
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32. When I get lots of SSH probes across a range of a /24, I block the /24.
Do you people have nothing better to do than scan firewall log files and insert rules to block stuff that was already blocked by default? Hint: if ssh probes spams your log then move your ssh service to a non standard port. Regards, Baldur
On Dec 26, 2015, at 10:09, Stephen Satchell <list@satchell.net> wrote:
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32.
... without any knowledge of how many end systems are going to be affected. A significant campus or provider user base behind a NAT is likely to have more infections in absolute terms, which means more observed bad behaviour. It also means more end-systems (again, in absolute terms) that represent collateral damage.
When I get lots of SSH probes across a range of a /24, I block the /24.
[...]
When I see that the bad traffic has caused me to block multiple /24s, I will block the entire allocation.
Your network, your rules. But that's not the way I would manage things if I thought my job was to optimise and maximise connectivity between my users and the Internet. With respect to ssh scans in particular -- disable all forms of password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them. Joe
On Sat, 26 Dec 2015 11:14:25 -0500, Joe Abley <jabley@hopcount.ca> said: >> My gauge is volume of obnoxious traffic. When I get lots of >> SSH probes from a /32, I block the /32. > ... without any knowledge of how many end systems are going to > be affected. A significant campus or provider user base behind > a NAT is likely to have more infections in absolute terms, which > means more observed bad behaviour. It also means more > end-systems (again, in absolute terms) that represent collateral > damage. Indeed this is only going to get worse with pressure on IPv4 addressing space. I often see this with small rural providers that have not yet progressed to the level of getting their own address space, and the available space is already insufficient in many cases. Another important scenario where this happens is Tor exit nodes. I have not observed any de-peering or network-layer filtering around exit nodes, but the milder, but still very obnoxious, tactic of application-layer capchas happens a lot. This is a serious problem for privacy or security conscious users (i.e. most of Tor's userbase) that tend not to enable JavaScript unless there is good reason. And a lot of these capcha systems require JavaScript. I see this every day since I live in a country where it would be foolish not to use Tor as a matter of course. Large CDNs like Cloudflare are guilty of this and this exascerbates the problem because it prevents access to a very large set of resources and not just a single web site. It's not nice. It has the effect of turning the privacy-conscious into second-class netizens. Rachel Greenstadt is presenting some research tomorrow at the CCC on the effect this has on excluding contributions to common goods such as Wikipedia: https://events.ccc.de/congress/2015/Fahrplan/events/7324.html -- William Waites <wwaites@tardis.ed.ac.uk> | School of Informatics https://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh https://hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
On Dec 26, 2015, at 08:14 , Joe Abley <jabley@hopcount.ca> wrote:
On Dec 26, 2015, at 10:09, Stephen Satchell <list@satchell.net> wrote:
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32.
... without any knowledge of how many end systems are going to be affected.
A significant campus or provider user base behind a NAT is likely to have more infections in absolute terms, which means more observed bad behaviour. It also means more end-systems (again, in absolute terms) that represent collateral damage.
Living with IPv4 sucks. It’s only going to get worse. This not news. There are no good IPv4 answers.
When I get lots of SSH probes across a range of a /24, I block the /24.
[...]
When I see that the bad traffic has caused me to block multiple /24s, I will block the entire allocation.
Your network, your rules. But that's not the way I would manage things if I thought my job was to optimise and maximise connectivity between my users and the Internet.
So what is your approach?
With respect to ssh scans in particular -- disable all forms of password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them.
This isn’t a bad idea, per se, but it’s not always possible for the guy running the server to dictate usage to the people using the accounts. Also, note that the only difference between a good long passphrase and a private key is, uh, wait, um, come to think of it, really not much. The primary difference is that nobody expects to have to remember a private key so we don’t get fussed when they contain lots of entropy. Users aren’t good at choosing good long secure passphrases and the automated mechanisms that attempt to enforce strong passwords just serve to increase user confusion and actually reduce the entropy in passwords overall. Owen
On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong <owen@delong.com> wrote:
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32. [...] With respect to ssh scans in particular -- disable all forms of
On Dec 26, 2015, at 08:14 , Joe Abley <jabley@hopcount.ca> wrote: On Dec 26, 2015, at 10:09, Stephen Satchell <list@satchell.net> wrote password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them.
This isn’t a bad idea, per se, but it’s not always possible for the guy running the server to dictate usage to the people using the accounts.
Also, note that the only difference between a good long passphrase and a private key is, uh, wait, um, come to think of it, really not much.
The primary difference is that nobody expects to have to remember a private key so we don’t get fussed when they contain lots of entropy. Users aren’t good at choosing good long secure passphrases and the automated mechanisms that attempt to enforce strong passwords just serve to increase user confusion and actually reduce the entropy in passwords overall.
No, the difference is that a passphrase works in conjunction with the private key, which is the "something you have" vs the "something you know" in two-factor authentication. With password authentication, there's only a single solution space for the attacker to sift through; with private key authentication, unless you're sloppy about securing your private key, there's two massive solution spaces for the attacker to sift through to find the unique point of intersection. Massively different solution space volumes to deal with. Equating the two only has meaning in cosmological contexts.
Owen
Matt
On Dec 26, 2015, at 12:50 , Matthew Petach <mpetach@netflight.com> wrote:
On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
My gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32. [...] With respect to ssh scans in particular -- disable all forms of
On Dec 26, 2015, at 08:14 , Joe Abley <jabley@hopcount.ca> wrote: On Dec 26, 2015, at 10:09, Stephen Satchell <list@satchell.net> wrote password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them.
This isn’t a bad idea, per se, but it’s not always possible for the guy running the server to dictate usage to the people using the accounts.
Also, note that the only difference between a good long passphrase and a private key is, uh, wait, um, come to think of it, really not much.
The primary difference is that nobody expects to have to remember a private key so we don’t get fussed when they contain lots of entropy. Users aren’t good at choosing good long secure passphrases and the automated mechanisms that attempt to enforce strong passwords just serve to increase user confusion and actually reduce the entropy in passwords overall.
No, the difference is that a passphrase works in conjunction with the private key, which is the "something you have" vs the "something you know" in two-factor authentication.
No… You are missing the point. Guessing a private key is roughly equivalent to guessing a really long pass phrase. There is no way that the server side can enforce password protection of the private key on the client side, so if you are assuming that public-key authentication is two-factor, then you are failing miserably.
With password authentication, there's only a single solution space for the attacker to sift through; with private key authentication, unless you're sloppy about securing your private key, there's two massive solution spaces for the attacker to sift through to find the unique point of intersection.
The point here is that securing the private key is a user task and not under the control of the administrator. As such, you have to assume sloppy.
Massively different solution space volumes to deal with. Equating the two only has meaning in cosmological contexts.
Or contexts where the user is sloppy about securing their private key, e.g. the real world. Owen
On Sat, 26 Dec 2015 15:11:13 -0800, Owen DeLong said:
Or contexts where the user is sloppy about securing their private key, e.g. the real world.
I seem to remember that enough people stashed their entire home directory to github, including their keys, that github had to put in special hacks to stop that.
On 27 December 2015 at 00:11, Owen DeLong <owen@delong.com> wrote:
No… You are missing the point. Guessing a private key is roughly equivalent to guessing a really long pass phrase. There is no way that the server side can enforce password protection of the private key on the client side, so if you are assuming that public-key authentication is two-factor, then you are failing miserably.
The key approach is still better. Even if the password is 123456 the attacker is not going to get in, unless he somehow stole the key file. Technically it is two-factor even if the user made one of the factors really easy. And that might save the day if you have users that chooses bad passwords. The system is weak in that it is too easy to steal the key file. It is not unlikely that a user with sloppy passwords is also sloppy with his key file. Too bad ssh does not generally support a challenge-response protocol to a write only hardware key device combined with server side passwords that can be checked against a blacklist. Regards, Baldur
On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 27 December 2015 at 00:11, Owen DeLong <owen@delong.com> wrote:
No… You are missing the point. Guessing a private key is roughly equivalent to guessing a really long pass phrase. There is no way that the server side can enforce password protection of the private key on the client side, so if you are assuming that public-key authentication is two-factor, then you are failing miserably.
The key approach is still better. Even if the password is 123456 the attacker is not going to get in, unless he somehow stole the key file.
Incorrect… It is possible the attacker could brute-force the key file. A 1024 bit key is only as good as a ~256 character passphrase in terms of entropy. If you are brute force or otherwise synthesizing the private key, you do not need the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase for the key file only matters if you already stole the key file. In terms of guessing the private key vs. guessing a suitably long pass phrase, the difficulty is roughly equivalent.
Technically it is two-factor even if the user made one of the factors really easy. And that might save the day if you have users that chooses bad passwords.
Technically it’s not two-factor and pretending it is is dangerous.
The system is weak in that it is too easy to steal the key file. It is not unlikely that a user with sloppy passwords is also sloppy with his key file.
Right… No matter what you do it is virtually impossible to protect against sloppy users. This has been true for decades even before the internet with teenagers given house keys.
Too bad ssh does not generally support a challenge-response protocol to a write only hardware key device combined with server side passwords that can be checked against a blacklist.
There’s no reason that it can’t if you use PAM. Owen
Owen you misunderstood what two factor is about. It is not practical to brute force the key file. Nor is it practical to brute force a good passphrase or password. Both have sufficient strength to withstand attack. But two factor is about having two things that needs to be broken. The key can be stolen, but the thief needs the password. The password can be stolen, but the thief needs the key. He needs both. SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor. But it is weak two factor because the key file is too easily stolen. NOT because the key file can be brute forced. Nor because hypothetically someone could memorize the content of the key file. It is also weak because the key file can be duplicated. Note it does not stop being two factor because of this, but stronger hardware based two factor systems usually come with the property that it is very hard to duplicate the key. Other examples of a two factor system were the key is easy to duplicate is credit card with magnetic strip + pin. Example where it is hard to duplicate is credit card with chip + pin. Both are examples of where the password (the pin) is actually very weak, but it is still two factor. Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in fact have a strength equal to 1024 bits entropy. It was considered equal to about 128 bit of entropy, but is believed to be weaker now. I am using ECC ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people with tin foil hats believe we should stay away from NIST altogether. Unless someone breaks the crypto, you are NOT going to brute force that key. Yes I get your argument, you are saying break the key and you won't need the password, but a) you can't actually break the key before the universe ends, b) it is still two factor, just a extremely tiny in the academic sense little bit weaker two factor. All crypto based two factor systems suffers from the possibility that one could break the crypto and possibly escape the need to know one or even both factors. But Owen - come one - this silly argument pales and is so infinite insignificant to the real problem with the ssh key two factor system, which is that the key is easily stolen and duplicated and there is no way to check the quality of the password (users might even change the key password to NO password). Regards, Baldur On 27 December 2015 at 03:37, Owen DeLong <owen@delong.com> wrote:
On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 27 December 2015 at 00:11, Owen DeLong <owen@delong.com> wrote:
No… You are missing the point. Guessing a private key is roughly equivalent to guessing a really long pass phrase. There is no way that the server side can enforce password protection of the private key on the client side, so if you are assuming that public-key authentication is two-factor, then you are failing miserably.
The key approach is still better. Even if the password is 123456 the attacker is not going to get in, unless he somehow stole the key file.
Incorrect… It is possible the attacker could brute-force the key file.
A 1024 bit key is only as good as a ~256 character passphrase in terms of entropy.
If you are brute force or otherwise synthesizing the private key, you do not need the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase for the key file only matters if you already stole the key file.
In terms of guessing the private key vs. guessing a suitably long pass phrase, the difficulty is roughly equivalent.
Technically it is two-factor even if the user made one of the factors really easy. And that might save the day if you have users that chooses bad passwords.
Technically it’s not two-factor and pretending it is is dangerous.
The system is weak in that it is too easy to steal the key file. It is not unlikely that a user with sloppy passwords is also sloppy with his key file.
Right… No matter what you do it is virtually impossible to protect against sloppy users.
This has been true for decades even before the internet with teenagers given house keys.
Too bad ssh does not generally support a challenge-response protocol to a write only hardware key device combined with server side passwords that can be checked against a blacklist.
There’s no reason that it can’t if you use PAM.
Owen
On Dec 26, 2015, at 20:35 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Owen you misunderstood what two factor is about. It is not practical to brute force the key file. Nor is it practical to brute force a good passphrase or password. Both have sufficient strength to withstand attack.
This simply isn’t as true as it’s assumed to be, but let’s move on for the moment.
But two factor is about having two things that needs to be broken. The key can be stolen, but the thief needs the password. The password can be stolen, but the thief needs the key. He needs both.
If the key file is stolen, you have one search space, the pass phrase to unlock the key. If the key file is not stolen, you have one search space: the key.
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
PCI DSS auditors think that NAT is a form of security, so don’t get me started on the fact that the PCI DSS auditors haven’t a clue about actual security. PCI DSS is more about security theater than security. In some ways, they’re even less competent than the TSA.
But it is weak two factor because the key file is too easily stolen. NOT because the key file can be brute forced. Nor because hypothetically someone could memorize the content of the key file.
Either way, you only have one search space. If you don’t have the key file, then the key is your search space. If you have the key file, then the passphrase may be an easier search space.
It is also weak because the key file can be duplicated. Note it does not stop being two factor because of this, but stronger hardware based two factor systems usually come with the property that it is very hard to duplicate the key. Other examples of a two factor system were the key is easy to duplicate is credit card with magnetic strip + pin. Example where it is hard to duplicate is credit card with chip + pin. Both are examples of where the password (the pin) is actually very weak, but it is still two factor.
To actually be two-factor, it needs to be two of something you have, something you know, something you are. The strongest combination is something you know and something you are (e.g. Retina, hand scan, etc. combined with PIN/Password). SSH Key protected by pass phrase is just two things you know. Admittedly, one of them is a thing you know because you stored it on disk instead of memorizing it, but it’s not really something you have because as you pointed out, it can be easily duplicated and also it can be transported without requiring physical movement. Something you have, in order to truly be a second factor, has to be a unique item that is: 1. In your possession 2. Cannot be (easily) duplicated without your knowledge (The greater the degree of difficulty for duplication, the better this is, but a Schlage key, for example, is sufficiently difficult to qualify in most cases). 3. Theft can be reliably detected by the fact it is no longer in your possession. An RSA or DSA key does not meet those criteria because it can be copied without your knowledge and without removing the key from your possession.
Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in fact have a strength equal to 1024 bits entropy. It was considered equal to about 128 bit of entropy, but is believed to be weaker now. I am using ECC ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people with tin foil hats believe we should stay away from NIST altogether. Unless someone breaks the crypto, you are NOT going to brute force that key.
I think you’re the first person to bring up 1024 RSA keys here. I only said private keys. A very large fraction of SSH users are still using 1024 bit DSA keys in the real world. I am still using 2048 bit DSA keys. ECC would be better. I also didn’t say that a 1024 bit key had 1024 bits of entropy. I said that a 1024 bit key and a 256-character pass phrase have about the same entropy. There are about 128 bits of entropy in a good 256 character pass phrase. There are about 128 bits of entropy in a 1024 bit DSA key.
Yes I get your argument, you are saying break the key and you won't need the password, but a) you can't actually break the key before the universe ends, b) it is still two factor, just a extremely tiny in the academic
If you have enough cheap GPUs, you can actually break a 1024 bit key well before the universe ends. In fact, you can probably break it before the end of 2016 if you’re willing to put about $30k into the process.
sense little bit weaker two factor. All crypto based two factor systems
No, it’s not a second factor. See above… It’s two things you know and not something you have and something you know as you have claimed. Calling a private key something you have instead of something you know is the same kind of slight of hand that Wall Street uses when they take a bunch of bad mortgages and package them up together and call it an AAA rated bond. (and we all saw how well that worked out). If you don’t know what I’m talking about, “The Big Short” is worth a watch.
suffers from the possibility that one could break the crypto and possibly escape the need to know one or even both factors. But Owen - come one -
Nope… Something you have isn’t subject to breaking the crypto, because it’s strength doesn’t come from crypto, it’s strength comes from unique physical properties that are difficult to duplicate and can be measured. Something you are similarly isn’t subject to breaking the crypto, because it’s strength comes from the unique physical properties of an individual person which can be measured and are difficult to duplicate. Yes, both can be broken and there are weaker and stronger choices. For example, a hand scanner is weaker than a retina scanner is weaker than a DNA scanner. Many of the finger print scanners are weaker than the hand scanners, but good ones are almost as strong as a retina scanner.
this silly argument pales and is so infinite insignificant to the real problem with the ssh key two factor system, which is that the key is easily stolen and duplicated and there is no way to check the quality of the password (users might even change the key password to NO password).
Right… That was, in fact, what I originally said at the end of my initial message, but you chose to ignore that and focus on this rathole. Since misinformation and lack of pedantry is fatal to good cryptographic security (or good security in general), I felt compelled to correct you and I still stand by what I have said. Likely, as usual, neither of us is going to convince the other one. I will say, however, that my understanding of these issues comes from mentors that work with real security professionals and I would never cite something as weak as PCI-DSS as an authority. Most of my mentors in this area work primarily on contracts with three letter government agencies that may or may not be known to exist publicly. Owen
Regards,
Baldur
On 27 December 2015 at 03:37, Owen DeLong <owen@delong.com> wrote:
On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 27 December 2015 at 00:11, Owen DeLong <owen@delong.com> wrote:
No… You are missing the point. Guessing a private key is roughly equivalent to guessing a really long pass phrase. There is no way that the server side can enforce password protection of the private key on the client side, so if you are assuming that public-key authentication is two-factor, then you are failing miserably.
The key approach is still better. Even if the password is 123456 the attacker is not going to get in, unless he somehow stole the key file.
Incorrect… It is possible the attacker could brute-force the key file.
A 1024 bit key is only as good as a ~256 character passphrase in terms of entropy.
If you are brute force or otherwise synthesizing the private key, you do not need the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase for the key file only matters if you already stole the key file.
In terms of guessing the private key vs. guessing a suitably long pass phrase, the difficulty is roughly equivalent.
Technically it is two-factor even if the user made one of the factors really easy. And that might save the day if you have users that chooses bad passwords.
Technically it’s not two-factor and pretending it is is dangerous.
The system is weak in that it is too easy to steal the key file. It is not unlikely that a user with sloppy passwords is also sloppy with his key file.
Right… No matter what you do it is virtually impossible to protect against sloppy users.
This has been true for decades even before the internet with teenagers given house keys.
Too bad ssh does not generally support a challenge-response protocol to a write only hardware key device combined with server side passwords that can be checked against a blacklist.
There’s no reason that it can’t if you use PAM.
Owen
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security). I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis). So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ? I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right? "You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions..." In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?) so, it's not really a mystery why failures like this happen.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
"really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security." Except it's *massively* more expensive. On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ?
I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right?
"You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions..."
In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?)
so, it's not really a mystery why failures like this happen.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design@gmail.com> wrote:
"really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security."
Except it's *massively* more expensive.
is it? how much does a datacenter pay for people + locks + card-key + pin-pad + ... vs the requisite bits for security their customer portal/backoffice/etc ? done right the cost shouldn't be super much more. -chris
On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ?
I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right?
"You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions..."
In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?)
so, it's not really a mystery why failures like this happen.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
"done right the cost shouldn't be super much more." I disagree. Done wrong, it's not super much more. Done right, it's massively more. Like Randy said, compare salaries alone. A good security employee will run you, what, 100k or more in the major job markets? And how many do you need, full time, to provide acceptable coverage for your environment? The costs add up really fast without a corresponding return. On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design@gmail.com> wrote:
"really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security."
Except it's *massively* more expensive.
is it? how much does a datacenter pay for people + locks + card-key + pin-pad + ...
vs
the requisite bits for security their customer portal/backoffice/etc ?
done right the cost shouldn't be super much more.
-chris
On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ?
I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right?
"You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions..."
In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?)
so, it's not really a mystery why failures like this happen.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
The costs add up really fast without a corresponding return.
i think there is a corresponding return, just not one that is perceived by the pointy heads. yet. but that is changing as more and more get pwned and the public and legal costs become greater and more apparent. patience. randy
On Sun, Dec 27, 2015 at 3:32 PM, Mike Hale <eyeronic.design@gmail.com> wrote:
"done right the cost shouldn't be super much more." I disagree. Done wrong, it's not super much more.
Done right, it's massively more.
please cite useful numbers... It's not (I think) really all that much more. Sure it's a new expense (not really, since ... you've always had security costs) but it's not 'massive'.
Like Randy said, compare salaries alone. A good security employee will run you, what, 100k or more in the major job markets? And how many do you need, full time, to provide acceptable coverage for your environment?
ideally you need 2-3 people (for a larger operation, less for small shops) with a bunch of automation to help things run along. Ideally your 2-3 experts aren't responding to the pager, almost all of that is offloaded to your noc/etc staff in a manner that they can actually deal with problems NOT as pager-spam which gets turned off. 'high quality alerts' with actionable playbooks. it'd be great if more of this was COTS-able for the smaller shops... I bet a bunch of it IS, though the parts aren't quite in place today :( which is sad.
The costs add up really fast without a corresponding return.
the return is not having to fend off the WSJ reporters of the world, and consequent lawsuits from your customers, subscribers, partners, etc... -chris
On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design@gmail.com> wrote:
"really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security."
Except it's *massively* more expensive.
is it? how much does a datacenter pay for people + locks + card-key + pin-pad + ...
vs
the requisite bits for security their customer portal/backoffice/etc ?
done right the cost shouldn't be super much more.
-chris
On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ?
I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right?
"You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions..."
In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?)
so, it's not really a mystery why failures like this happen.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
"please cite useful numbers" For what? IDS? SIEM? Log aggregation in general? For companies that have none of that, spinning up the best practice systems can easily cost half a mil a year (QRadar is 200k for our sized environment; a good netflow system is like 50 [100k+ for something like Lancope], one FTE to support and manage this as and additional workload on server and network guys in dealing with issues these tools find). And that's just the tip of the iceberg. An additional 500k a year is tough to justify (and costs way, way more than simply locking the doors or hiring a team of security guards at 10 an hour). Simplistic, of course, but one example of the cost difference. "Sure it's a new expense (not really, since ... you've always had security costs) but it's not 'massive'." Depends on the organization. For those who don't have a security-specific team, it is new spend. "ideally you need 2-3 people (for a larger operation, less for small shops) with a bunch of automation to help things run along." Absolutely agree. So we're looking at 200-300k just in pure salary cost, plus what, 40% extra for various benefits? That automation piece too is incredibly pricey (either in time and labor of software). "though the parts aren't quite in place today :( which is sad." One hundred percent in agreement. This is much, much harder for the smaller organizations to take. I wish there were services that made this way easier. I think this is where small system integrators could partner with security services that provide tier one security response (something like arctic wolf) and provide that needed coverage...but that's not inexpensive either (though way cheaper than hiring your own security dudes). "the return is not having to fend off the WSJ reporters of the world, and consequent lawsuits from your customers, subscribers, partners, etc..." True. But how do you put that in money terms? Obviously, I think the spend is absolutely important, and it's something that is vitally important to the business. But I've found it very challenging in making that case in a way that works, precisely because of that increased amount of spending. "but that is changing as more and more get pwned and the public and legal costs become greater and more apparent. patience." It is. Sony and Target were really useful in that regard. On Sun, Dec 27, 2015 at 12:51 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 3:32 PM, Mike Hale <eyeronic.design@gmail.com> wrote:
"done right the cost shouldn't be super much more." I disagree. Done wrong, it's not super much more.
Done right, it's massively more.
please cite useful numbers... It's not (I think) really all that much more. Sure it's a new expense (not really, since ... you've always had security costs) but it's not 'massive'.
Like Randy said, compare salaries alone. A good security employee will run you, what, 100k or more in the major job markets? And how many do you need, full time, to provide acceptable coverage for your environment?
ideally you need 2-3 people (for a larger operation, less for small shops) with a bunch of automation to help things run along. Ideally your 2-3 experts aren't responding to the pager, almost all of that is offloaded to your noc/etc staff in a manner that they can actually deal with problems NOT as pager-spam which gets turned off. 'high quality alerts' with actionable playbooks.
it'd be great if more of this was COTS-able for the smaller shops... I bet a bunch of it IS, though the parts aren't quite in place today :( which is sad.
The costs add up really fast without a corresponding return.
the return is not having to fend off the WSJ reporters of the world, and consequent lawsuits from your customers, subscribers, partners, etc...
-chris
On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale <eyeronic.design@gmail.com> wrote:
"really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security."
Except it's *massively* more expensive.
is it? how much does a datacenter pay for people + locks + card-key + pin-pad + ...
vs
the requisite bits for security their customer portal/backoffice/etc ?
done right the cost shouldn't be super much more.
-chris
On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
> SSH password + key file is accepted as two factor by PCI DSS auditors, so > yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ?
I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right?
"You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions..."
In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?)
so, it's not really a mystery why failures like this happen.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
So excuse me for not taking "is accepted by PCI auditors" as grounds for a claim of strong actual security.
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
hellofalot more holes to cover. and the salaries of the guards are a bit higher for the net; so more incentive for pointy heads to skimp. randy
On Dec 27, 2015, at 11:26 , Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Dec 27, 2015 at 1:59 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
SSH password + key file is accepted as two factor by PCI DSS auditors, so yes it is in fact two factor.
They also accept NAT as "security". If anything, PCI DSS is yet another example of a money grab masquerading as security theater (not even real security).
is it that? or is it that once you click the checkboxes on /pci audit/ 'no one' ever does the daily due-diligence required to keep their security processes updated/running/current/etc ?
You ask this as if those two were mutually exclusive. They are not. I believe that both are actually true. The PCI-DSS checklist can be completed without relatively weak security and involves a lot of theatrical requirements that have nothing to do with actual security. Beyond that, yes, most organizations survive the audit and then go back to ignore it until time for the next audit mode.
I'm not a fan of the compliance regimes, but their goal (in a utopian world where corporations are not people and such) is the equivalent of the little posterboard person 42" tall before the roller-coaster rides, right?
"You really, REALLY should have at least these protections/systems/etc in place before you attempt to process credit-card transactions…"
Right. And that’s a decent goal. Unfortunately, if you read the actual document, the standards require lots of things that don’t actually improve (and in some cases can actually degrade) security, such as NAT.
In the utopian world this list would be sane, useful and would include daily/etc processes to monitor the security controls for issues... I don't think there's a process bit in PCI about: "And joey the firewall admin looks at his logs daily/hourly/everly for evidence of compromise" (and yes, ideally there's some adaptive/learning/AI-like system that does the 'joey the firewall admin' step... but let's walk before running, eh?)
Yeah, it doesn’t actually require anyone or anything to ever really look at logs at all.
so, it's not really a mystery why failures like this happen.
This is a bit of a tangent, really. The discussion was about authentication factor counts and Baldur tried to use PCI-DSS acceptance of password-encrypted private key authentication as two-factor to bolster his claim that it was, in fact two-factor, when it clearly isn’t actually two-factor as has been stated previously. The comments about PCI-DSS being a non-credible standard were primarily an additional note that his argument was built on thin air.
I remember seeing a story a while ago that stated that of companies hit by a data breach on a system that was inside their PCI scope, something insane like 98% or 99% were in 100% full PCI compliance at the time of the breach. The only conclusion to be drawn is that the PCI set of checkboxes are missing a lot of really crucial things for real security. (And let's not forget the competence level of the average PCI auditor, as the ones I've encountered have all been very nice people, but more suited to checking boxes based on buzzwords than actual in-deopth security analysis).
people toss pci/sox/etc auditors under the bus 'all the time', and i'm guilty of this i'm sure as well, but really ... if you put systems on the tubes and you don't take the same care you would for your brick/mortar places ... you're gonna have a bad day. 'cyber security' really isn't a whole lot different from 'lock your damned doors and windows' brick/mortar security.
Conceptually, sure. However, in actual implementation, there’s a plethora of decent locksmiths and reasonably good security contractors out there to provide good solutions for physical security. In the cyber security world, the waters are a lot murkier. There are no good standards to allow a lay person to identify a good capable contractor vs. a charlatan with a flashy web site. Most of the widely known standards are crap. I’ve met some really good CISSPs in my day, but I’ve also met a number of people touting their CISSP certification who don’t realize that NAT is actually detrimental to security and a few who even claimed that NAT was good. Several couldn’t even get the concept of separating NAT from stateful inspection after repeated attempts to explain it to them in kindergarten terms. Cyber security is a lot harder to understand well and quite a bit more complicated than physical security. Owen
On 27 December 2015 at 22:08, Owen DeLong <owen@delong.com> wrote:
This is a bit of a tangent, really. The discussion was about authentication factor counts and Baldur tried to use PCI-DSS acceptance of password-encrypted private key authentication as two-factor to bolster his claim that it was, in fact two-factor, when it clearly isn’t actually two-factor as has been stated previously.
I wanted to stay out of this, but Owen you are full of shit here. I am pointing out that your homemade definition does not match up with what others think two factor means. PCI DSS might be utter crap, but they are still more than "Owen DeLong and his personal opinion". You are utterly confused about the meaning about two factor. You apparently believe the magic words "two factor" is a statement about the security of a system, while it is in fact just a simple property. A property that even an inherently insecure and weak system can have. It is not, as you have said, about strengthen the search space of a crypto key (just double the key length if you need that). In fact, many two factor systems do not use crypto keys at all. An example of such a non crypto based system is a credit card with magnetic strip plus pin. The magnetic strip contains just the card number, which can also be read directly from the card and even memorized by the owner. We need two factor because if you have just one factor, say the password, the hacker will simply call the user and ask him to tell the password. And the users will happily obligate. Experience shows this. On the other hand, if you give the users a single factor system with a physical token (a key), that gets stolen, misplaced or "borrowed" far too easily. Therefore industry standard is card + pin to enter a building (=two factor). Secure places require three factor (card + pin + biometric). SSH keys are two factor because people do not in general memorize the key file. Because they do not, you can not gain access to the system with only what you know (=in your mind). Unless the user violated protocols and changed the passphrase to null, you can not gain access just by possession of the key file. That is all that is required to name it two factor. That Owen DeLong believes the system stinks does not change that at all. Historically the banks used to depend on a system that is the same as ssh keys: certificate files you have on your computer to access the bank website. That also is a two factor system. The users did not usually memorize the content of the certificates. The system is weak because bad guys used malware to steal the certificate files and install key loggers to also get the other factor, the password. In my country (Denmark) they decided hardware keys are still too expensive, so they developed a two factor system based on paper keys. You will get a piece of paper with a few hundred random numbers. When you log in, you are asked to type one of the numbers in to prove that you are in possession of the key paper. The codes are just 6 digits and infinite weak if you believe them to be part of any crypto scheme. This system has also been broken because now bad guys ask the users to take pictures of the key paper to prove something, and the users happily do just that. Banks are still happy though, because the loss is less than the cost to ship hardware keys to everyone. Only strong two factor systems are really resistant to the users defeating the system by doing stupid things. That does not mean that only strong two factor systems are two factor. That would be silly - Owen what would you then name weak and broken two factor systems? It is a property - nothing more. Regards, Baldur
On Dec 27, 2015, at 14:33 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 27 December 2015 at 22:08, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: This is a bit of a tangent, really. The discussion was about authentication factor counts and Baldur tried to use PCI-DSS acceptance of password-encrypted private key authentication as two-factor to bolster his claim that it was, in fact two-factor, when it clearly isn’t actually two-factor as has been stated previously.
I wanted to stay out of this, but Owen you are full of shit here. I am pointing out that your homemade definition does not match up with what others think two factor means. PCI DSS might be utter crap, but they are still more than "Owen DeLong and his personal opinion”.
Dude… It’s not just my opinion. Virtually every one else who chimed in on the thread other than you backed my position on this.
You are utterly confused about the meaning about two factor. You apparently believe the magic words "two factor" is a statement about the security of a system, while it is in fact just a simple property. A property that even an inherently insecure and weak system can have.
No, as I pointed out, you can have very weak security with two weak factors. However, the property two-factor means something and it’s not what you apparently think.
It is not, as you have said, about strengthen the search space of a crypto key (just double the key length if you need that). In fact, many two factor systems do not use crypto keys at all. An example of such a non crypto based system is a credit card with magnetic strip plus pin. The magnetic strip contains just the card number, which can also be read directly from the card and even memorized by the owner.
Actually, the magnetic stripe contains quite a bit more than the card number, but that’s another tangent. I never said you had to have crypto for two-factor, nor did I say that two factor magically made things stronger.
We need two factor because if you have just one factor, say the password, the hacker will simply call the user and ask him to tell the password. And the users will happily obligate. Experience shows this. On the other hand, if you give the users a single factor system with a physical token (a key), that gets stolen, misplaced or "borrowed" far too easily. Therefore industry standard is card + pin to enter a building (=two factor). Secure places require three factor (card + pin + biometric).
Card+pin is an example of two factors… You _HAVE_ the card and you _KNOW_ the PIN. Password-encrypted Key, OTOH, is something you _KNOW_ and something else you _KNOW_. It’s not something you _HAVE_ or something you _ARE_. There are three generally accepted categories of Factors for authentication… 1. Something you HAVE 2. Something you KNOW 3. Something you ARE In order to qualify as 2-factor, a system must require something from two of the categories. Two things from the same category do not qualify.
SSH keys are two factor because people do not in general memorize the key file. Because they do not, you can not gain access to the system with only what you know (=in your mind). Unless the user violated protocols and changed the passphrase to null, you can not gain access just by possession of the key file. That is all that is required to name it two factor. That Owen DeLong believes the system stinks does not change that at all.
Something on disk counts as something you know. A private/public key pair is not something you HAVE because it’s not a physical object and it’s certainly not something you ARE. It’s clearly in the something you KNOW category for all practical purposes, even if you don’t memorize it into your mind. Now, a private key in black box where you feed it encrypted stuff to be decrypted or decrypted stuff to be encrypted and you cannot extract the private key, that could be something you HAVE. But at that point, it’s the black box that is the thing you have, not the key itself. The key in the box and the boxes ability to decrypt/encrypt using that key is merely a mechanism for proving that you have the correct black box.
Historically the banks used to depend on a system that is the same as ssh keys: certificate files you have on your computer to access the bank website. That also is a two factor system. The users did not usually memorize the content of the certificates. The system is weak because bad guys used malware to steal the certificate files and install key loggers to also get the other factor, the password.
Again, real two-factor authentication depends on factors from different categories above. The certificate, like it or not, whether you memorize it or not, is something you KNOW, not something you HAVE. To qualify as something you HAVE, it has to be a unique physical token with some degree of difficulty in duplication. Some physical tokens are easier to duplicate than others. Examples include keys for pin-tumbler locks. Even those come in varying degrees of difficulty (3, 5, or 7 pins, straight or spool pins, angled pin alignments, etc.)
In my country (Denmark) they decided hardware keys are still too expensive, so they developed a two factor system based on paper keys. You will get a piece of paper with a few hundred random numbers. When you log in, you are asked to type one of the numbers in to prove that you are in possession of the key paper. The codes are just 6 digits and infinite weak if you believe them to be part of any crypto scheme. This system has also been broken because now bad guys ask the users to take pictures of the key paper to prove something, and the users happily do just that. Banks are still happy though, because the loss is less than the cost to ship hardware keys to everyone.
Why not just use Google Authenticator (free App) with a unique series on people’s smartphones? I’m pretty sure smartphones are quite common in DK by now.
Only strong two factor systems are really resistant to the users defeating the system by doing stupid things. That does not mean that only strong two factor systems are two factor. That would be silly - Owen what would you then name weak and broken two factor systems? It is a property - nothing more.
Correct. However, calling a system which depends on two “factors” from the same factor category doesn’t meet the requirements of a two factor system. Password protected SSH key is all in the something you KNOW category. Especially when you consider that you aren’t presenting the password and the key to the authenticator, you are using the password to unlock the key that is presented to the authenticator. (yes, I realize the key isn’t actually presented, it’s done differently involving using the key to encrypt a hash which can then be verified as correctly encrypted by decrypting with the public key, but that’s a technicality that isn’t really relevant here). Owen
Also think of it from the perspective of the authenticating host. That SSH connection relies *only* on the key for authentication. It requires nothing else. How you protect that key is irrelevant. All that matters is that the host is accepting a single form of authentication. It's clearly single-factor. You can call pseudo-multi-factor if you want. It's certainly better than a shitty password. But it's not multi-factor by the generally accepted definition (although I'd place it under 'something you have' rather than the 'something you know' section). On Sun, Dec 27, 2015 at 5:08 PM, Owen DeLong <owen@delong.com> wrote:
On Dec 27, 2015, at 14:33 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 27 December 2015 at 22:08, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: This is a bit of a tangent, really. The discussion was about authentication factor counts and Baldur tried to use PCI-DSS acceptance of password-encrypted private key authentication as two-factor to bolster his claim that it was, in fact two-factor, when it clearly isn’t actually two-factor as has been stated previously.
I wanted to stay out of this, but Owen you are full of shit here. I am pointing out that your homemade definition does not match up with what others think two factor means. PCI DSS might be utter crap, but they are still more than "Owen DeLong and his personal opinion”.
Dude… It’s not just my opinion. Virtually every one else who chimed in on the thread other than you backed my position on this.
You are utterly confused about the meaning about two factor. You apparently believe the magic words "two factor" is a statement about the security of a system, while it is in fact just a simple property. A property that even an inherently insecure and weak system can have.
No, as I pointed out, you can have very weak security with two weak factors.
However, the property two-factor means something and it’s not what you apparently think.
It is not, as you have said, about strengthen the search space of a crypto key (just double the key length if you need that). In fact, many two factor systems do not use crypto keys at all. An example of such a non crypto based system is a credit card with magnetic strip plus pin. The magnetic strip contains just the card number, which can also be read directly from the card and even memorized by the owner.
Actually, the magnetic stripe contains quite a bit more than the card number, but that’s another tangent.
I never said you had to have crypto for two-factor, nor did I say that two factor magically made things stronger.
We need two factor because if you have just one factor, say the password, the hacker will simply call the user and ask him to tell the password. And the users will happily obligate. Experience shows this. On the other hand, if you give the users a single factor system with a physical token (a key), that gets stolen, misplaced or "borrowed" far too easily. Therefore industry standard is card + pin to enter a building (=two factor). Secure places require three factor (card + pin + biometric).
Card+pin is an example of two factors… You _HAVE_ the card and you _KNOW_ the PIN.
Password-encrypted Key, OTOH, is something you _KNOW_ and something else you _KNOW_. It’s not something you _HAVE_ or something you _ARE_.
There are three generally accepted categories of Factors for authentication…
1. Something you HAVE 2. Something you KNOW 3. Something you ARE
In order to qualify as 2-factor, a system must require something from two of the categories. Two things from the same category do not qualify.
SSH keys are two factor because people do not in general memorize the key file. Because they do not, you can not gain access to the system with only what you know (=in your mind). Unless the user violated protocols and changed the passphrase to null, you can not gain access just by possession of the key file. That is all that is required to name it two factor. That Owen DeLong believes the system stinks does not change that at all.
Something on disk counts as something you know. A private/public key pair is not something you HAVE because it’s not a physical object and it’s certainly not something you ARE.
It’s clearly in the something you KNOW category for all practical purposes, even if you don’t memorize it into your mind.
Now, a private key in black box where you feed it encrypted stuff to be decrypted or decrypted stuff to be encrypted and you cannot extract the private key, that could be something you HAVE. But at that point, it’s the black box that is the thing you have, not the key itself. The key in the box and the boxes ability to decrypt/encrypt using that key is merely a mechanism for proving that you have the correct black box.
Historically the banks used to depend on a system that is the same as ssh keys: certificate files you have on your computer to access the bank website. That also is a two factor system. The users did not usually memorize the content of the certificates. The system is weak because bad guys used malware to steal the certificate files and install key loggers to also get the other factor, the password.
Again, real two-factor authentication depends on factors from different categories above. The certificate, like it or not, whether you memorize it or not, is something you KNOW, not something you HAVE.
To qualify as something you HAVE, it has to be a unique physical token with some degree of difficulty in duplication. Some physical tokens are easier to duplicate than others. Examples include keys for pin-tumbler locks. Even those come in varying degrees of difficulty (3, 5, or 7 pins, straight or spool pins, angled pin alignments, etc.)
In my country (Denmark) they decided hardware keys are still too expensive, so they developed a two factor system based on paper keys. You will get a piece of paper with a few hundred random numbers. When you log in, you are asked to type one of the numbers in to prove that you are in possession of the key paper. The codes are just 6 digits and infinite weak if you believe them to be part of any crypto scheme. This system has also been broken because now bad guys ask the users to take pictures of the key paper to prove something, and the users happily do just that. Banks are still happy though, because the loss is less than the cost to ship hardware keys to everyone.
Why not just use Google Authenticator (free App) with a unique series on people’s smartphones? I’m pretty sure smartphones are quite common in DK by now.
Only strong two factor systems are really resistant to the users defeating the system by doing stupid things. That does not mean that only strong two factor systems are two factor. That would be silly - Owen what would you then name weak and broken two factor systems? It is a property - nothing more.
Correct. However, calling a system which depends on two “factors” from the same factor category doesn’t meet the requirements of a two factor system.
Password protected SSH key is all in the something you KNOW category. Especially when you consider that you aren’t presenting the password and the key to the authenticator, you are using the password to unlock the key that is presented to the authenticator.
(yes, I realize the key isn’t actually presented, it’s done differently involving using the key to encrypt a hash which can then be verified as correctly encrypted by decrypting with the public key, but that’s a technicality that isn’t really relevant here).
Owen
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
On Sat, Dec 26, 2015 at 6:37 PM, Owen DeLong <owen@delong.com> wrote:
On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
[...]
The key approach is still better. Even if the password is 123456 the attacker is not going to get in, unless he somehow stole the key file.
Incorrect… It is possible the attacker could brute-force the key file.
A 1024 bit key is only as good as a ~256 character passphrase in terms of entropy.
If you are brute force or otherwise synthesizing the private key, you do not need the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase for the key file only matters if you already stole the key file.
In terms of guessing the private key vs. guessing a suitably long pass phrase, the difficulty is roughly equivalent.
Intriguing point. I was thinking about it from the end-user perspective; but you're right, from the bits-on-the-wire perspective, it's all just a stream of 1's and 0's, whether it came from a private key + passphrase run through an algorithm or not. Thanks for the reminder to look at it from multiple perspectives. ^_^ Matt
On Sat, Dec 26, 2015 at 10:06 PM, Matthew Petach <mpetach@netflight.com> wrote:
Thanks for the reminder to look at it from multiple perspectives.
The key attribute missing from the discussion so far is that the factors be *different*, from the set of: - something you know (password / PIN) - something you have (keyfob / OTP generator / chip) - something you are (fingerprint / retina scan) Claiming a passphrase and key are two "factors" is missing the point -- they both come from the same set (a secret which could be cloned). If you believe those are two factors then a password alone is 10 factors (one for each character)! ;) Damian
On Sat, 26 Dec 2015 12:50:27 -0800, Matthew Petach said:
No, the difference is that a passphrase works in conjunction with the private key, which is the "something you have" vs the "something you know" in two-factor authentication.
With password authentication, there's only a single solution space for the attacker to sift through; with private key authentication, unless you're sloppy about securing your private key, there's two massive solution spaces for the attacker to sift through to find the unique point of intersection.
Actually, to be pedantic (and this is crypto, where failure to be pedantic can be fatal), the online attacker still has only one large space to search through. The private key you have on disk isn't the private key you present to the remote server - the passphrase is used to convert from one to the other. (Hint: Consider the case of an ssh key generated without a passphrase. Yes, there's valid reasons for doing this, such as allowing an ssh from within a cronjob or other place where providing a passphrase is difficult. And yes, if you do this, you should be securing it at the server end to only allow that key to invoke the one command it was intended to, by using the 'command="/your/one/command/here" option in authorized_keys)
unless you're sloppy about securing your private key, there's two massive solution spaces for the attacker to sift through to find the unique point of intersection.
Actually, you have that backwards. The attacker only has 2 solution spaces if you *have* been sloppy and your private key is captured. The passphrase only helps if your private key on disk is captured - the length of it determines how many possible on-the-wire private keys could correspond to that on-disk copy. Just remember that if they captured that, they almost certainly also captured your known_hosts file - you *did* hash that, right? :) And of course, nothing hardens it like an iptables rule that only accepts inbound port 22 (or whatever you chose) to only address space you *expect* to see inbound ssh from. :)
On Dec 26, 2015, at 12:34, Owen DeLong <owen@delong.com> wrote:
Also, note that the only difference between a good long passphrase and a private key is, uh, wait, um, come to think of it, really not much.
Are you equating a long PSK with PKE? They’re quite different.
On Dec 26, 2015, at 11:14 AM, Joe Abley <jabley@hopcount.ca> wrote:
With respect to ssh scans in particular -- disable all forms of password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them.
Or if you can’t get users to use keys (aside from remove the users) consider things like: example /etc/ssh/sshd_config Match User root PasswordAuthentication no for users that should not be permitted to fall-back to password authentication. - Jared
Different network types will have different abilities to enforce this. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" <jared@puck.nether.net> To: "Joe Abley" <jabley@hopcount.ca> Cc: nanog@nanog.org Sent: Saturday, December 26, 2015 3:21:03 PM Subject: Re: de-peering for security sake
On Dec 26, 2015, at 11:14 AM, Joe Abley <jabley@hopcount.ca> wrote:
With respect to ssh scans in particular -- disable all forms of password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them.
Or if you can’t get users to use keys (aside from remove the users) consider things like: example /etc/ssh/sshd_config Match User root PasswordAuthentication no for users that should not be permitted to fall-back to password authentication. - Jared
I think as granular as practicable. In some cases, that will be a /32 or /128. In some cases, that will be a /24 or /64. In some cases, it may be an entire ASN. Each network will need to decide for themselves based on the constraints of the time they have to address the issue, the level of automation for addressing these things, memory in their routing platform(s), etc. There is no one-size-fits all answer. Owen
On Dec 26, 2015, at 06:19 , Mike Hammett <nanog@ics-il.net> wrote:
How much is an acceptable standard to the community? Individual /32s ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent would be) has made your naughty list that you block the whole prefix?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest Internet Exchange http://www.midwest-ix.com
----- Original Message -----
From: "Owen DeLong" <owen@delong.com> To: "Dan Hollis" <goemon@anime.net> Cc: "Mike Hammett" <nanog@ics-il.net>, "NANOG" <nanog@nanog.org> Sent: Saturday, December 26, 2015 1:00:35 AM Subject: Re: de-peering for security sake
On Dec 25, 2015, at 22:16 , Dan Hollis <goemon@anime.net> wrote:
On Fri, 25 Dec 2015, Owen DeLong wrote:
Merely because people are asleep at the switch does not give those of us in a position to understand the consequences license to abuse our position.
At what point do you cut the wire? How abusive is acceptable?
IMHO, you never cut the wire. You may filter selectively, but cutting the wire comes with far more collateral damage than actual useful effect.
Owen
participants (14)
-
Baldur Norddahl -
Christopher Morrow -
Damian Menscher -
James Downs -
Jared Mauch -
Joe Abley -
Matthew Petach -
Mike Hale -
Mike Hammett -
Owen DeLong -
Randy Bush -
Stephen Satchell -
Valdis.Kletnieks＠vt.edu -
William Waites