Forgot your password?
typodupeerror

Comment: Re:Derp (Score 1) 163

by bluefoxlucid (#47499923) Attached to: New Mayhem Malware Targets Linux and UNIX-Like Servers

your characterizing Windows as "retarded" for not distinguishing between 750 char/s and the much faster network, was illogical.

There are two parts to that.

The first part is that the network log-in source can be grouped as an infinite number of terminals--lots of connections--so a per-connection rate limit is useless; thus all network service log-in (caveat: Active Directory handles console log-ins... over network) must be grouped as one thing to be effective. Console log-ins are separate so that a network attack can't function as a DOS; as well, the risk is mitigated because you can't enter passwords fast enough for any use.

The second part is that a console brute-force is slow. Your concern about what amounts to typing really, really fast (i.e. programmed HID plugged into USB) isn't a real concern because of password complexity. It's not that passwords are necessarily that complex; it's that a password which isn't complex enough can be readily brute forced under strong password policies like "3 passwords per minute", it just takes a week or two.

You dismiss the possibility that weak passwords are used, so that hardware password attacks are dismissable, but at the same time address the problem that these same non-weak passwords aren't strong enough to withstand network password attacks without lock-outs?

No, I dismiss the possibility that short lock-out intervals help with weak passwords.

You can attack 129,600 passwords per 30 days if you have a 3 failure per minute policy. Basic English 1250 extends out to about 5000 words with conjugations and domain language (medical, legal, whatever) for most people. Weak passwords in the traditional complexity scheme are like "rainman" becomes "Rainman1", so 100,000 attempts has a fair chance of getting it eventually. That's within the realm of a hardware keyboard typist. Common policy is 60 or 90 day retention, which increases the risk into strong viability; while public kiosks are too visible for a multi-hour console log-in attack, which makes these attacks less viable even at high rates.

Complex passwords reach 10^14 theoretically, and four-word passwords reach 10^16. Reasonable rate limits of 20 attempts per minute carry this out to hundreds of thousands of years. A human can type barely that fast. Remember the original argument:

Windows does stupid shit like lock the local console if you set up rate-limit log-in...when logging in through the Microsoft log-in manager.

If the attacker tries to log in over RDP or telnet or such, and locks the account, the actual console log-in box no longer works. That's dumb, because no attacker can possibly brute force the password through that, unless the password is laughably weak--in which case, as stated above, the rate limiting doesn't actually help.

tl;dr: I can lock you out of your server by constantly trying to log into your server, so you can't apply patches anymore. Then I hack it on Tuesday.

Comment: Re:Derp (Score 1) 163

by bluefoxlucid (#47485661) Attached to: New Mayhem Malware Targets Linux and UNIX-Like Servers

BTW, the person who coined "movie plot security threat" doesn't exactly agree with you [schneier.com].

That's for keyloggers, not key entry. Typing is different than reading.

Where did this "750 characters per second" come from? Is this a limit built into Windows? USB 2.0 runs at 35 MB/s, according to Wikipedia.

There's this link that references USB-HID specifically at 750 characters per second. I can't find other references to USB HID rates, and the HID protocol is semi-flexible (i.e. it's really fucking hard to implement NKRO on HID, since HID keyboard protocol specifies 6KRO in boot mode; but you're free to implement an alternate HID protocol once your keyboard's out of boot mode).

OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole

1-2 second delay is an expected human-facing turn-around: this actually happens on most modern systems. I pointed it out and then theorized eliminating that rate limit entirely, instead relying on the limits of the HID keyboard protocol at 750 characters per second, which is the faster measurement and thus can be taken as a worst case.

Your naivety about the average entropy in a typical 8 character password is striking.

We're talking about theoretical password complexity here, not dictionary attacks. If you only have 5000 or so passwords to try, a rate limit of 5 seconds to enter each will give you a maximum time of less than half a day. That's a rate of 12 per minute. Even at 3 per minute, it takes barely over a day; weak passwords are quite weak.

I also consider the full entropy of an 8 character password as a weak measurement. My typical recommendation is all lower case, with the space or underscore, and minimum 16 characters. This is to enforce a 4 dictionary word standard (passwords like "red_ant_room_lake" illustrate why so short), although you could say 20 characters and all full dictionary words, minimum 4 (which means 5 words sometimes!). The entropy is much higher even with small vocabularies.

In other words: I used conservative numbers. Real world numbers FOR A HARDWARE PASSWORD BRUTE FORCE DEVICE will involve longer time frames (log-in subsystem delays), higher-entropy passwords, and so on. I also made a final comment about console scripts and the complexity they add--because they're vastly faster than hardware HID brute force devices.

Because hardware brute force devices are not useful--not faster than a human in any reasonable case and, even then, not fast enough to actually crack anything--your proposed attack is a movie plot.

Comment: Re:it is the wrong way... (Score 1) 286

by bluefoxlucid (#47484937) Attached to: Australia Repeals Carbon Tax

Capitalism works, but not as just "let the market handle everything." I'm working on transitional plans for a new economic strategy that makes capitalism actually work (permanently); I already have the end state, and also have proven that it works both in the end state and in transition. There is risk due to variation--an improper transition can actually not work--so I need to work out that kind of stuff and set up a full end-to-end plan that follows a path that works.

Fortunately, changing an economic system is a simple project. It works like any other project, and you can rely on all the stuff normal projects are bound by. For example: All the risks in transition fall away as you pass them. For example: I have to spin social security, food stamps, and HUD down. I also want to eliminate unemployment *and* minimum wage; these carry less risk.

Unemployment carries approximately zero risk: nobody on unemployment will come out receiving *less* income, so you can just cut it off. Likewise, repealing minimum wage carries little risk: I'm transitioning from a strategy of avoidance to a strategy of transfer and mitigation, and the risks of low wage are largely shifted onto the employers rather than the employees. These are easy.

Social security can't be cut off immediately: people rely on planned finances, and will face an economic situation they can't compensate for if faced with a significant reduction in income. To handle this, I have to avoid the risk: Social security is grandfathered for 15 years; anyone who isn't of retirement age in 15 years isn't getting social security. That actually carries a risk of high tax, but it's 6.8% (social security is currently 12.4%; I'm reducing OASDI to 6.8% immediately, but still providing the full benefit until everyone who starts collecting before a time 15 years in the future dies). That risk stays around for probably 30-40 years, but scales down after 15. Risk strategy: avoid.

HUD not so easy: the housing subsidy is less predictable, and will invoke market forces. Food stamps, EBT, WIC, same deal. These require complex transitions, and *any* transitions put people at-risk. The design requirements here explicitly require not putting people at-risk, but also require not raising taxes. Grandfathering is an immediate avoidance strategy: the additional tax burden for HUD is under $50 billion, about 1/10 of social security. Food security around twice that.

As people leave the grandfathered systems, risk decreases. HUD is small, and quick: the turn-over in WIC, EBT, and the food stamp program is bigger than Social Security, so it'll fall off in 5-10 years. Likewise, the tax burden from Social Security rapidly decreases after 15 years. HUD falls somewhere in the middle, and carries a long tail: working-age people are supported by HUD and come in and out, but some of the young ones will *never* exit until they die; thus there will be a short period of rapid cost decrease, followed by a very slow decline.

See? It's all temporary risks; and, as you pass the risks, you gain more flexibility to handle further risks. Just have to minimize the risks, move the easy ones up-front so they can be culled quickly, then manage and control the remaining risks as they shrink slowly.

I'm pretty sure I could get this started, technically (not politically), in under a year. At that point, immediately, taxes are *slightly* lower; give it another 1-3 years and nobody goes homeless or hungry in America ever again.

Comment: Re:Derp (Score 1) 163

by bluefoxlucid (#47484661) Attached to: New Mayhem Malware Targets Linux and UNIX-Like Servers

That's called a movie plot security threat, and it's not a concern.

Aside from all the obvious shit like "how do you get in there unnoticed?" and "How does it know to start entering passwords?", you have the speed of the bus. Even without a 1-2 second turn-around for testing a password, keyboards can only enter 750 characters per second. That's less than 100 password attempts per second for 8 character passwords, or 10^12 seconds to try them all. 800,000 years!

In other words: console attack via keyboard is no threat. I proscribed accounting per-tty direct console attempts separately because of shell scripts (on the console), which might lock you out of sudo in x11, so you open a new xterm and get pts/17 and sudo there. Of course that creates other oddness (users can create terminals, i.e. screen, xterm), which needs addressing.

Comment: Re:it is the wrong way... (Score 1) 286

by bluefoxlucid (#47481995) Attached to: Australia Repeals Carbon Tax

Pretty much yeah. Capitalism works; but it's the same as people saying God will give them virgin 13 year old girls to fuck when they get to heaven for murdering gay people. The fact that you have a name for a very weak ideal doesn't mean you actually understand the ideal that's referenced by the name.

Religious people should read their holy texts once in a while. Economic people should read about economics once in a while, too.

Comment: Still old-school (Score 3, Insightful) 163

by bluefoxlucid (#47481931) Attached to: New Mayhem Malware Targets Linux and UNIX-Like Servers

I was going to release an RFC several years back that detailed malware communications protocols, but it was out-of-scope for an RFC and I figured it would be bad when people started using it. Plus IETF might not take that as an April 1 RFC.

I had suggested that the malware be modular, and that it have a communications protocol using PKI, and an evolutionary module loading framework. It would take code for modules shipped across the network and try to compile them locally for various systems, then ship the binaries around. It would also divide when it got a new module: a kill module would just kill the weak strain. The proposal included detecting remote OS and shipping the correct primary executable code, as well as support code for cross-infection.

The whole thing was a big argument for why we need a non-executable stack and strict rules preventing in-memory transitions between non-executable and executable pages. Data written in memory should never become code. Of course, people want to use JIT compilers, so...

Modern malware still bores me.

Comment: Re:Derp (Score 2) 163

by bluefoxlucid (#47481887) Attached to: New Mayhem Malware Targets Linux and UNIX-Like Servers

If the attacker gains access to any kind of database of password hashes, he can just compute thousands of attempts per second.

Likewise, log-in rate limiting is problematic. Windows does stupid shit like lock the local console if you set up rate-limit log-in...when logging in through the Microsoft log-in manager. That's retarded. A person is sitting at that console, and can't enter passwords fast enough; it should NEVER BE LOCKED. By contrast, any network log-in (RDP, FTP, ssh, etc.) should lock for 60 seconds after 20 failed attempts in 60 seconds, not counting console log-ins.

This does pose an additional small problem: if your system is compromised by malware, a no-local-login-locking policy will allow infinite, concurrent, constant log-ins. If you rate limit it to 20 per 60 seconds, the malware can prevent local users from logging in. If the malware has a local user's access but has locked out the administrator, the admin can't log in and remove the malware; you now need to power cycle what may be a production server.

You can get around this somewhat by attaching the log-in rate limit to the terminal. That means you need rules that decide context (network, local); then, for some contexts (local), account per terminal (tty1, tty2, pts/0, etc.).

Nobody's done that yet.

Comment: Re:Dumb dumb dumb advice... (Score 1) 278

I use a password manager for the bad practice of high password complexity. Passwords like 'mj%9F!17' that should have never been created because they're crap, and impossible to remember.

For my important stuff--like my password safe password--I use passwords like "crazy_dutch_flying_candybar". It really doesn't make a difference if you use underscores, spaces, or concatenation; just use the same always so you never have to remember how you formatted it. Most systems accept underscores, and concatenation is confounding due to the mental impulse to add a space.

You can also make up numerics and memorize them with Dominic's System, but this greatly reduces entropy. For example, if you used 1477 and came up with "jesus_christ_chasing_girls" (because 14--AD, Anno Domino, The Year of our Lord, Jesus Christ--and 77--GG, Girls Girls, Yakko Warner, chasing girls all the damn time), anyone who has your Dominic's matrix can come up with a few thousand likely passwords. Even with some interpretation, there are 100 names and 100 activities describable in a handful of sensible ways, so maybe 100 x 500, give or take.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (1) Gee, I wish we hadn't backed down on 'noalias'.

Working...