FAQ
Suppose I have a CentOS 5.7 machine running the default Apache with no
extra modules enabled, and with the "yum-updatesd" service running to pull
down and install updates as soon as they become available from the
repository. (Assume further the password is strong, etc.) On the other
hand, suppose that as the admin, I'm not subscribed to any security alert
mailing lists which send out announcements like "Please disable this
feature as a workaround until this hole is plugged", so the machine just
hums along with all of its default settings.

So the machine can still be broken into, if there is an unpatched exploit
released in the wild, in the window of time before a patch is released for
that update. On the other hand, at any point in time where there are no
unpatched exploits in the wild, the machine should be much harder to break
into.

Roughly what percent of the time is there such an unpatched exploit in the
wild, so that the machine can be hacked by someone keeping up with the
exploits? 5%? 50%? 95%?

Hopefully this is specific enough that the answer is not "it depends" :) ,
an actual numeric answer should exist -- although I don't know if anyone
has ever tried to work it out. But if not, then what's a good guess, based
on observing how frequently root exploits are released in the wild, and how
long the patches usually take.

Bennett

Search Discussions

  • Karanbir Singh at Dec 27, 2011 at 10:29 pm

    On 12/28/2011 03:13 AM, Bennett Haselton wrote:
    Roughly what percent of the time is there such an unpatched exploit in the
    wild, so that the machine can be hacked by someone keeping up with the
    exploits? 5%? 50%? 95%?
    there is no way to tell, and there is no metric to work against unless
    there is some source that can identify exactly when and how a specific
    exploit was discovered ( but then again, many exploits are not reported
    by the people who find them, they just abuse those exploits till such
    time as they can )

    - KB
  • Gilbert Sebenste at Dec 27, 2011 at 10:33 pm

    On Tue, 27 Dec 2011, Bennett Haselton wrote:

    Suppose I have a CentOS 5.7 machine running the default Apache with no
    extra modules enabled, and with the "yum-updatesd" service running to pull
    down and install updates as soon as they become available from the
    repository.

    So the machine can still be broken into, if there is an unpatched exploit
    released in the wild, in the window of time before a patch is released for
    that update.

    Roughly what percent of the time is there such an unpatched exploit in the
    wild, so that the machine can be hacked by someone keeping up with the
    exploits? 5%? 50%? 95%?
    There's no way to give you an exact number, but let me put it this way:

    If you've disable as much as you can (which by default, most stuff is
    disabled, so that's good), and you restart Apache after each update,
    your chances of being broken into are better by things like SSH brute
    force attacks. There's always a chance someone will get in, but when you
    look at the security hole history of Apache, particularly over the past
    few years, there have been numerous CVE's, but workarounds and they aren't
    usually earth-shattering. Very few of them have. The latest version that
    ships with 5.7 is as secure as they come. If it wasn't, most web sites
    on the Internet would be hacked by now, as most run Apache.

    *******************************************************************************
    Gilbert Sebenste ********
    (My opinions only!) ******
    *******************************************************************************
  • Bennett Haselton at Dec 27, 2011 at 11:29 pm

    On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste wrote:
    On Tue, 27 Dec 2011, Bennett Haselton wrote:

    Suppose I have a CentOS 5.7 machine running the default Apache with no
    extra modules enabled, and with the "yum-updatesd" service running to pull
    down and install updates as soon as they become available from the
    repository.

    So the machine can still be broken into, if there is an unpatched exploit
    released in the wild, in the window of time before a patch is released for
    that update.

    Roughly what percent of the time is there such an unpatched exploit in the
    wild, so that the machine can be hacked by someone keeping up with the
    exploits? 5%? 50%? 95%?
    There's no way to give you an exact number, but let me put it this way:

    If you've disable as much as you can (which by default, most stuff is
    disabled, so that's good), and you restart Apache after each update,
    your chances of being broken into are better by things like SSH brute
    force attacks. There's always a chance someone will get in, but when you
    look at the security hole history of Apache, particularly over the past
    few years, there have been numerous CVE's, but workarounds and they aren't
    usually earth-shattering. Very few of them have. The latest version that
    ships with 5.7 is as secure as they come. If it wasn't, most web sites
    on the Internet would be hacked by now, as most run Apache
    I was asking because I had a server that did get broken into, despite
    having yum-updatesd running and a strong password. He said that even if
    you apply all latest updates automatically, there were still windows of
    time where an exploit in the wild could be used to break into a machine; in
    particular he said:

    "For example, there was a while back ( ~march ) a kernel exploit that
    affected CentOS / RHEL. The patch came after 1-2 weeks of the security
    announcement. The initial announcement provided a simple work around until
    the new version is released."

    Was this a sufficiently high-profile incident that you know what he's
    referring to? If this kind of thing happens once a year or more, than
    surely this is a much greater threat than "brute forcing the SSH
    password"? That's what I'm talking about -- how often does this sort of
    thing happen, where you need to be subscribed to be a security mailing list
    in order to know what workaround to make to stay safe, as opposed to simply
    running yum-updatesd to install latest patches automatically.

    Bennett
  • Karanbir Singh at Dec 27, 2011 at 11:38 pm

    On 12/28/2011 04:29 AM, Bennett Haselton wrote:
    I was asking because I had a server that did get broken into, despite
    having yum-updatesd running and a strong password. He said that even if
    the software component compromised was a part of the updates being
    dished out from the distro ( and therefore likely covered via the
    yum-updatesd? )

    - KB
  • Bennett Haselton at Dec 27, 2011 at 11:42 pm
    Everything installed on the machine had been installed with "yum". So I
    assumed that meant that it would also be updated by "yum" if an update was
    available from the distro.
    On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh wrote:
    On 12/28/2011 04:29 AM, Bennett Haselton wrote:
    I was asking because I had a server that did get broken into, despite
    having yum-updatesd running and a strong password. He said that even if
    the software component compromised was a part of the updates being
    dished out from the distro ( and therefore likely covered via the
    yum-updatesd? )

    - KB
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Johnny Hughes at Dec 28, 2011 at 8:10 am

    On 12/27/2011 10:42 PM, Bennett Haselton wrote:
    Everything installed on the machine had been installed with "yum". So I
    assumed that meant that it would also be updated by "yum" if an update was
    available from the distro.
    1. Are you running PHP apps on the web server? Perl apps? Bad code in
    dynamic apps is the main way security breaches happen if via apache.
    And in those cases is usually the ability to execute some script
    (sometimes one that the bad guys upload first) that is the issue. Many
    times this happens because programmers of the dynamic (php, perl,
    python, ruby, etc.) do not properly vet the input of some form or other
    item.

    2. Why have password logins at all? Using a secure ssh key only for
    logins makes the most sense.

    3. Please do not top post.
    On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh wrote:
    On 12/28/2011 04:29 AM, Bennett Haselton wrote:
    I was asking because I had a server that did get broken into, despite
    having yum-updatesd running and a strong password. He said that even if
    the software component compromised was a part of the updates being
    dished out from the distro ( and therefore likely covered via the
    yum-updatesd? )
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111228/26c8dbc5/attachment.bin
  • Bennett Haselton at Dec 29, 2011 at 3:17 am

    On Wed, Dec 28, 2011 at 6:10 AM, Johnny Hughes wrote:
    On 12/27/2011 10:42 PM, Bennett Haselton wrote:
    Everything installed on the machine had been installed with "yum". So I
    assumed that meant that it would also be updated by "yum" if an update was
    available from the distro.
    1. Are you running PHP apps on the web server? Perl apps? Bad code in
    dynamic apps is the main way security breaches happen if via apache.
    And in those cases is usually the ability to execute some script
    (sometimes one that the bad guys upload first) that is the issue. Many
    times this happens because programmers of the dynamic (php, perl,
    python, ruby, etc.) do not properly vet the input of some form or other
    item.
    The only popular third-party script on the server was glype from
    www.glype.com. I don't know if it's popular enough (compared to, say,
    WordPress) to make it worthwhile for the bad guys to have developed an
    exploit against it. On the other hand, if they used an automated tool that
    can be pointed to *any* PHP script and probe it for weaknesses, they could
    have found something.


    >

    2. Why have password logins at all? Using a secure ssh key only for
    logins makes the most sense.
    Well that's something that I'm curious about the reasoning behind -- if
    you're already using a completely random 12-character password, why would
    it be any more secure to use an ssh key? Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.

    3. Please do not top post.
    >

    My bad. Gmail default. :)
  • Reindl Harald at Dec 29, 2011 at 6:29 am

    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    2. Why have password logins at all? Using a secure ssh key only for
    logins makes the most sense.
    Well that's something that I'm curious about the reasoning behind -- if
    you're already using a completely random 12-character password, why would
    it be any more secure to use an ssh key? Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    because the key is MUCH longer than 12 chars
    becasue it is NOT bruteforceable
    because brute-force-attacks are trying password-login

    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111229/d0d103e2/attachment.bin
  • Leonard den Ottolander at Dec 29, 2011 at 6:56 am
    Hello Reindl,
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    Bennett clearly states that he understands the ssh key is more random,
    but wonders why a 12 char password (of roughly 6 bits entropy per byte
    assuming upper & lower case characters and numbers) wouldn't be
    sufficient.

    I'm fairly confident the 9 to 12 char (54 to 72 bit) passwords I use are
    sufficiently strong to protect my machines against remote brute force
    attacks via ssh. Seeing that every login attempt takes at least a second
    and in the default setup sshd allows a maximum of 10 threads at a time a
    remote brute force is not really feasible (1/2 . 2 ^ 54 . 1s / 10). Imho
    of course :)

    Regards,
    Leonard.

    --
    mount -t life -o ro /dev/dna /genetic/research
  • Reindl Harald at Dec 29, 2011 at 7:07 am

    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    Hello Reindl,
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    Bennett clearly states that he understands the ssh key is more random,
    but wonders why a 12 char password (of roughly 6 bits entropy per byte
    assuming upper & lower case characters and numbers) wouldn't be
    sufficient.
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?

    this is a secure configuration with no costs
    so why not use it?

    PasswordAuthentication no
    ChallengeResponseAuthentication no
    GSSAPIAuthentication no
    GSSAPICleanupCredentials no
    RSAAuthentication yes
    PubkeyAuthentication yes
    PermitEmptyPasswords no
    PermitRootLogin without-password
    AllowGroups root verwaltung
    AllowUsers root harry
    IgnoreRhosts yes
    HostbasedAuthentication no
    StrictModes yes
    UseDNS no
    UsePrivilegeSeparation yes
    UsePAM yes
    LoginGraceTime 25
    MaxAuthTries 10
    MaxStartups 25

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111229/f26962c3/attachment.bin
  • Marko Vojinovic at Dec 29, 2011 at 8:21 am

    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    Hello Reindl,
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    Bennett clearly states that he understands the ssh key is more random,
    but wonders why a 12 char password (of roughly 6 bits entropy per byte
    assuming upper & lower case characters and numbers) wouldn't be
    sufficient.
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too random to
    be memorized --- you have to carry it on a usb stick (or whereever). This
    provides an additional point of failure should your stick get lost or stolen.
    Human brain is still by far the most secure information-storage device. :-)

    It is very inconvenient for people who need to login to their servers from
    random remote locations (ie. people who travel a lot or work in hardware-
    controlled environment).

    Besides, it is essentially a question of overkill. If password is not good
    enough, you could argue that the key is also not good enough --- two keys (or
    a larger one) would be more secure. Where do you draw the line?

    Best, :-)
    Marko
  • Reindl Harald at Dec 29, 2011 at 8:59 am

    Am 29.12.2011 14:21, schrieb Marko Vojinovic:
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too random to
    be memorized --- you have to carry it on a usb stick (or whereever). This
    provides an additional point of failure should your stick get lost or stolen.
    Human brain is still by far the most secure information-storage device. :-)
    this is bullshit
    most people have their ssh-key on a usb-stick

    normally a ssh-key is protected by a password
    this can be your 12-char password

    if you put an non-proctected key on a stick this is really
    your problem - per default it is requestet from ssh-keygen

    the hughe difference is: while having the same password (for the key)
    it can not be used directly for brute-force und you need the password
    and at least one time access to the key file



    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111229/d04ab312/attachment.bin
  • Mark Roth at Dec 29, 2011 at 9:24 am

    Reindl Harald wrote:
    Am 29.12.2011 14:21, schrieb Marko Vojinovic:
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too
    random to be memorized --- you have to carry it on a usb stick (or
    whereever). This provides an additional point of failure should your
    stick get lost or stolen.
    Human brain is still by far the most secure information-storage device.
    :-)
    this is bullshit
    most people have their ssh-key on a usb-stick

    normally a ssh-key is protected by a password
    this can be your 12-char password
    <snip>
    Many US companies have gone past that. A number that I've worked for, and
    the one I work for, all have used RSA keyfobs. To open the VPN link, you
    need three pieces of information: userid, PIN (which is up to 8 chars min)
    and the six digit code from the fob.

    The US gov't has gone a different way: it issues CaC or PIV-II cards, and
    you need a) a card reader attached or builtin to your system, b) the card,
    and c) your PIN (8 digits).

    In both cases, once you've got your VPN, *then* it will frequently be
    asking for username & passwords for each different kind of access.

    mark
  • Reindl Harald at Dec 29, 2011 at 9:28 am

    Am 29.12.2011 15:24, schrieb m.roth at 5-cent.us:
    Reindl Harald wrote:
    Am 29.12.2011 14:21, schrieb Marko Vojinovic:
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too
    random to be memorized --- you have to carry it on a usb stick (or
    whereever). This provides an additional point of failure should your
    stick get lost or stolen.
    Human brain is still by far the most secure information-storage device.
    :-)
    this is bullshit
    most people have their ssh-key on a usb-stick

    normally a ssh-key is protected by a password
    this can be your 12-char password
    <snip>
    Many US companies have gone past that.

    A number that I've worked for, and
    the one I work for, all have used RSA keyfobs. To open the VPN link, you
    need three pieces of information: userid, PIN (which is up to 8 chars min)
    and the six digit code from the fob.

    The US gov't has gone a different way: it issues CaC or PIV-II cards, and
    you need a) a card reader attached or builtin to your system, b) the card,
    and c) your PIN (8 digits).

    In both cases, once you've got your VPN, *then* it will frequently be
    asking for username & passwords for each different kind of access.
    why do you not tell this the idiot who is argumentating against kyes
    and thinks using password-login is smart?


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111229/3a76f834/attachment.bin
  • Leonard den Ottolander at Dec 30, 2011 at 3:24 pm
    Reinl,
    On Thu, 2011-12-29 at 15:28 +0100, Reindl Harald wrote:
    why do you not tell this the idiot who is argumentating against kyes
    and thinks using password-login is smart?
    I don't like your tone. I'm not sure if it's me or Bennett you are
    calling an idiot or both, but in any case you should mind your words and
    try to understand the argument others are making before shooting off
    your mouth.

    I merely responded to Bennett's inquiry why a 12 char password wouldn't
    be sufficiently strong. I believe Marko also made the point that it is
    always arbitrary where to draw the line as to what you consider
    strong/safe enough. I made my point why I believe using 9 to 12
    character passwords is sufficiently secure for my purposes (I do not run
    a military facility).

    Now if you have an argument to make about that statement I'm very
    interested to hear it. On the other hand, if you start calling people
    idiots on a public channel because you think they do not understand what
    you are telling (where it's actually you who seems to be missing the
    point they are making) I don't consider you a suitable conversation
    partner. You should understand discussions on lists like these are made
    on arguments not insults.

    Leonard.

    --
    mount -t life -o ro /dev/dna /genetic/research
  • Mark Roth at Dec 30, 2011 at 3:35 pm

    Leonard den Ottolander wrote:
    Reinl,
    On Thu, 2011-12-29 at 15:28 +0100, Reindl Harald wrote:
    why do you not tell this the idiot who is argumentating against kyes
    and thinks using password-login is smart?
    I don't like your tone. I'm not sure if it's me or Bennett you are
    calling an idiot or both, but in any case you should mind your words and
    try to understand the argument others are making before shooting off
    your mouth. <snip>
    Now if you have an argument to make about that statement I'm very
    interested to hear it. On the other hand, if you start calling people
    idiots on a public channel because you think they do not understand what
    you are telling (where it's actually you who seems to be missing the
    point they are making) I don't consider you a suitable conversation
    partner. You should understand discussions on lists like these are made
    on arguments not insults.
    Agreed. I don't even label as idiots the idiots who post here, asking us
    to tell them how to do the job they were hired for, without any indication
    that they've read man pages, or googled for an answer.

    mark
  • Marc Deop at Dec 29, 2011 at 10:41 am

    On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
    the hughe difference is: while having the same password (for the key)
    it can not be used directly for brute-force und you need the password
    and at least one time access to the key file
    Explain me how having a key protected by a password avoids brute forcing if you loose the usb stick holding that key?

    Technology is developing at a scary pace, have a look at this:
    http://mytechencounters.wordpress.com/2011/04/03/gpu-password-cracking-crack-a-windows-password-using-a-graphic-card/

    And this is with a simple card, imagine what you can do with a system with multiple paralel cards...


    Just to be clear: I'm not arguing which system is better/more secure. I'm just pointing out one downside of having the key in a usb memory.

    And bruteforcing against ssh servers are really difficult as some others have commented (and even more difficult if you limit failed connections...)

    Regards
  • 夜神 岩男 at Dec 29, 2011 at 10:59 am

    On 12/30/2011 12:41 AM, Marc Deop wrote:
    On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
    the hughe difference is: while having the same password (for the key)
    it can not be used directly for brute-force und you need the password
    and at least one time access to the key file
    Explain me how having a key protected by a password avoids brute forcing if you loose the usb stick holding that key?

    Technology is developing at a scary pace, have a look at this:
    http://mytechencounters.wordpress.com/2011/04/03/gpu-password-cracking-crack-a-windows-password-using-a-graphic-card/

    And this is with a simple card, imagine what you can do with a system with multiple paralel cards...


    Just to be clear: I'm not arguing which system is better/more secure. I'm just pointing out one downside of having the key in a usb memory.

    And bruteforcing against ssh servers are really difficult as some others have commented (and even more difficult if you limit failed connections...)
    My IC card fries itself after 10 unsucessful attempts.

    That is one way.

    The military CACs fry themselves after 3.

    They are not just disks, they are tiny 8-bit systems embedded in the
    chip. The key never actually leaves the card. The benefit is that your
    key is never exposed, even in an encrypted state. The downside is that
    signing really huge things can take a few seconds (like ~5 secs for,
    say, signing a decent sized RPM or email attachment, 15 secs or so for
    signing the a kernel RPM) because the card processor, not the host
    system, is doing the signing.

    I don't know about the security of USB dongles. I've never used them
    before, but I'm sure that secured versions of them are much more than
    simple USB drives with a directory full of keys, but rather discrete USB
    devices which probably operate in the same way. I'm speculating, but I
    can't imagine this isn't the case with good USB systems.
  • Marko Vojinovic at Dec 29, 2011 at 11:26 am

    On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
    Am 29.12.2011 14:21, schrieb Marko Vojinovic:
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too
    random to be memorized --- you have to carry it on a usb stick (or
    whereever). This provides an additional point of failure should your
    stick get lost or stolen. Human brain is still by far the most secure
    information-storage device. :-)
    this is bullshit
    most people have their ssh-key on a usb-stick
    And how are you going to access your servers if the stick gets broken or lost?
    I guess you would have to travel back to where the server is hosted, in order
    to copy/recreate the key.

    I did not argue that the key is not more secure than a password. I was just
    pointing out that sometimes it can be more inconvenient.

    Your question was "why discuss to use or not to use the best currently
    availbale method in context of security?", and my answer was "there can be a
    tradeoff between security and convenience". I don't see why do you consider
    this to be bullshit.

    Best, :-)
    Marko
  • Mark Roth at Dec 29, 2011 at 11:33 am

    Marko Vojinovic wrote:
    On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
    Am 29.12.2011 14:21, schrieb Marko Vojinovic:
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too
    random to be memorized --- you have to carry it on a usb stick (or
    whereever). This provides an additional point of failure should your
    stick get lost or stolen. Human brain is still by far the most secure
    information-storage device. :-)
    this is bullshit
    most people have their ssh-key on a usb-stick
    And how are you going to access your servers if the stick gets broken or
    lost? I guess you would have to travel back to where the server is
    hosted, in order to copy/recreate the key.
    Um, yep: you're SOL, same as if you spilled coffee on your laptop, or
    whatever. And if you loose it, you should then create a new one.
    I did not argue that the key is not more secure than a password. I was
    just pointing out that sometimes it can be more inconvenient.
    All security is inconvenient. What's implemented is a balance between
    convenience and security - really secure is a system not connected to any
    network, and with no USB ports, that runs off a DVD....
    <snip>
    mark
  • 夜神 岩男 at Dec 29, 2011 at 11:41 am

    On 12/30/2011 01:33 AM, m.roth at 5-cent.us wrote:
    Marko Vojinovic wrote:
    On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
    Am 29.12.2011 14:21, schrieb Marko Vojinovic:
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too
    random to be memorized --- you have to carry it on a usb stick (or
    whereever). This provides an additional point of failure should your
    stick get lost or stolen. Human brain is still by far the most secure
    information-storage device. :-)
    this is bullshit
    most people have their ssh-key on a usb-stick
    And how are you going to access your servers if the stick gets broken or
    lost? I guess you would have to travel back to where the server is
    hosted, in order to copy/recreate the key.
    Um, yep: you're SOL, same as if you spilled coffee on your laptop, or
    whatever. And if you loose it, you should then create a new one.
    I did not argue that the key is not more secure than a password. I was
    just pointing out that sometimes it can be more inconvenient.
    All security is inconvenient. What's implemented is a balance between
    convenience and security - really secure is a system not connected to any
    network, and with no USB ports, that runs off a DVD....
    ...at the bottom of the ocean...
  • Johnny Hughes at Dec 29, 2011 at 9:02 am

    On 12/29/2011 07:21 AM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    Hello Reindl,
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    Bennett clearly states that he understands the ssh key is more random,
    but wonders why a 12 char password (of roughly 6 bits entropy per byte
    assuming upper & lower case characters and numbers) wouldn't be
    sufficient.
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too random to
    be memorized --- you have to carry it on a usb stick (or whereever). This
    provides an additional point of failure should your stick get lost or stolen.
    Human brain is still by far the most secure information-storage device. :-)

    It is very inconvenient for people who need to login to their servers from
    random remote locations (ie. people who travel a lot or work in hardware-
    controlled environment).

    Besides, it is essentially a question of overkill. If password is not good
    enough, you could argue that the key is also not good enough --- two keys (or
    a larger one) would be more secure. Where do you draw the line?
    This is absolutely ludicrous. Requiring a physical "key" to be present
    for access can not be compared to a 12 character password, random or not.

    Bottom line ... if you want people to crack your server, use passwords
    and they way.

    For the love of God, do not allow password access your machines people.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111229/3dda0694/attachment.bin
  • Peter Eckel at Dec 29, 2011 at 9:05 am
    Hi Marko,
    Using the ssh key can be problematic because it is too long and too random to
    be memorized --- you have to carry it on a usb stick (or whereever). This
    provides an additional point of failure should your stick get lost or stolen.
    this is only correct when you use SSH keys without a sufficiently secure passphrase. Which you obviously should never do. If you have a passphrase with your key, finding or stealing the USB stick is completely useless, and even if someone gets at your key, your no worse off than with password authentication.
    Human brain is still by far the most secure information-storage device. :-)
    I strongly disgree. Social engineering is a very efficient way to get at other people's data.
    It is very inconvenient for people who need to login to their servers from
    random remote locations (ie. people who travel a lot or work in hardware-
    controlled environment). Agreed.
    Besides, it is essentially a question of overkill. If password is not good
    enough, you could argue that the key is also not good enough --- two keys (or
    a larger one) would be more secure. Where do you draw the line?
    One key is indefinitely better than a password. The additional security you gain when you add another key is, however, disputable.

    Best regards,

    Peter.
  • 夜神 岩男 at Dec 29, 2011 at 9:53 am

    On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    Hello Reindl,
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    Bennett clearly states that he understands the ssh key is more random,
    but wonders why a 12 char password (of roughly 6 bits entropy per byte
    assuming upper& lower case characters and numbers) wouldn't be
    sufficient.
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too random to
    be memorized --- you have to carry it on a usb stick (or whereever). This
    provides an additional point of failure should your stick get lost or stolen.
    Human brain is still by far the most secure information-storage device. :-)

    It is very inconvenient for people who need to login to their servers from
    random remote locations (ie. people who travel a lot or work in hardware-
    controlled environment).

    Besides, it is essentially a question of overkill. If password is not good
    enough, you could argue that the key is also not good enough --- two keys (or
    a larger one) would be more secure. Where do you draw the line?

    Best, :-)
    Marko
    Hi Marko!
    What about IC cards? I use that a lot, and its reduced my need for a
    password to something tiny (6 numbers) and requires a physical key (my
    card). I have the root certificates, private keys, etc. stored offline
    just in case my card goes nuts, which has happened before, but I've
    never had a problem with this.

    When traveling I log in to my home server and work servers with my
    laptop. Its really a *lot* easier than using a bunch of pasword schemes.
    I was initially worried that I'd run into a situation where I'd either
    lose my card traveling, or it would get crushed, or whatever -- but that
    hasn't happened in 5 years. What has happened in 5 years of doing this
    is intermittent network outages, work server crashing, web applications
    failing, database corruption, etc.

    So from experience (mine and coworkers, at least), it is a lot more
    likely that problems will arise from totally different vectors than
    having ssh keys and ic cards making life complicated -- because from
    this user's perspective its made things a LOT simpler.

    But it requires a bit of study. Which most people don't do. More to the
    point most people don't even read popups on the screens, even the big
    red scary ones, so...
  • Mark Roth at Dec 29, 2011 at 10:00 am

    ??????????????? wrote:
    On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    <snip>
    It is very inconvenient for people who need to login to their servers
    from random remote locations (ie. people who travel a lot or work in
    hardware-controlled environment).

    Besides, it is essentially a question of overkill. If password is not
    good enough, you could argue that the key is also not good enough ---
    two keys (or a larger one) would be more secure. Where do you draw the
    line?
    <snip>
    When traveling I log in to my home server and work servers with my
    laptop. Its really a *lot* easier than using a bunch of pasword schemes.
    <snip>
    Ah, that brings to mind another issue with only passwords:
    synchronization. I worked as a subcontractor for a *huge* US co a few
    years ago. I've *never* had to write passwords down... but for there, I
    had a page of them! Our group's, the corporate test systems, the corporate
    *production* systems, and *each* had their own, along with their own
    password aging (there was *no* single sign-on), the contracting co's....

    mark
  • 夜神 岩男 at Dec 29, 2011 at 10:35 am

    On 12/30/2011 12:00 AM, m.roth at 5-cent.us wrote:
    ??????????????? wrote:
    On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    <snip>
    It is very inconvenient for people who need to login to their servers
    from random remote locations (ie. people who travel a lot or work in
    hardware-controlled environment).

    Besides, it is essentially a question of overkill. If password is not
    good enough, you could argue that the key is also not good enough ---
    two keys (or a larger one) would be more secure. Where do you draw the
    line?
    <snip>
    When traveling I log in to my home server and work servers with my
    laptop. Its really a *lot* easier than using a bunch of pasword schemes.
    <snip>
    Ah, that brings to mind another issue with only passwords:
    synchronization. I worked as a subcontractor for a *huge* US co a few
    years ago. I've *never* had to write passwords down... but for there, I
    had a page of them! Our group's, the corporate test systems, the corporate
    *production* systems, and *each* had their own, along with their own
    password aging (there was *no* single sign-on), the contracting co's....

    mark
    Ah, forgot about that because its no longer a problem for me anymore.
    Using the same password on two systems is a religiously-to-be-observed
    rule that *most* users violate.

    I can put my public keys on any system and not worry about it. Hitting
    the number pad for my digits is a lot faster than typing in a password,
    a lot more convenient than remembering a bunch of them (and a big
    motivator to buy laptops with full-blown 10-keys, which is common now
    anyway, as are internal card readers...).
  • Mark Roth at Dec 29, 2011 at 10:41 am

    ??????????????? wrote:
    On 12/30/2011 12:00 AM, m.roth at 5-cent.us wrote:
    ????????????????????????????????? wrote:
    On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    <snip>
    When traveling I log in to my home server and work servers with my
    laptop. Its really a *lot* easier than using a bunch of pasword
    schemes.
    <snip>
    Ah, that brings to mind another issue with only passwords:
    synchronization. I worked as a subcontractor for a *huge* US co a few
    years ago. I've *never* had to write passwords down... but for there, I
    had a page of them! Our group's, the corporate test systems, the
    corporate *production* systems, and *each* had their own, along with
    their own password aging (there was *no* single sign-on), the
    contracting co's....
    Ah, forgot about that because its no longer a problem for me anymore.
    Using the same password on two systems is a religiously-to-be-observed
    rule that *most* users violate.
    <snip>
    Yeah, but this was *corporate*: systems I had no access to other than as a
    user, with very limited sudo. I was *appalled* that they didn't have
    single sign-on.

    mark
  • Cliff Pratt at Dec 29, 2011 at 11:07 pm

    On Fri, Dec 30, 2011 at 4:00 AM, wrote:
    ??????????????? wrote:
    On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    <snip>
    It is very inconvenient for people who need to login to their servers
    from random remote locations (ie. people who travel a lot or work in
    hardware-controlled environment).

    Besides, it is essentially a question of overkill. If password is not
    good enough, you could argue that the key is also not good enough ---
    two keys (or a larger one) would be more secure. Where do you draw the
    line?
    <snip>
    When traveling I log in to my home server and work servers with my
    laptop. Its really a *lot* easier than using a bunch of pasword schemes.
    <snip>
    Ah, that brings to mind another issue with only passwords:
    synchronization. I worked as a subcontractor for a *huge* US co a few
    years ago. I've *never* had to write passwords down... but for there, I
    had a page of them! Our group's, the corporate test systems, the corporate
    *production* systems, and *each* had their own, along with their own
    password aging (there was *no* single sign-on), the contracting co's....
    We use PasswordSafe to solve that one. There are other similar products.

    Cheers,

    Cliff
  • Ljubomir Ljubojevic at Dec 29, 2011 at 12:33 pm

    On 12/29/2011 03:53 PM, ????? wrote:
    On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
    On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
    Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
    Hello Reindl,
    On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
    Am 29.12.2011 09:17, schrieb Bennett Haselton:
    Even though the ssh key is more
    random, they're both sufficiently random that it would take at least
    hundreds of years to get in by trial and error.
    if you really think your 12-chars password is as secure
    as a ssh-key protcected with this password you should
    consider to take some education in security
    Bennett clearly states that he understands the ssh key is more random,
    but wonders why a 12 char password (of roughly 6 bits entropy per byte
    assuming upper& lower case characters and numbers) wouldn't be
    sufficient.
    so explain me why discuss to use or not to use the best
    currently availbale method in context of security?
    Using the ssh key can be problematic because it is too long and too random to
    be memorized --- you have to carry it on a usb stick (or whereever). This
    provides an additional point of failure should your stick get lost or stolen.
    Human brain is still by far the most secure information-storage device. :-)

    It is very inconvenient for people who need to login to their servers from
    random remote locations (ie. people who travel a lot or work in hardware-
    controlled environment).

    Besides, it is essentially a question of overkill. If password is not good
    enough, you could argue that the key is also not good enough --- two keys (or
    a larger one) would be more secure. Where do you draw the line?

    Best, :-)
    Marko
    Hi Marko!
    What about IC cards? I use that a lot, and its reduced my need for a
    password to something tiny (6 numbers) and requires a physical key (my
    card). I have the root certificates, private keys, etc. stored offline
    just in case my card goes nuts, which has happened before, but I've
    never had a problem with this.

    When traveling I log in to my home server and work servers with my
    laptop. Its really a *lot* easier than using a bunch of pasword schemes.
    I was initially worried that I'd run into a situation where I'd either
    lose my card traveling, or it would get crushed, or whatever -- but that
    hasn't happened in 5 years. What has happened in 5 years of doing this
    is intermittent network outages, work server crashing, web applications
    failing, database corruption, etc.

    So from experience (mine and coworkers, at least), it is a lot more
    likely that problems will arise from totally different vectors than
    having ssh keys and ic cards making life complicated -- because from
    this user's perspective its made things a LOT simpler.

    But it requires a bit of study. Which most people don't do. More to the
    point most people don't even read popups on the screens, even the big
    red scary ones, so...
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    I like to use serial numbers from MB, HDD, etc., as passwords. I never
    use normal words for my passwords, and few other users (with ssh/cli
    access) are carefully checked for their passwords.

    If this formula is true "(1/2 . 2 ^ 54 . 1s / 10)" for 9 *random*
    character password, then 0.5 * 18014398509481984 /10 gives
    900719925474099 seconds to crack it, or 10424999137 days per attacker.

    If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that
    never attacked any denyhosts or fail2ban server in recent time.

    So for army of 10,000 attacker PC's, bruteforce ssh needs 1042499 days,
    or 2856 years to crack it. Is this correct figure?

    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Mark Roth at Dec 29, 2011 at 12:45 pm
    Ljubomir Ljubojevic wrote:
    <snip>
    I like to use serial numbers from MB, HDD, etc., as passwords. I never
    The one problem with this is that *if* the attacker has the slightest idea
    of the hardware, their task is vastly smaller. I trust, for example, that
    you don't use Dell's s/n/"express code"; Penguin, not having sold 5
    gazillion servers, has the first few digits all the same, for years
    (they're being optimistic with s/n's that long).
    <snip>
    mark
  • Ljubomir Ljubojevic at Dec 29, 2011 at 1:18 pm

    On 12/29/2011 06:45 PM, m.roth at 5-cent.us wrote:
    Ljubomir Ljubojevic wrote:
    <snip>
    I like to use serial numbers from MB, HDD, etc., as passwords. I never
    The one problem with this is that *if* the attacker has the slightest idea
    of the hardware, their task is vastly smaller. I trust, for example, that
    you don't use Dell's s/n/"express code"; Penguin, not having sold 5
    gazillion servers, has the first few digits all the same, for years
    (they're being optimistic with s/n's that long).
    <snip>
    mark

    No. I got the idea from my first second-hand MB for NOC router/firewall,
    while I was on the grain silo needing to reinstall ClarkConnect on it
    (don't ask :-D ). You can use s/n from some old PC you have at your
    home, or discarded MB (or whatever).

    Of course, using s/n's would be same as using some good random-generator
    script.


    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • 夜神 岩男 at Dec 30, 2011 at 5:40 am

    On 12/30/2011 02:33 AM, Ljubomir Ljubojevic wrote:
    I like to use serial numbers from MB, HDD, etc., as passwords. I never
    use normal words for my passwords, and few other users (with ssh/cli
    access) are carefully checked for their passwords.

    If this formula is true "(1/2 . 2 ^ 54 . 1s / 10)" for 9 *random*
    character password, then 0.5 * 18014398509481984 /10 gives
    900719925474099 seconds to crack it, or 10424999137 days per attacker.

    If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that
    never attacked any denyhosts or fail2ban server in recent time.

    So for army of 10,000 attacker PC's, bruteforce ssh needs 1042499 days,
    or 2856 years to crack it. Is this correct figure?
    Unfortunately, no, it is not a correct number.

    There are a few situational variables that have to be considered to
    really assess the security of a password, and theoretical best-case
    entropy is only a small part of that.

    If, for example, you login remotely using a password that has to cross
    an untrusted network you should expect that it is being sniffed. Now
    this is less a problem because it should be encrypted. The situation is
    the same for local Windows or Linux logins -- all systems I know of
    encrypt passowords for storage by default, which isn't much different
    than how simple password encryption works across the network.

    There is a problem with this, however. The password, however long, is
    reduced to a fixed-length hash in most password encryption schemes.
    Because of the wonders of modulo mathematics the total set of possible
    hashes is a lot less than the total set of possible passwords. What this
    means is we can start attacking the algorithm itself, in preparation for
    trying to decrypt intercepted data (of any type that falls under a
    signature/hash type scheme, not just passwords).

    We can start a 10,000 computer botnet (or, more realistically, a 10m
    computer botnet these days, and this is a technique used right now)
    working on the problem of assembling a new index table that orders and
    assigns every possible valid hash said algorithm can produce, and start
    assigning values.

    Essentially, we can move the computing cost up-front by assuming that we
    indeed *do* have to try *every* possible password, which means computing
    done 5 years ago applies to your brand new password today.

    Something weird about the way encryption algorithms tend to work is that
    as you move through the list of possible hashes you find large spans of
    values that are impossible to actually arrive at given the set of data a
    user can enter. You can move those to the side, and this massively
    redudces the work load (but its something you can't discover until
    you're well into building the hash index, which might be a year or so).

    You can also start with targeted hash indexing, meaning you first run
    through every possible dictionary word, then every variant of, then
    every possible combination of, then every possible combination with l33t
    substitutions, then any data set that you can scan from external sources
    (meaning things people might see and decide to use as a password that
    isn't in the dictionary, which is the category your S/N scheme falls
    into...), all of the above with numeric insertions (4, 2 and scattered
    single digits are most common, so focus on those), names of companies,
    etc. Going this route you can can about 99% of average user passwords in
    about a month. This is how John the Ripper works, in a nutshell -- it
    has a hash index of pre-checked phrases in a myriad of different hashing
    schemes and just checks the hashed password against the index to locate
    the list of possible correct ones, which is a pretty short list.

    Anyway, to keep from getting into too much math, just consider that
    password cracking is not only based on entropy of the password, and the
    concept of passwords encrypted for transit or storage has been around
    long enough that has tables exist for a vast number of common algorithms.

    If you are only logging on locally *and* you are nearly certain that
    nobody has access to your password storage, then you're just fine. Most
    users who don't spend time using IE to surf unsavory websites and click
    on everything those websites has to offer are safe from this. People who
    log in remotely, however, face a different challenge. People who login
    to a web interface using a password have a SERIOUS problem, in my
    opinion, because HTTP cannot be secured, and some websites (even banks!)
    sometimes don't have a public HTTPS, but force the user to use a
    HTTP->HTTPS redirect, which makes securing it literally impossible.

    Blah blah. I'm glossing over some details here and there are as many
    different cracking scenarios which involve their own weaknesses as there
    are systems.

    In short, keys, man, keys. Its not perfect, but it is much stronger than
    passwords and in my experience FAR much less hassle.

    -Iwao
  • Marko Vojinovic at Dec 30, 2011 at 11:19 am
    On Friday 30 December 2011 19:40:55 ????? wrote:
    [snip]
    We can start a 10,000 computer botnet (or, more realistically, a 10m
    computer botnet these days, and this is a technique used right now)
    working on the problem of assembling a new index table that orders and
    assigns every possible valid hash said algorithm can produce, and start
    assigning values.

    Essentially, we can move the computing cost up-front by assuming that we
    indeed *do* have to try *every* possible password, which means computing
    done 5 years ago applies to your brand new password today. [snip]
    In short, keys, man, keys. Its not perfect, but it is much stronger than
    passwords and in my experience FAR much less hassle.
    You are basically saying that, given enough resources, you can precalculate
    all hashes for all possible passwords in advance.

    Can the same be said for keys? Given enough resources, you could precalculate
    all possible public/private key combinations, right?

    Please don't get me wrong --- I'm not saying that the resources needed are
    equal (or even comparable) for the two cases.

    But theoretically, both keys and passwords rely on the assumption that the
    "inverse operation" (be it calculating a password from a hash or factoring a
    large integer into primes) is too expensive to be feasible. But "given enough
    time and resources", you could in principle have prebuilt tables for both,
    right?

    Just asking... :-) ...while waiting for the first successful build of a quantum
    computer, which will fundamentally redefine all current concepts of security...
    ;-)

    Best, :-)
    Marko
  • Lamar Owen at Dec 30, 2011 at 11:51 am

    On Friday, December 30, 2011 11:19:46 AM Marko Vojinovic wrote:
    You are basically saying that, given enough resources, you can precalculate
    all hashes for all possible passwords in advance.
    Can the same be said for keys? Given enough resources, you could precalculate
    all possible public/private key combinations, right?
    Public key crypto's security is based on the cost of factoring and finding large prime numbers; hashing is somewhat different and relies on 'one-way' functions that are very difficult to reverse. There are similarities and some sharing between the algorithms, but the difficulty of reversal is based on different mathematical properties.

    However, at least for some hashes on some OS's, precalculation of partial hashes is no theory; lookup 'Rainbow Tables' some day. (see https://en.wikipedia.org/wiki/Rainbow_tables )
  • 夜神 岩男 at Dec 30, 2011 at 12:07 pm

    On 12/31/2011 01:19 AM, Marko Vojinovic wrote:
    On Friday 30 December 2011 19:40:55 ????? wrote:
    [snip]
    We can start a 10,000 computer botnet (or, more realistically, a 10m
    computer botnet these days, and this is a technique used right now)
    working on the problem of assembling a new index table that orders and
    assigns every possible valid hash said algorithm can produce, and start
    assigning values.

    Essentially, we can move the computing cost up-front by assuming that we
    indeed *do* have to try *every* possible password, which means computing
    done 5 years ago applies to your brand new password today. [snip]
    In short, keys, man, keys. Its not perfect, but it is much stronger than
    passwords and in my experience FAR much less hassle.
    You are basically saying that, given enough resources, you can precalculate
    all hashes for all possible passwords in advance.

    Can the same be said for keys? Given enough resources, you could precalculate
    all possible public/private key combinations, right?

    Please don't get me wrong --- I'm not saying that the resources needed are
    equal (or even comparable) for the two cases.

    But theoretically, both keys and passwords rely on the assumption that the
    "inverse operation" (be it calculating a password from a hash or factoring a
    large integer into primes) is too expensive to be feasible. But "given enough
    time and resources", you could in principle have prebuilt tables for both,
    right?

    Just asking... :-) ...while waiting for the first successful build of a quantum
    computer, which will fundamentally redefine all current concepts of security...
    ;-)
    Yes, theoretically it is possible to precalculate the hashes of
    everything against everything. Seriously. Of course, the only groups
    with the current resources to actually build hash indexes against
    serious keys are governments, and there are limits there even.

    The cost is what prevents this, which is why cryptographic security can
    never, ever sit still.

    And you're right about quantum computing changing the game. In fact, it
    can change the game so much that physical and information security will
    once again become one and the same, period [1].

    Considering this and how close we are to quantum computing, I find the
    "rush to the cloud" for business and personal data storage laugably
    shortsighted.

    -Iwao

    1.Ok, there is actually a way around this which relies on quantum
    hashing, but I don't know the terms for this in English. It depends on
    the idea that you can only observe some articles of data a single time
    before the act of observation forces an alteration of state: In other
    words it does nothing to encrypt the data, but rather you can know 100%
    if the data has been intercepted at all. But its ridiculously finnicky
    right now because its so new, so don't expect this for a long time.
  • Alex Milojkovic at Dec 31, 2011 at 12:02 am
    I think the best password policy is the one you've never told anyone and never posted on a public mailing list.

    How many of you out there know of cases where administrators' passwords were compromised by brute force?
    Can we take a count of that?

    I believe in passwords. I don't believe in PKI.
    It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it.
    PKI is convenience and if your password is 20-30 characters it will take long time to break it.

    Password crack estimator
    http://www.mandylionlabs.com/documents/BFTCalc.xls

    Spreadsheet is safe (take my word for it) ha,ha

    Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.


    -Alex

    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of ?? ??
    Sent: Friday, December 30, 2011 9:07 AM
    To: centos at centos.org
    Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
    On 12/31/2011 01:19 AM, Marko Vojinovic wrote:

    On Friday 30 December 2011 19:40:55 ????? wrote:
    [snip]
    We can start a 10,000 computer botnet (or, more realistically, a 10m
    computer botnet these days, and this is a technique used right now)
    working on the problem of assembling a new index table that orders
    and assigns every possible valid hash said algorithm can produce, and
    start assigning values.

    Essentially, we can move the computing cost up-front by assuming that
    we indeed *do* have to try *every* possible password, which means
    computing done 5 years ago applies to your brand new password today. [snip]
    In short, keys, man, keys. Its not perfect, but it is much stronger
    than passwords and in my experience FAR much less hassle.
    You are basically saying that, given enough resources, you can
    precalculate all hashes for all possible passwords in advance.

    Can the same be said for keys? Given enough resources, you could
    precalculate all possible public/private key combinations, right?

    Please don't get me wrong --- I'm not saying that the resources needed
    are equal (or even comparable) for the two cases.

    But theoretically, both keys and passwords rely on the assumption that
    the "inverse operation" (be it calculating a password from a hash or
    factoring a large integer into primes) is too expensive to be
    feasible. But "given enough time and resources", you could in
    principle have prebuilt tables for both, right?

    Just asking... :-) ...while waiting for the first successful build of
    a quantum computer, which will fundamentally redefine all current concepts of security...
    ;-)
    Yes, theoretically it is possible to precalculate the hashes of everything against everything. Seriously. Of course, the only groups with the current resources to actually build hash indexes against serious keys are governments, and there are limits there even.

    The cost is what prevents this, which is why cryptographic security can never, ever sit still.

    And you're right about quantum computing changing the game. In fact, it can change the game so much that physical and information security will once again become one and the same, period [1].

    Considering this and how close we are to quantum computing, I find the "rush to the cloud" for business and personal data storage laugably shortsighted.

    -Iwao

    1.Ok, there is actually a way around this which relies on quantum hashing, but I don't know the terms for this in English. It depends on the idea that you can only observe some articles of data a single time before the act of observation forces an alteration of state: In other words it does nothing to encrypt the data, but rather you can know 100% if the data has been intercepted at all. But its ridiculously finnicky right now because its so new, so don't expect this for a long time.
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • John R Pierce at Dec 31, 2011 at 1:43 am

    On 12/30/11 9:02 PM, Alex Milojkovic wrote:
    I believe in passwords. I don't believe in PKI.
    It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it.
    you're supposed to password protect your PKI keystore.

    --
    john r pierce N 37, W 122
    santa cruz ca mid-left coast
  • Drew at Dec 31, 2011 at 8:43 am
    It's been an interesting if somewhat heated discussion. Figures the
    fun ones come up when I'm away. ;)

    The discussion of using Certs(PKI) vs Passwords to secure SSH seem to
    be missing an important piece of the puzzle, and that to my mind is
    attack vectors & target value.

    The argument I saw against PKI is that's it's no more secure then
    regular passwords because your certificates are password protected
    anyways and stored on external media so they can be stolen and used to
    access the system.

    Like the OP I run a web server (two in my case) and I have external
    SSH access for certain reasons. I've got things like fail2ban
    installed, various logwatch type software running to alert me to any
    abnormal entries. I also have cert based access to my machine.

    In my case, the primary attack vector for hackers getting at my
    servers is via the web. Because I host primarily personal websites on
    my servers, the hackers motivation for breaking into my server (aside
    from 'it's there') is to turn the machine into a bot-net or host some
    viagra phishing sites on it.

    The concern, for me, is more about remote compromise then about
    physical theft of my usb token. A russian hacker who want's another
    compromised machine for his bot-net or phishing ring is probably not
    going to go to the effort of physically flying over here from Europe
    and spend the time needed to track me down, break into my office, and
    steal my usb token. He's more likely to move onto another target one
    of his script-kiddies found for him.



    --
    Drew

    "Nothing in life is to be feared. It is only to be understood."
    --Marie Curie
  • Timothy Murphy at Dec 31, 2011 at 8:59 am

    Drew wrote:

    In my case, the primary attack vector for hackers getting at my
    servers is via the web. Because I host primarily personal websites on
    my servers, the hackers motivation for breaking into my server (aside
    from 'it's there') is to turn the machine into a bot-net or host some
    viagra phishing sites on it.
    I'm in much the same situation,
    and would like to protect myself to a minimal extent.
    But I don't understand how a usb token (below) would help.

    I'm probably showing my ignorance.
    (The only protection I take is to run fail2ban.)
    The concern, for me, is more about remote compromise then about
    physical theft of my usb token. A russian hacker who want's another
    compromised machine for his bot-net or phishing ring is probably not
    going to go to the effort of physically flying over here from Europe
    and spend the time needed to track me down, break into my office, and
    steal my usb token. He's more likely to move onto another target one
    of his script-kiddies found for him.
    --
    Timothy Murphy
    e-mail: gayleard /at/ eircom.net
    tel: +353-86-2336090, +353-1-2842366
    s-mail: School of Mathematics, Trinity College Dublin
  • Drew at Dec 31, 2011 at 9:49 am

    I'm in much the same situation,
    and would like to protect myself to a minimal extent.
    But I don't understand how a usb token (below) would help.
    The 'token' in this case (a standard usb thumbdrive) is merely a
    portable container for my ssh certificates and a copy of putty (when
    I'm on a windows box). You don't need it if you never move around.
    What matters is the use of the certificate.

    Token may have been the incorrect word as RSA's keyfobs are sometime
    called tokens.

    --
    Drew

    "Nothing in life is to be feared. It is only to be understood."
    --Marie Curie
  • Stephen Harris at Dec 31, 2011 at 9:40 am

    On Sat, Dec 31, 2011 at 05:43:54AM -0800, Drew wrote:
    The argument I saw against PKI is that's it's no more secure then
    regular passwords because your certificates are password protected
    anyways and stored on external media so they can be stolen and used to
    access the system.
    Typical security is based around three things:
    1. Something you know (eg password)
    2. Something you have (eg physical token, USB key, ssh private key)
    3. Something you are (eg fingerprint)

    Passwords are "1 factor"; it's just a password. RSA SecurID tokens
    are "2 factor"; you need the number on the token and the PIN. The more
    factors you have, typically the stronger the protection. (Assuming proper
    implementation, of course!)

    In the same way, public key authentication is 2 factor (in the SSH
    implementation, anyway) because you need the private key and the
    passphrase to the key. (historically, passphrases were longer than
    8 character passwords but that's not so true on many systems, today)

    Why is this more secure? Because a gazillion people can brute force
    attack a box protected by passwords, however only people who have
    physical access to the token (#2) can attack my box. By stealing the
    token they've reduced my protection to single factor. BUT, and this is
    an important but, they _have to steal it first_.

    SSH keys are weaker than RSA tokens because an SSH key can be duplicated
    without the owners knowledge; if you steal my RSA key then I'll know!
    But you still need to duplicate it, and that makes it stronger than
    password auth.

    --

    rgds
    Stephen
  • Alex Milojkovic at Dec 31, 2011 at 2:57 pm
    The good thing about PKI is that it takes longer to break.
    The bad thing about PKI is many admins keep many private keys in the same
    spot.
    So you figure out one password, many doors are open.

    --Alex


    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf
    Of Stephen Harris
    Sent: Saturday, December 31, 2011 6:41 AM
    To: CentOS mailing list
    Subject: Re: [CentOS] what percent of time are there unpatched exploits
    against default config?
    On Sat, Dec 31, 2011 at 05:43:54AM -0800, Drew wrote:
    The argument I saw against PKI is that's it's no more secure then
    regular passwords because your certificates are password protected
    anyways and stored on external media so they can be stolen and used to
    access the system.
    Typical security is based around three things:
    1. Something you know (eg password)
    2. Something you have (eg physical token, USB key, ssh private key)
    3. Something you are (eg fingerprint)

    Passwords are "1 factor"; it's just a password. RSA SecurID tokens are "2
    factor"; you need the number on the token and the PIN. The more factors you
    have, typically the stronger the protection. (Assuming proper
    implementation, of course!)

    In the same way, public key authentication is 2 factor (in the SSH
    implementation, anyway) because you need the private key and the passphrase
    to the key. (historically, passphrases were longer than
    8 character passwords but that's not so true on many systems, today)

    Why is this more secure? Because a gazillion people can brute force attack
    a box protected by passwords, however only people who have physical access
    to the token (#2) can attack my box. By stealing the token they've reduced
    my protection to single factor. BUT, and this is an important but, they
    _have to steal it first_.

    SSH keys are weaker than RSA tokens because an SSH key can be duplicated
    without the owners knowledge; if you steal my RSA key then I'll know!
    But you still need to duplicate it, and that makes it stronger than password
    auth.

    --

    rgds
    Stephen
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Johnny Hughes at Dec 31, 2011 at 9:13 am

    On 12/30/2011 11:02 PM, Alex Milojkovic wrote:
    I think the best password policy is the one you've never told anyone and never posted on a public mailing list.

    How many of you out there know of cases where administrators' passwords were compromised by brute force?
    Can we take a count of that?
    I know of plenty ... people contact security at centos.org all the time
    after having their machines compromised by brute force.

    Here are a couple of articles for you to read:

    http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Processing-Units-GPUs-Password-Security-System

    http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crack-your-password-in-under-a-second/
    I believe in passwords. I don't believe in PKI.
    It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it.
    PKI is convenience and if your password is 20-30 characters it will take long time to break it.

    Password crack estimator
    http://www.mandylionlabs.com/documents/BFTCalc.xls

    Spreadsheet is safe (take my word for it) ha,ha

    Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
    You don't need a botnet of 1000 PCs ... you only need a couple of
    graphics cards.

    -Alex

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111231/3b870cb9/attachment.bin
  • Leonard den Ottolander at Dec 31, 2011 at 10:21 am
    Hello Johnny,
    On Sat, 2011-12-31 at 08:13 -0600, Johnny Hughes wrote:
    Here are a couple of articles for you to read:

    http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Processing-Units-GPUs-Password-Security-System

    http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crack-your-password-in-under-a-second/
    You don't need a botnet of 1000 PCs ... you only need a couple of
    graphics cards.
    Please enlighten me how this has any bearing on remotely brute forcing
    an SSH login? The number of passwords tried is limited by the daemon,
    not the amount of processing power the attacker has available.

    The examples you provide require the attacker to have access to the hash
    table, f.e. /etc/shadow, which supposedly is not the case if they
    haven't been able to login to your system yet.

    Regards,
    Leonard.

    --
    mount -t life -o ro /dev/dna /genetic/research
  • Ljubomir Ljubojevic at Dec 31, 2011 at 11:58 am

    On 12/31/2011 03:13 PM, Johnny Hughes wrote:
    On 12/30/2011 11:02 PM, Alex Milojkovic wrote:
    I think the best password policy is the one you've never told anyone and never posted on a public mailing list.

    How many of you out there know of cases where administrators' passwords were compromised by brute force?
    Can we take a count of that?
    I know of plenty ... people contact security at centos.org all the time
    after having their machines compromised by brute force.

    Here are a couple of articles for you to read:

    http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Processing-Units-GPUs-Password-Security-System

    http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crack-your-password-in-under-a-second/
    I believe in passwords. I don't believe in PKI.
    It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it.
    PKI is convenience and if your password is 20-30 characters it will take long time to break it.

    Password crack estimator
    http://www.mandylionlabs.com/documents/BFTCalc.xls

    Spreadsheet is safe (take my word for it) ha,ha

    Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
    You don't need a botnet of 1000 PCs ... you only need a couple of
    graphics cards.
    Can you please explain how this is possible by attacking linux via ssh
    brute force. I fail to see it. If attacks are throttled via ssh config
    and fail2ban/danyhosts, how does their GPU power comes into equation?


    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Leonard den Ottolander at Dec 31, 2011 at 12:26 pm
    Hello Johnny,
    These articles fail to clarify even the most basic of assumptions they
    make. I can only guess the numbers relate to the cracking of MD5 hashes
    (salted or unsalted?) and access to the /etc/shadow file.

    On CentOS-6 password hashes are no longer stored as MD5, but as SHA-512
    hashes. Apparently the SHA hashing algorithms as used by Red Hat have a
    configurable iterator count much like bcrypt
    ( http://en.wikipedia.org/wiki/Crypt_%28Unix%29 "SHA2-based scheme").

    Also, the only way for an attacker to have access to /etc/shadow is to
    already have root access to your system in which case you are already
    faqed.

    Imo the weakness of MD5 hashes is more of a concern for web applications
    where an attacker might gain access to (part of) your database via f.e.
    SQL injection. This is why a proper web application will use a bcrypt
    hash to store passwords. As the amount of iterations bcrypt uses is
    configurable the algorithm can scale with increasing processing power.

    Regards,
    Leonard.

    --
    mount -t life -o ro /dev/dna /genetic/research
  • Les Mikesell at Dec 31, 2011 at 12:57 pm

    On Sat, Dec 31, 2011 at 8:13 AM, Johnny Hughes wrote:

    Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
    You don't need a botnet of 1000 PCs ... you only need a couple of
    graphics cards.
    If you have a stolen passphrase-protected ssh private key, is it
    possible to brute-force the passphrase directly, or can success only
    be determined by checking against a copy of the public key?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Alex Milojkovic at Dec 31, 2011 at 2:50 pm
    Thanks Johnny,
    Yes if you have console access to the server and can plug in the GPU and/or have access to the password file.

    Ok let me rephrase myself.
    How many people have had their passwords cracked on Internet servers by means available to them?
    In other words gained root access by way of a TCP service.

    These articles are based on theoretical math and scenarios that are not common.
    They are saying one billion passwords per second
    How many servers can handle a million requests per second without DOS, I'd like to have one :)

    But the reality is that most passwords are taken through flaws in the software run as root or by weak password and obvious user names.

    Everything else is more or less social engineering in my opinion and shouldn't focus on passwords. In that case no authentication mechanism will be enough, we are just fooling ourselves.
    If someone can gain physical access to your server you've got other problems, not password problems.
    It's not the fault of the developer /password mechanism.
    One weakness in Unix is that root account. Everyone knows it's there and everyone's trying it.
    When will it be possible to set your own admin username, that'd be nice.
    In Windows you can rename Administrator which helps.

    Internet is still an infant.
    Hopefully sometime soon, perimeter routers will be like border checkpoints.
    I like you, you get in.
    I don't like you, you stay out.
    IP address allocation needs to be done smarter so that geographical regions can be isolated easier. And at some point it probably will be.
    Internet has facilitated the biggest financial/intellectual losses during such a short time of its existence.
    I believe that needs to change.

    Good discussion

    --Alex





    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Johnny Hughes
    Sent: Saturday, December 31, 2011 6:14 AM
    To: centos at centos.org
    Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
    On 12/30/2011 11:02 PM, Alex Milojkovic wrote:
    I think the best password policy is the one you've never told anyone and never posted on a public mailing list.

    How many of you out there know of cases where administrators' passwords were compromised by brute force?
    Can we take a count of that?
    I know of plenty ... people contact security at centos.org all the time after having their machines compromised by brute force.

    Here are a couple of articles for you to read:

    http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Processing-Units-GPUs-Password-Security-System

    http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crack-your-password-in-under-a-second/
    I believe in passwords. I don't believe in PKI.
    It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it.
    PKI is convenience and if your password is 20-30 characters it will take long time to break it.

    Password crack estimator
    http://www.mandylionlabs.com/documents/BFTCalc.xls

    Spreadsheet is safe (take my word for it) ha,ha

    Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
    You don't need a botnet of 1000 PCs ... you only need a couple of graphics cards.

    -Alex
  • Les Mikesell at Dec 31, 2011 at 3:32 pm

    On Sat, Dec 31, 2011 at 1:50 PM, Alex Milojkovic wrote:

    Ok let me rephrase myself.
    How many people have had their passwords cracked on Internet servers by means available to them?
    In other words gained root access by way of a TCP service.
    Someone cracked my gmail password and sent what seemed like an oddly
    small amount of spam from it.
    These articles are based on theoretical math and scenarios that are not common.
    They are saying one billion passwords per second
    How many servers can handle a million requests per second without DOS, I'd like to have one :)
    If you have a server with port 22 open to the internet you can get an
    idea of what is going on by looking at your logs. Unless you are a
    high-profile site you probably won't see millions of attempts, but you
    will see dozens or hundreds a day, coming from many different sources.
    They seem to be at least loosely coordinated and are probably
    spreading the attempts widely. If your machine happens to be the one
    where they get a match from the random probabilities, it likely gets
    added into the set doing more attempts.
    Everything else is more or less social engineering in my opinion and shouldn't focus on passwords. In that case no authentication mechanism will be enough, we are just fooling ourselves.
    Targeted cracking may involve social engineering, but I'd bet that
    much, much more of the random hacking involves software
    vulnerabilities, both before and after they are published. Again, if
    you look at the logs of what hits port 80 you'll see the probes for
    things that might permit arbitrary code execution. Unless one of
    those succeeds, you won't see the followup - but if it does, the
    attacker will then attempt to execute local 'root escalation'
    vulnerabilities like the one fixed not too long ago in glibc that let
    anyone who could create a symlink become root.
    Hopefully sometime soon, perimeter routers will be like border checkpoints.
    I like you, you get in.
    I don't like you, you stay out.
    That doesn't work for web services open to the public. You need
    firewalls that can work at wire speed filtering the inbound URLs for
    known attack patterns, plus of course, updating the software as
    quickly as possible to fix the vulnerabilities.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Timothy Murphy at Dec 31, 2011 at 5:45 pm

    Les Mikesell wrote:

    Someone cracked my gmail password and sent what seemed like an oddly
    small amount of spam from it.
    gmail and hotmail must be very easy to crack,
    or is there some check apart from the password?
    That doesn't work for web services open to the public. You need
    firewalls that can work at wire speed filtering the inbound URLs for
    known attack patterns, plus of course, updating the software as
    quickly as possible to fix the vulnerabilities.
    Yes, I'm more worried about attacks through port 80.
    Can anyone point me to documentation on protecting a web-server?


    --
    Timothy Murphy
    e-mail: gayleard /at/ eircom.net
    tel: +353-86-2336090, +353-1-2842366
    s-mail: School of Mathematics, Trinity College Dublin

Related Discussions

People

Translate

site design / logo © 2022 Grokbase