Re: Have I been hacked?
On Sat, Jan 10, 2015 at 12:24 PM, scott <redhowlingwolves@gmx.com> wrote:
> On 01/09/2015 09:19 PM, Jerry Stuckle wrote:
>> On 1/9/2015 8:49 PM, Joel Rees wrote:
>>> On Fri, Jan 9, 2015 at 6:25 PM, Martin Steigerwald <Martin@lichtvoll.de> wrote:
>>>> Am Freitag, 9. Januar 2015, 00:24:06 schrieb Brian:
>>>>> On Thu 08 Jan 2015 at 22:36:46 +0100, Martin Steigerwald wrote:
>>>>>> Am Donnerstag, 8. Januar 2015, 14:20:27 schrieb Jerry Stuckle:
>>>>>>> Just ensure you're using good security practices - don't allow root
>>>>>>> login, use long, random passwords, etc. I also use a random character
>>>>>>> strings for the login ids, as well as passwords - just one more thing
>>>>>>> for the hackers to have to figure out how to get around.
>>>>>>
>>>>>> Only allow SSH key based logins. Of course, only after you copied a public
>>>>>> key onto the machine with ssh-copy-id.
>>>>>>
>>>>>> And have SSH keys with *strong* passphrases, to protect against someone
>>>>>> stealing your key. Use ssh-agent wisely only on trusted machines.
>>>>>
>>>>> SSH password logins are just as safe. 20 characters gives a strong
>>>>> password for use on trusted machines. There is no need to worry about
>>>>> it being stolen because it is in your memory,
>>>>
>>>> I think SSH keys are safer, cause there is no password at all that can be
>>>> brute forced.
>>>
>>> What do you mean by that?
>>>
>>>> Okay, one can try to guess the key, but try that with a 4096 bit
>>>> key.
>>>
>>> Hmm.
>>>
>>> 10 characters, 6 to 7 bits per character, that's 60 bits.
>>>
>>> If the bits are truly random, straight brute-force will take, on
>>> average, half of 2^60 attempts.
>>>million
>>> We can hold the integer 2^59 in a C variable on most recent desktops,
>>> but if we have bc (dc if you like post-fix), we can do this on even 32
>>> bit CPUs:
>>>
>>> 576460752303423488 (base ten)
>>>
>>> At one milion attempts per second, that's 5764607523034 seconds, or
>>> 182678 CPU-years.
>>>
>>> There's no way that's going to happen on-line, if the password is
>>> truly random, and not randomly a password that's a quick permutation
>>> of common memes or of entries in rainbow tables.
>>>
>>
>> Actually, 62 possible characters (upper case, lower case and digits), 10
>> positions is 62^10 or 839,299,365,868,340,224 possible combinations.
>>
>> Adding in special characters obviously would increase that.
>>
>> But there is no way you'll hit a server 1,000,000 times a second trying
>> to brute force a password.
>>
>>
>>> I currently use sixteen or more letters in my passwords, don't use
>>> simple permutations or common phrases (as for the first leter trick),
>>> use disconnected words from multiple languages. Or use 16 character
>>> true random passwords for the important stuff.
>>>
>>
>> All good suggestions.
>>
>>> SSH keys are useful, but you have to keep them somewhere. The real
>>> danger to good passwords is the off-line attempts, and the passphrase
>>> you use for your private keystore is potentially subject to off-line
>>> if your password is.
>>>
>>
>> Yes, keys may actually be less secure than passwords.
>>
>> Jerrymillion
>>
>>
> If you have a dedicated hacker, or hackers, time is on their side.
What are your assumptions?
Even the NSA doesn't have the CPUs to brute force, from the network, a
password like y3z!6G@dA9}f2lP.. That's going to require a mean of
something like (95^15)/2 attempts. (Since Jerry points out that I
might as well count the members of the set to make the math clear,
since I've got bc fired up.) That's 10 followed by 28 zeros. At a
(network impossible) billion attempts a second, that's a mean time to
discovery of about 10^13 years, which is, what? roughly 2.5 thousand
times the current best hypothesis of the age of the solar sytem.
Off-line attacks can currently achieve in the range of a million
guesses a second, and the guesses can be split between as many CPUs as
you have. That's why a ten character password of only latin
upper/lower case and numbers is within reach of the NSA.
Also, passwords/passphrases/SSH keys like !-L0U{.t@4loR/$w|f+ are dead
meat, whether you like Taylor Swift or not, because they are
permutations of common memes, and that's subject to strategy attacks.
>I
> would much rather use a key with a passphrase.
What you do when you use an SSH key is introduce two stages of authentication.
The one that occurs on the net uses huge keys that really do put the
odds so far beyond the known lifetime of the universe as to make it
practically resistant to brute force. It is also generated by
arbitrary, statistically well-distributed processes, to make it very
resistant to analysis. So, as long as there are no vulnerabilities,
that stage can be relied on.
The other stage occurs on your computer, where you have means to
control access andOn Sat, Jan 10, 2015 at 12:24 PM, scott
<redhowlingwolves@gmx.com> wrote:
> On 01/09/2015 09:19 PM, Jerry Stuckle wrote:
>> On 1/9/2015 8:49 PM, Joel Rees wrote:
>>> On Fri, Jan 9, 2015 at 6:25 PM, Martin Steigerwald <Martin@lichtvoll.de> wrote:
>>>> Am Freitag, 9. Januar 2015, 00:24:06 schrieb Brian:
>>>>> On Thu 08 Jan 2015 at 22:36:46 +0100, Martin Steigerwald wrote:
>>>>>> Am Donnerstag, 8. Januar 2015, 14:20:27 schrieb Jerry Stuckle:
>>>>>>> Just ensure you're using good security practices - don't allow root
>>>>>>> login, use long, random passwords, etc. I also use a random character
>>>>>>> strings for the login ids, as well as passwords - just one more thing
>>>>>>> for the hackers to have to figure out how to get around.
>>>>>>
>>>>>> Only allow SSH key based logins. Of course, only after you copied a public
>>>>>> key onto the machine with ssh-copy-id.
>>>>>>
>>>>>> And have SSH keys with *strong* passphrases, to protect against someone
>>>>>> stealing your key. Use ssh-agent wisely only on trusted machines.
>>>>>
>>>>> SSH password logins are just as safe. 20 characters gives a strong
>>>>> password for use on trusted machines. There is no need to worry about
>>>>> it being stolen because it is in your memory,
>>>>
>>>> I think SSH keys are safer, cause there is no password at all that can be
>>>> brute forced.
>>>
>>> What do you mean by that?
>>>
>>>> Okay, one can try to guess the key, but try that with a 4096 bit
>>>> key.
>>>
>>> Hmm.
>>>
>>> 10 characters, 6 to 7 bits per character, that's 60 bits.
>>>
>>> If the bits are truly random, straight brute-force will take, on
>>> average, half of 2^60 attempts.
>>>million
>>> We can hold the integer 2^59 in a C variable on most recent desktops,
>>> but if we have bc (dc if you like post-fix), we can do this on even 32
>>> bit CPUs:
>>>
>>> 576460752303423488 (base ten)
>>>
>>> At one milion attempts per second, that's 5764607523034 seconds, or
>>> 182678 CPU-years.
>>>
>>> There's no way that's going to happen on-line, if the password is
>>> truly random, and not randomly a password that's a quick permutation
>>> of common memes or of entries in rainbow tables.
>>>
>>
>> Actually, 62 possible characters (upper case, lower case and digits), 10
>> positions is 62^10 or 839,299,365,868,340,224 possible combinations.
>>
>> Adding in special characters obviously would increase that.
>>
>> But there is no way you'll hit a server 1,000,000 times a second trying
>> to brute force a password.
>>
>>
>>> I currently use sixteen or more letters in my passwords, don't use
>>> simple permutations or common phrases (as for the first leter trick),
>>> use disconnected words from multiple languages. Or use 16 character
>>> true random passwords for the important stuff.
>>>
>>
>> All good suggestions.
>>
>>> SSH keys are useful, but you have to keep them somewhere. The real
>>> danger to good passwords is the off-line attempts, and the passphrase
>>> you use for your private keystore is potentially subject to off-line
>>> if your password is.
>>>
>>
>> Yes, keys may actually be less secure than passwords.
>>
>> Jerrymillion
>>
>>
> If you have a dedicated hacker, or hackers, time is on their side.
What are your assumptions?
Even the NSA doesn't have the CPUs to brute force, from the network, a
password like y3z!6G@dA9}f2lP.. That's going to require a mean of
something like (95^15)/2 attempts. (Since Jerry points out that I
might as well count the members of the set to make the math clear,
since I've got bc fired up.) That's 10 followed by 28 zeros. At a
(network impossible) billion attempts a second, that's a mean time to
discovery of about 10^13 years, which is, what? roughly 2.5 thousand
times the current best hypothesis of the age of the solar sytem.
Off-line attacks can currently achieve in the range of a million
guesses a second, and the guesses can be split between as many CPUs as
you have. That's why a ten character password of only latin
upper/lower case and numbers is within reach of the NSA.
Also, passwords/passphrases/SSH keys like !-L0U{.t@4loR/$w|f+ are dead
meat, whether you like Taylor Swift or not, because they are
permutations of common memes, and that's subject to strategy attacks.
>I
> would much rather use a key with a passphrase.
What you do when you use an SSH key is introduce two stages of authentication.
The one that occurs on the net uses huge keys that really do put the
odds so far beyond the known lifetime of the universe as to make it
practically resistant to brute force. It is also generated by
arbitrary, statistically well-distributed processes, to make it very
resistant to analysis. So, as long as there are no vulnerabilities,
that stage can be relied on.
The other stage oc observation attempts.
And there is the benefit of having a structured keystore to help your
memory and keep the key theoretically safe.
But if you use an old protocol that has become subject to analysis or
other attack, you aren't safe.
And if you aren't careful with your keystore, you aren't safe. The
keystore is in your own directories, where a process ostensibly owned
by you can see it, particularly if it guesses your SSH key, to decrypt
it.. This is part of the reason you shouldn't bank from the account
you surf from.
So the convenience of the structured keystore has it's down sides, too.
A password, once it is used, may be left in cache, but it may quickly
be washed from cache, too. If you aren't using a password manager, the
password need not remain on your machine long at all, particularly if
apps wipe their own memories before quitting and the OS clears cache
that has been freed.
Various trade-offs. and a strong password can be good enough.
I use both, for different situations.
However, one-time passwords, if implemented correctly, are the
strongest approach.
--
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.
Reply to: