[CentOS] what percent of time are there unpatched exploits against default config?

Sat Dec 31 05:02:17 UTC 2011
Alex Milojkovic <centos at businessforce.ca>

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