Re: an actual hacked machine, in a preserved state

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



On 1/3/2012 12:31 PM, Pete Travis wrote:
> On Jan 3, 2012 12:36 PM, "Ljubomir Ljubojevic"<office@xxxxxxxx>  wrote:
>> On 01/03/2012 04:47 PM, m.roth@xxxxxxxxx wrote:
>>> Having been on vacation, I'm coming in very late in this....
>>>
>>> Les Mikesell wrote:
>>>> On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton<bennett@xxxxxxxxxxxxx>
>>>> wrote:
>>> <snip>
>>>>> OK but those are *users* who have their own passwords that they have
>>>>> chosen, presumably.  User-chosen passwords cannot be assumed to be
>>>>> secure against a brute-force attack.  What I'm saying is that if
> you're
>>>>> the only user, by my reasoning you don't need fail2ban if you just
> use a
>>>>> 12-character truly random password.
>>>> But you aren't exactly an authority when you are still guessing about
>>>> the cause of your problem, are you?  (And haven't mentioned what your
>>>> logs said about failed attempts leading up to the break in...).
>>> Further, that's a ridiculous assumption. Without fail2ban, or something
>>> like it, they'll keep trying. You, instead, Bennett, are presumably
>>> generating that "truly random" password[1] and assigning it to all your
>>> users[2], and not allowing them to change their passwords, and you will
> be
>>> changing it occasionally and informing them of the change.[3]
>>>
>>> Right?
>>>
>>>           mark
>>>
>>> 1. How will you generate "truly random"? Clicks on a Geiger counter?
> There
>>> is no such thing as a random number generator.
>>> 2. Which, being "truly random", they will write down somewhere, or store
>>> it on a key, labelling the file "mypassword" or some such.
>>> 3. How will you notify them of their new password - in plain text?
>> Bennet was/is the only one using those systems, and only as root. No
>> additional users existed prior to breach. And he is very persisting in
>> placing his own opinion/belief above those he asks for help. That is why
>> we have such a long long long thread. It came to the point where I am
>> starting to believe him being a troll. Not sure yet, but it is getting
>> there.
>>
>> I am writing this for your sake, not his. I decided to just watch from
>> no on. This thread WAS very informative, I did lear A LOT, but enough is
>> enough, and I spent far to much time reading this thread.
>>
>>
>> --
>>
>> 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
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
> I'm subscribed to this list just because of threads like this.  I want to
> thank you all for exposing me to knowledge and discussion that reveals far
> more than manpages or readmes - it helps a lot to know where to start
> reading, and about what.
>
> I am not a statistician,  but I feel an observation should be made on the
> idea of an 'unguessable password.'  A 12 character string may have 12^42
> possible permutations,

I'm not sure where you got the 12^42 figure from.  My assumption was 
that each character has about 64 = 2^6 possible values, so there are 
2^72  possible passwords, which is on the order of 10^24.

> but you are assuming that the correct guess will be
> the last possible guess.

Actually I was using the fact that the average time to break the 
password would be the time required to check half of the possible 
passwords, not that they won't find it until the last possible one.  
That's still on the order of 10^24.

> Simplistic probability puts the odds of success
> at 50% - either the attacker gets it right, or they don't.

I can't make sense of this statement at all.  Just because there are two 
possible outcomes doesn't mean that each possibility is equally likely 
-- you might as well that either the sun comes up tomorrow, or it 
doesn't, so the odds of success are 50% :)  The only time the "50%" 
figure comes up is that the average time to guess a password is the time 
taken to check half of all possible passwords, and hence is 50% of the 
worst-case time to guess a password (which would be the time taken to 
check all of them).

> An intelligent
> brute forcing tool could be making some assumptions about the minimum
> length and complexity of your password, and ruling out the dictionary words
> and strings based on them happens quickly.  The next guess has the same
> rough odds of being correct as the 100563674th guess.

Actually, each time you make a guess and it's wrong, the probability of 
success goes up slightly for your next guess.  Imagine having 10 cups 
with a ball under one of them.  The probability of turning over the 
right cup on the first try is 1/10.  If you're wrong, though, then the 
probability of getting it right on the next cup goes up to 1/9, and so on.

But it's all a moot point if there are 10^24 possible passwords and the 
odds of finding the right one in any conceivable length of time are 
essentially zero.

> Of course, no amount of guessing will succeed on a system that doesn't
> accept passwords.   System security, in terms of probability, seems to be
> an 'every little bit helps' sort of endeavour.

Well it depends on how literally you mean "every little bit" :)  If the 
chance of a break-in occurring in the next year from a given attack is 1 
in 10^10, you can reduce it to 1 in 10^20, but it's already less likely 
than your data center being hit by a meteorite.  The real problem is 
that it takes away from time that can be used for things that have a 
greater likelihood of reducing the chance of a break-in.  If I had taken 
the advice about ssh keys at the beginning of the thread, I never would 
have gotten to the suggestion about SELinux.

Bennett
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux