It's not hard to find a Win7 laptop, the caveat is that you generally have to buy a system with Win7 Pro on it (slightly more expensive) and you won't find bottom of the barrel laptops with it.
But for a work laptop, which makes you money, that expense is minor.
(For our road warriors, we are still paying $2.0k to $2.5k for laptops with 4-5 year warranties, maxed out RAM, SSDs, spare PSUs, docking stations, software, and other goodies. My current laptop is of similar cost, purchased in 2007 with WinXP, and now running Win7. I don't plan on retiring it until 2015 or 2016, unless something goes horribly wrong with it. All of our laptops are lasting 5+ years these days.)
Finally, this is a nearly 40 inch display. They look ridiculous as a computer monitor and the ergonomics suck.
We used to say the same about 24-27" monitors.
I have (4) 22-27" displays on my desk arranged in a 2x2 array, which measures almost 45-48" diagonally. Being able to replace that with a single 40" display would be rather nice. Granted, they might need to curve it a bit for it to be properly ergonomic for desktop use. (Hidden advantage of the 2x2 array of monitors is that I can turn each one inward a bit to be properly aligned for my field of vision).
A 32" 4K display would be just about perfect for replacing the right-half of my monitor array.
The other trick you learn with multiple displays arranged in a 2x2 array is that you put less important information in the upper screens.
For office equipment (routers, firewalls, root passwords, super user passwords, etc.) we have setup (3+) people with GPG keys. They have both an electronic copy of their GPG key along with a paper copy in a sealed envelope stored in a safe-deposit box. At least one of those people has no clue what a GPG key is, but he's the CEO so he is our last-ditch backup key holder.
We then store all passwords in GPG-encrypted text files (ASCII armored text blocks), stuffed into our version control system. Whenever I change an account password, I encrypt those details using the 3+ keys of the people who need to know in case of my untimely demise. Any of those 3+ people can get access to the data. The VCS just makes it easier to distribute the latest copies of the text files.
Yes, we could probably do a "three-man rule" setup with GPG, but for now it's good enough that any of the 3+ people can access the contents of those files.
Plus with GPG ASCII armored text blocks, you can print them, email them, fax them, or whatever without worrying about compromising security of the contents. Worst case, you have some temp employee type the ASCII text block back into a text editor so that you can decrypt it.
Frankly, the passwords that do not matter (do not give access to finances or other *really important* stuff) -- letting the browser remember them (protected with a master password) is fine. Or use one of the "lastpass" or "keypass" style solutions. In fact, for 99% of websites that I visit, the password is just random jibberish (15-25 random alphanumeric characters). I don't care if I can't remember it, because various software solutions do that for me.
For the more secure stuff, GPG encrypted ASCII blocks stored in text files is the best approach. You can encrypt a particular account's information with multiple GPG keys to allow multiple people to unlock it. The ASCII blocks are easily emailed around and can be printed to *paper* and stored in a file cabinet / fire safe / safe deposit box as a worst-case backup plan. We actually store our ASCII text files in a version control system, which simplifies things.
Naturally, with the GPG or any other software approach, it is only as strong as your pass phrase that protects the content. And just like passwords, it is vulnerabile to key logging software/hardware.
MOO2 was a far better game then MOO1. The big issues with it was that late-game tech made the galaxy distances meaningless, late-game battles were tedious, and the AI was rudimentary and easy to trick/defeat. Combat, however, was far more balanced in MOO2 over MOO1 and you didn't have to build stacks of 65k ships in order to win.
CIV4 was mostly an improvement over CIV3, but CIV5 goofed it up because the developers threw out all of the lessons of Civ3 and Civ4. Hexes were a great idea. Limiting the stacks of doom was a great idea. 1UPT (one unit per tile) combined with hexes that were 2x-3x too large for that purpose was garbage and resulted in constant micro-management in order to keep your forces from tripping over their own feet.
Only "weakly encrypted" PINs. How do you "encrypt" a four-decimal-digit PIN?
The same way that you protect any other plain text of nearly any length at all. You generate an encryption key (56bit DES, 112bit 3DES, 128bit AES or 256bit AES) and encrypt the plain text with that key.
The only way to get the plain text back is to brute-force the key (assuming that the algorithm is well designed, properly implemented, and that the key can't be leaked in some other fashion).
Here is an example for you: Please figure out what PIN I used in the following output from an AES-128 encryption:
2c 5b 22 99 53 42 5b cc 4d bf a7 88 3b 61 95 14
Oh, and you only get 10 guesses before the card is flagged as stolen.
Hashing relies on salt for security. Encryption does not.
Passwords are hashed instead of encrypted because you want to make it near impossible to reverse the process and discover the original password. In fact, you hash, because you are simply not interested in being able to reverse the process. You then use custom salt along with the hash step to make pre-generated rainbow attack tables useless. And to prevent the breaking of one account to instantly grant access to all other accounts that happen to have the same password, you salt each account with a unique salt.
Encryption, OTOH, is designed to be reversed. The only thing protecting your plain-text is the encryption key. In the case of symmetrical encryption, this is usually a 56bit (DES) or 112bit (3DES) or 128/256bit (AES) key. Adding salt to the process gains you nothing in terms of actual security.
I don't understand why any one would use encryption here at all. Why would they not use challenge/response, so that the PIN never leaves the card/keypad (encrypted or not).
Because parts of the system are still asynchronous. There is not real-time communication in a lot of parts of the banking system. And it was much worse 10-15 years ago when a lot of these systems were designed.
Decrypting them should be trivial, given the limited number of possible pin numbers, even if the table was salted.
Don't confuse hashing of PINs with encryption of PINs.
If the PINs were stored / sniffed in a hashed form where the hash algorithm is known *and* the salt is known, then yes it is trivial to figure out what PIN number appears in each record.
OTOH, if the PINs are encrypted and the key is not known by the attackers, then the attackers have to break that key. Which might be 56 bit or it might be 112 bits or it might be as large as 128 or 256 bits. Assuming that the encryption algorithm is not vulnerable to a plain-text attack, the attackers are left with having to brute-force the encryption key.
Which is not an easy task, even for 56bit keys. Especially with such a short plain-text of only 4 digits. There may be multiple keys that result in something that looks like 4 digits, but it could be the wrong 4 digits. Longer plain-text are easier to validate. So if the entire table was encrypted with a single key, it becomes easier to say that you have found the right key.
On the flip side, documenting the configuration of a system that *only* has a GUI interface for accessing that configuration is a masochistic art form.
If it is text based or (shudder) XML based configuration files, then you can easily stuff the file into any version control system and easily see the differences between what you started with and what you are now running with.
For server administration, documenting what you did to configure the system is a very big deal. Text based configuration files make that a trivial issue with no fancy tools required.
Yeah, you are simply an uninformed idiot if you believe what you wrote.
Server motherboards can be purchased in standard sizes, or custom sizes depending on your needs. Some of the cost difference is licensing for the SAS/SCSI chips, the rest of the difference between a server board and a "gaming" motherboard is the quality of the discrete components. You get capacitors that will last 10-15 years, not cheap crappy ones that might blow out in less then 5 years. You get boards capable of dual or quad processors. You get KVM over IPMI and other "lights out" features that let you power-cycle a system or get into the BIOS settings remotely.
With a consumer level board, you'll be lucky if it still works in 5 years. OTOH, you can buy more and keep spares on the shelf, but you still run the risk of parts with lower quality control causing tolerances to drive out of bounds.
ECC RAM has been readily available from most stores for close to a decade now. It is no longer a special-order part and in any system over a few GB of RAM, you should strongly consider using it if the motherboard (and CPU) supports it. Heck, it's now barely a 5% or 10% cost increase over non-ECC RAM. The big advantage is that you don't get bitten by flipped bits, which get more and more common as feature size shrinks.
As for hard drives, if you are not using drives with TLER in a RAID, then you are an idiot. The TLER makes sure that the drive reports failures in a timely manner so that your entire RAID array doesn't grind to a halt for 10-30 seconds. As soon as you get over 6-8 drives in the array, this really starts to matter (you can get away with it in smaller arrays).
And remember, if you can't afford new furniture every year, you can't afford a cat (you should see how shredded my 5 year old couch is).
The trick with scratching posts is that they need to be on the natural travel path. For instance, the one at the entrance to my home office gets heavy use, because in order for my cat to come visit, she passes right by it. As a result, she prefers that over scratching the furniture. Plus she always gets petted after using it because it gets my attention.
It also helps that it is a full 36" tall, so she can stretch out a bit while using it. Most of the scratching posts are well under 24" tall and nearly useless in the vertical position.
(Other keys are to use the type of material that your cat likes, plus figuring out whether they want a horizontal surface or a vertical surface to scratch.)
It may be okay because the tunnel is encrypted with SSL or SSH -- but is still not best-design. Better designs never send the password, or even the password has over the wire.
At which point, you no longer have to care whether or not the tunnel is encrypted.
It's not like North Korea's populace will know any better.
The leaks in that information dam have already started. Cross-border trade with China is leaking information in, which is why you hear a lot more the past few years about crackdowns on those caught listening to western media.
SSD is down to about 2x-3x the cost of 15k RPM SAS drives. Which is pretty competitive for situations where you needed the speed of 15k RPM SAS and are short-stroking the drives to get even more speed out of spinning rust.
- Avoid the 5000 most commonly used English (or your language's) words.
- Odd capitalization helps, as long as you can remember it
- Misspellings are a good idea
- L33T speak ("0" in place of "o") is basically worthless
- Tacking together 2-4 less commonly used words, mixed in with numbers/symbols still works moderately well. Figure 16 or 17 bits per word, plus 4-5 bits per symbol/number, plus 0.5 bits for every change in case.
- Pure random is difficult, unless you have KeyPass or store passwords in some other encrypted system.
- Getting above at least 45 bits is currently a decent goal, but you'll need to be up to 50 bits of strength within the next 10 years.
- 16-20 digit random alphanumeric passwords with random capitalization are around 96-120 bits.
- Anything 8 digits or less can be cracked in under a day by even a modestly funded attacker ($1000 of hardware)
On Linux, we use a minimum length of 15 and it has to pass cracklib compexlity rules. On the Windows domain, minimum length of 14 plus complexity requirements. We recommend something that is 16-20 characters long. (Our Linux servers, however are moderately more secure, because you can't SSH to them without a public-key pair.)
my understanding was that the reason a lot of Chinese (and Koreans for that matter) are still using XP is because the online banks have written their websites to Internet Explorer 6 and have no intention of ever changing that. There's some sort of crypto module that they're using which is an ActiveX control and completely incompatible with anything else.
That article from last month was about South Korea banks, who have specifically targeted ActiveX and IE6.
Not saying that China banks didn't do something equally as dumb...
We're switching over to putting the VMs on top of enterprise SSDs for just that reason. Even 15k SAS drives don't have the IOPS to deal with the demands of lots of small VMs that all assume they are running on dedicated hardware.
Price difference between enterprise SSD and 15k SAS drives is about 2.0-2.5x $/GB. So it's more expensive, but not an order-of-magnitude more expensive. And the gap keeps narrowing.
A safe rule of thumb that I've used over the years is to only allocate 99% of the drive size when putting together the array. This is a bit easier with Software RAID and mdadm under Linux.
You might even be safe at 99.5% or 99.9%, but the latter is probably a bit risky.
The other thing to look for in enterprise SSDs is the user of "super-caps" (large capacitors), these provide enough charge that the SSD can power down gracefully if the power is cut. Such as flushing any buffers, making sure the sector mapping table is updated, or whatever other metadata they need to track.
SSDs have their uses, but they're nowhere near cheap enough to replace systems with massive amounts of storage or that rely on RAID.
They're getting really close for primary storage and being used in RAID arrays..
300GB 15k RPM SAS is about $180-$200. An Intel DC S3500 Series SSD (300GB) is around $390. So the price difference of the SSD vs the spinning rust is only about 2x now. And you will probably gain 25x IOPS over that spinning rust.
Bulk storage using 7200 RPM drives is still the domain of spinning rust and will be for a while.
Let's take your example, assuming Alphanumeric (26+26+10 = 62, roughly 6 bits) and padding characters (30 possible on most keyboards, or 5 bits).
Let's assume an attacker knows your pattern:
Each alphanumeric is worth 6 bits at best. Knowing which symbol you used to pad with is only worth 5 bits. Figuring out whether to pad with 0, 1 or 2 symbols between each letter is only 2 bits per letter.
So you get 5 bits for the padding symbol, plus 8 bits per letter (6 bits for the actual alphanumeric plus 2 bits for 0-3 padding symbols between each letter). In your trivial example this totals up to: 5 + (3*8) = 29 bits. Something with length 8 is 5 + (8*8) or 69 bits. Actually a bit less because you're unlikely to remember that your padding was 3 characters after this letter, 2 after this other letter, 3 after this letter and 1 after that letter.
And that's if we brute-force it in a smart way. If we go even smarter, we'll use a word list of the 10k most common english words and do "leet" or "hacker" character substitution (0 for o, 4 for a, 3 for e, etc).
For pure brute-force, assuming only easily typed letters, each position is worth around 6.6 bits (97 or so different possible characters). 8*6.6 = 52.8 bits for any password of 8 total characters or less. That's around 7841 trillion possibles. With modern GPUs that can guess at least 1 billion per second (depending on the hash it may be as high as 15-20B/s for $1000), that 7841 trillion is only 13 weeks at 1 billion/sec. If it's a trivial hash that can be done at the rate of 13B/sec, that time falls to 1 week for any password of 8 characters or less.
And that is only if you are willing to use 97 possibles for every single character in the password, including hard to type things like "$_|-@+=>". Since that's difficult, it's probably more like 70 possibles per position for something that humans can remember. That's only 6.1 bits per position (68.5) or 490 trillion or a factor of 16x easier. So that means 5.6 days for a 1 billion/sec hash tester and only 10 hours at 13 billion/sec testing.
All of which is a very long-winded way of saying passwords of 8 characters or less (roughly 48 bits) are screwed if the attacker has $1000 and gets a copy of your hash for offline cracking.
By forcing a minimum length of 12, you've made the brute-force attack about 22 million times harder. So they either need to spend 22 million times more money or wait 22 million times longer. Naturally, as you get into the longer passwords, dictionary attacks become the preferred route so unless you are doing completely random password generation of 12+ characters, you're not gaining as much as you think. Maybe as little as 4 bits per additional character (4*12 is only 48 bits).
Things don't start getting safe(-ish) these days until you get up into the 15+ character range. Even at the worst case of only 4 bits per character of entropy, that's 60 bits (about 1.1e+18) or 1900 weeks per password at 1B/sec guesses.
They may know 45k words (and there are roughly 300k English Dictionary words), but the number of commonly used words is far less. Estimates that I've seen over the years say that the commonly used English words is around 5k to 10k.
So unless the user has a very large vocabulary and the good sense to stay away from those 5k-10k most frequently used words, you can get a long way into cracking passwords by sticking to those frequently used words.
No one talks about Suse because we are off talking about more exciting things. That is the problem with having a stable sensible distribution that actually works.... Its doesn't have the latest $sexy to ignite peoples fires, or the latest $sucky to piss everyone off.
No, nobody talks about SUSE because it is it got bought by Novell who then did a deal with the devil (Microsoft) on patents. Which was the kiss of death to us back when we were looking to trade-up from Gentoo to something more stable.
The only games in town for server Linux is now RHEL (CentOS or SciLinux if you are cheap) or Debian. Everything else is second class and generally requires compiling from source. And frankly, it's a whole lot easier to get a job if you have experience with RHEL over some other distro.
Slashdot Mirror
It's not hard to find a Win7 laptop, the caveat is that you generally have to buy a system with Win7 Pro on it (slightly more expensive) and you won't find bottom of the barrel laptops with it.
But for a work laptop, which makes you money, that expense is minor.
(For our road warriors, we are still paying $2.0k to $2.5k for laptops with 4-5 year warranties, maxed out RAM, SSDs, spare PSUs, docking stations, software, and other goodies. My current laptop is of similar cost, purchased in 2007 with WinXP, and now running Win7. I don't plan on retiring it until 2015 or 2016, unless something goes horribly wrong with it. All of our laptops are lasting 5+ years these days.)
Finally, this is a nearly 40 inch display. They look ridiculous as a computer monitor and the ergonomics suck.
We used to say the same about 24-27" monitors.
I have (4) 22-27" displays on my desk arranged in a 2x2 array, which measures almost 45-48" diagonally. Being able to replace that with a single 40" display would be rather nice. Granted, they might need to curve it a bit for it to be properly ergonomic for desktop use. (Hidden advantage of the 2x2 array of monitors is that I can turn each one inward a bit to be properly aligned for my field of vision).
A 32" 4K display would be just about perfect for replacing the right-half of my monitor array.
The other trick you learn with multiple displays arranged in a 2x2 array is that you put less important information in the upper screens.
For office equipment (routers, firewalls, root passwords, super user passwords, etc.) we have setup (3+) people with GPG keys. They have both an electronic copy of their GPG key along with a paper copy in a sealed envelope stored in a safe-deposit box. At least one of those people has no clue what a GPG key is, but he's the CEO so he is our last-ditch backup key holder.
We then store all passwords in GPG-encrypted text files (ASCII armored text blocks), stuffed into our version control system. Whenever I change an account password, I encrypt those details using the 3+ keys of the people who need to know in case of my untimely demise. Any of those 3+ people can get access to the data. The VCS just makes it easier to distribute the latest copies of the text files.
Yes, we could probably do a "three-man rule" setup with GPG, but for now it's good enough that any of the 3+ people can access the contents of those files.
Plus with GPG ASCII armored text blocks, you can print them, email them, fax them, or whatever without worrying about compromising security of the contents. Worst case, you have some temp employee type the ASCII text block back into a text editor so that you can decrypt it.
I joking call it the "got hit by a bus" plan.
Frankly, the passwords that do not matter (do not give access to finances or other *really important* stuff) -- letting the browser remember them (protected with a master password) is fine. Or use one of the "lastpass" or "keypass" style solutions. In fact, for 99% of websites that I visit, the password is just random jibberish (15-25 random alphanumeric characters). I don't care if I can't remember it, because various software solutions do that for me.
For the more secure stuff, GPG encrypted ASCII blocks stored in text files is the best approach. You can encrypt a particular account's information with multiple GPG keys to allow multiple people to unlock it. The ASCII blocks are easily emailed around and can be printed to *paper* and stored in a file cabinet / fire safe / safe deposit box as a worst-case backup plan. We actually store our ASCII text files in a version control system, which simplifies things.
Naturally, with the GPG or any other software approach, it is only as strong as your pass phrase that protects the content. And just like passwords, it is vulnerabile to key logging software/hardware.
MOO2 was a far better game then MOO1. The big issues with it was that late-game tech made the galaxy distances meaningless, late-game battles were tedious, and the AI was rudimentary and easy to trick/defeat. Combat, however, was far more balanced in MOO2 over MOO1 and you didn't have to build stacks of 65k ships in order to win.
CIV4 was mostly an improvement over CIV3, but CIV5 goofed it up because the developers threw out all of the lessons of Civ3 and Civ4. Hexes were a great idea. Limiting the stacks of doom was a great idea. 1UPT (one unit per tile) combined with hexes that were 2x-3x too large for that purpose was garbage and resulted in constant micro-management in order to keep your forces from tripping over their own feet.
Only "weakly encrypted" PINs. How do you "encrypt" a four-decimal-digit PIN?
The same way that you protect any other plain text of nearly any length at all. You generate an encryption key (56bit DES, 112bit 3DES, 128bit AES or 256bit AES) and encrypt the plain text with that key.
The only way to get the plain text back is to brute-force the key (assuming that the algorithm is well designed, properly implemented, and that the key can't be leaked in some other fashion).
Here is an example for you: Please figure out what PIN I used in the following output from an AES-128 encryption:
2c 5b 22 99 53 42 5b cc 4d bf a7 88 3b 61 95 14
Oh, and you only get 10 guesses before the card is flagged as stolen.
(sends you back to Encryption 101)
Hashing relies on salt for security. Encryption does not.
Passwords are hashed instead of encrypted because you want to make it near impossible to reverse the process and discover the original password. In fact, you hash, because you are simply not interested in being able to reverse the process. You then use custom salt along with the hash step to make pre-generated rainbow attack tables useless. And to prevent the breaking of one account to instantly grant access to all other accounts that happen to have the same password, you salt each account with a unique salt.
Encryption, OTOH, is designed to be reversed. The only thing protecting your plain-text is the encryption key. In the case of symmetrical encryption, this is usually a 56bit (DES) or 112bit (3DES) or 128/256bit (AES) key. Adding salt to the process gains you nothing in terms of actual security.
I don't understand why any one would use encryption here at all. Why would they not use challenge/response, so that the PIN never leaves the card/keypad (encrypted or not).
Because parts of the system are still asynchronous. There is not real-time communication in a lot of parts of the banking system. And it was much worse 10-15 years ago when a lot of these systems were designed.
Decrypting them should be trivial, given the limited number of possible pin numbers, even if the table was salted.
Don't confuse hashing of PINs with encryption of PINs.
If the PINs were stored / sniffed in a hashed form where the hash algorithm is known *and* the salt is known, then yes it is trivial to figure out what PIN number appears in each record.
OTOH, if the PINs are encrypted and the key is not known by the attackers, then the attackers have to break that key. Which might be 56 bit or it might be 112 bits or it might be as large as 128 or 256 bits. Assuming that the encryption algorithm is not vulnerable to a plain-text attack, the attackers are left with having to brute-force the encryption key.
Which is not an easy task, even for 56bit keys. Especially with such a short plain-text of only 4 digits. There may be multiple keys that result in something that looks like 4 digits, but it could be the wrong 4 digits. Longer plain-text are easier to validate. So if the entire table was encrypted with a single key, it becomes easier to say that you have found the right key.
On the flip side, documenting the configuration of a system that *only* has a GUI interface for accessing that configuration is a masochistic art form.
If it is text based or (shudder) XML based configuration files, then you can easily stuff the file into any version control system and easily see the differences between what you started with and what you are now running with.
For server administration, documenting what you did to configure the system is a very big deal. Text based configuration files make that a trivial issue with no fancy tools required.
I stopped buying CFLs because in the winter they take forever to reach brightness (horrible for a bathroom)
All depends on the CFL that you buy. The better ones (mid-tier) generally come on at full brightness. Even in environments as cool as 15C.
The bigger issue with them in the bathroom setting is getting a good daylight color CFL so that everything doesn't look washed out and blue.
Yeah, you are simply an uninformed idiot if you believe what you wrote.
Server motherboards can be purchased in standard sizes, or custom sizes depending on your needs. Some of the cost difference is licensing for the SAS/SCSI chips, the rest of the difference between a server board and a "gaming" motherboard is the quality of the discrete components. You get capacitors that will last 10-15 years, not cheap crappy ones that might blow out in less then 5 years. You get boards capable of dual or quad processors. You get KVM over IPMI and other "lights out" features that let you power-cycle a system or get into the BIOS settings remotely.
With a consumer level board, you'll be lucky if it still works in 5 years. OTOH, you can buy more and keep spares on the shelf, but you still run the risk of parts with lower quality control causing tolerances to drive out of bounds.
ECC RAM has been readily available from most stores for close to a decade now. It is no longer a special-order part and in any system over a few GB of RAM, you should strongly consider using it if the motherboard (and CPU) supports it. Heck, it's now barely a 5% or 10% cost increase over non-ECC RAM. The big advantage is that you don't get bitten by flipped bits, which get more and more common as feature size shrinks.
As for hard drives, if you are not using drives with TLER in a RAID, then you are an idiot. The TLER makes sure that the drive reports failures in a timely manner so that your entire RAID array doesn't grind to a halt for 10-30 seconds. As soon as you get over 6-8 drives in the array, this really starts to matter (you can get away with it in smaller arrays).
And remember, if you can't afford new furniture every year, you can't afford a cat (you should see how shredded my 5 year old couch is).
The trick with scratching posts is that they need to be on the natural travel path. For instance, the one at the entrance to my home office gets heavy use, because in order for my cat to come visit, she passes right by it. As a result, she prefers that over scratching the furniture. Plus she always gets petted after using it because it gets my attention.
It also helps that it is a full 36" tall, so she can stretch out a bit while using it. Most of the scratching posts are well under 24" tall and nearly useless in the vertical position.
(Other keys are to use the type of material that your cat likes, plus figuring out whether they want a horizontal surface or a vertical surface to scratch.)
It may be okay because the tunnel is encrypted with SSL or SSH -- but is still not best-design. Better designs never send the password, or even the password has over the wire.
At which point, you no longer have to care whether or not the tunnel is encrypted.
It's not like North Korea's populace will know any better.
The leaks in that information dam have already started. Cross-border trade with China is leaking information in, which is why you hear a lot more the past few years about crackdowns on those caught listening to western media.
The question is "how long can they keep it up".
SSD is down to about 2x-3x the cost of 15k RPM SAS drives. Which is pretty competitive for situations where you needed the speed of 15k RPM SAS and are short-stroking the drives to get even more speed out of spinning rust.
Generally speaking:
- Avoid the 5000 most commonly used English (or your language's) words.
- Odd capitalization helps, as long as you can remember it
- Misspellings are a good idea
- L33T speak ("0" in place of "o") is basically worthless
- Tacking together 2-4 less commonly used words, mixed in with numbers/symbols still works moderately well. Figure 16 or 17 bits per word, plus 4-5 bits per symbol/number, plus 0.5 bits for every change in case.
- Pure random is difficult, unless you have KeyPass or store passwords in some other encrypted system.
- Getting above at least 45 bits is currently a decent goal, but you'll need to be up to 50 bits of strength within the next 10 years.
- 16-20 digit random alphanumeric passwords with random capitalization are around 96-120 bits.
- Anything 8 digits or less can be cracked in under a day by even a modestly funded attacker ($1000 of hardware)
On Linux, we use a minimum length of 15 and it has to pass cracklib compexlity rules. On the Windows domain, minimum length of 14 plus complexity requirements. We recommend something that is 16-20 characters long. (Our Linux servers, however are moderately more secure, because you can't SSH to them without a public-key pair.)
my understanding was that the reason a lot of Chinese (and Koreans for that matter) are still using XP is because the online banks have written their websites to Internet Explorer 6 and have no intention of ever changing that. There's some sort of crypto module that they're using which is an ActiveX control and completely incompatible with anything else.
That article from last month was about South Korea banks, who have specifically targeted ActiveX and IE6.
Not saying that China banks didn't do something equally as dumb...
We're switching over to putting the VMs on top of enterprise SSDs for just that reason. Even 15k SAS drives don't have the IOPS to deal with the demands of lots of small VMs that all assume they are running on dedicated hardware.
Price difference between enterprise SSD and 15k SAS drives is about 2.0-2.5x $/GB. So it's more expensive, but not an order-of-magnitude more expensive. And the gap keeps narrowing.
A safe rule of thumb that I've used over the years is to only allocate 99% of the drive size when putting together the array. This is a bit easier with Software RAID and mdadm under Linux.
You might even be safe at 99.5% or 99.9%, but the latter is probably a bit risky.
The other thing to look for in enterprise SSDs is the user of "super-caps" (large capacitors), these provide enough charge that the SSD can power down gracefully if the power is cut. Such as flushing any buffers, making sure the sector mapping table is updated, or whatever other metadata they need to track.
SSDs have their uses, but they're nowhere near cheap enough to replace systems with massive amounts of storage or that rely on RAID.
They're getting really close for primary storage and being used in RAID arrays..
300GB 15k RPM SAS is about $180-$200. An Intel DC S3500 Series SSD (300GB) is around $390. So the price difference of the SSD vs the spinning rust is only about 2x now. And you will probably gain 25x IOPS over that spinning rust.
Bulk storage using 7200 RPM drives is still the domain of spinning rust and will be for a while.
Let's take your example, assuming Alphanumeric (26+26+10 = 62, roughly 6 bits) and padding characters (30 possible on most keyboards, or 5 bits).
Let's assume an attacker knows your pattern:
Each alphanumeric is worth 6 bits at best. Knowing which symbol you used to pad with is only worth 5 bits. Figuring out whether to pad with 0, 1 or 2 symbols between each letter is only 2 bits per letter.
So you get 5 bits for the padding symbol, plus 8 bits per letter (6 bits for the actual alphanumeric plus 2 bits for 0-3 padding symbols between each letter). In your trivial example this totals up to: 5 + (3*8) = 29 bits. Something with length 8 is 5 + (8*8) or 69 bits. Actually a bit less because you're unlikely to remember that your padding was 3 characters after this letter, 2 after this other letter, 3 after this letter and 1 after that letter.
And that's if we brute-force it in a smart way. If we go even smarter, we'll use a word list of the 10k most common english words and do "leet" or "hacker" character substitution (0 for o, 4 for a, 3 for e, etc).
For pure brute-force, assuming only easily typed letters, each position is worth around 6.6 bits (97 or so different possible characters). 8*6.6 = 52.8 bits for any password of 8 total characters or less. That's around 7841 trillion possibles. With modern GPUs that can guess at least 1 billion per second (depending on the hash it may be as high as 15-20B/s for $1000), that 7841 trillion is only 13 weeks at 1 billion/sec. If it's a trivial hash that can be done at the rate of 13B/sec, that time falls to 1 week for any password of 8 characters or less.
And that is only if you are willing to use 97 possibles for every single character in the password, including hard to type things like "$_|-@+=>". Since that's difficult, it's probably more like 70 possibles per position for something that humans can remember. That's only 6.1 bits per position (68.5) or 490 trillion or a factor of 16x easier. So that means 5.6 days for a 1 billion/sec hash tester and only 10 hours at 13 billion/sec testing.
All of which is a very long-winded way of saying passwords of 8 characters or less (roughly 48 bits) are screwed if the attacker has $1000 and gets a copy of your hash for offline cracking.
By forcing a minimum length of 12, you've made the brute-force attack about 22 million times harder. So they either need to spend 22 million times more money or wait 22 million times longer. Naturally, as you get into the longer passwords, dictionary attacks become the preferred route so unless you are doing completely random password generation of 12+ characters, you're not gaining as much as you think. Maybe as little as 4 bits per additional character (4*12 is only 48 bits).
Things don't start getting safe(-ish) these days until you get up into the 15+ character range. Even at the worst case of only 4 bits per character of entropy, that's 60 bits (about 1.1e+18) or 1900 weeks per password at 1B/sec guesses.
They may know 45k words (and there are roughly 300k English Dictionary words), but the number of commonly used words is far less. Estimates that I've seen over the years say that the commonly used English words is around 5k to 10k.
So unless the user has a very large vocabulary and the good sense to stay away from those 5k-10k most frequently used words, you can get a long way into cracking passwords by sticking to those frequently used words.
5k ^ N is a lot smaller then 45k ^ N or 300k ^ N.
No one talks about Suse because we are off talking about more exciting things. That is the problem with having a stable sensible distribution that actually works.... Its doesn't have the latest $sexy to ignite peoples fires, or the latest $sucky to piss everyone off.
No, nobody talks about SUSE because it is it got bought by Novell who then did a deal with the devil (Microsoft) on patents. Which was the kiss of death to us back when we were looking to trade-up from Gentoo to something more stable.
The only games in town for server Linux is now RHEL (CentOS or SciLinux if you are cheap) or Debian. Everything else is second class and generally requires compiling from source. And frankly, it's a whole lot easier to get a job if you have experience with RHEL over some other distro.