The unimportant accounts (forum logins, shopping carts), just let your browser store them and protect them with a master password. Firefox is okay in this, Internet Explorer is not (as it doesn't have a master password). Give those accounts a 10-20 randomized mix of letters/numbers. I use a tool called EPG (Extended Password Generator) to do quick random generation of passwords. But there are also linux shell tricks you can do to generate stuff.
As a backup, store those login details in GPG/PGP encrypted text files in your documents folder and include that folder in your backups. I suggest 1 file per site. Then, as long as you have your PGP/GPG keys, you can retrieve your passwords for those accounts. Since the content is ASCII armored and encrypted, you could even print those blocks of text out, or email them to friends to store, or email them to yourself at various services. As regular files, they can be trivially included in a backup along with the rest of your documents (mine get stuffed into a version control system, which lets me synchronize the files across multiple machines easily).
For the more important accounts, you can extend the above scheme, but don't let your web browser remember the passwords. You'll either have to memorize the passwords or fire up GPG/PGP every time you need to login to those important accounts. For the really important, gotta have it while away from your computer, jot the passwords down on a slip of paper, fold it over and tuck it in your wallet. Which is still safer then having a trivial password.
Note that the weak point in the above is your GPG/PGP key's passphrase. Make sure you choose a very good passphrase. Make sure that you backup your keys and keychain regularly (you can even print out your GPG keys as an ASCII armored block on a sheet of paper).
So what IP in involved with APC UPS's new "Microlink" communication protocol that it uses over USB ports on the newer UPS units? Why won't APC release this information to the apcupsd developers?
NVIDIA is not the only company being stupid about this. We've bought APC Smart-UPS units for about 15 years now based on their reputation. Now we buy Tripp-Lite, because they play nicer with our Linux based servers.
ECC RAM is hardly any more expensive then regular RAM these days. There's still a price premium, but it's not much of one. Especially since individual sticks of RAM are now much cheaper then they used to be (when it was $100/stick).
DDR3 1333 2x4GB ECC - about $60-$70
DDR3 1333 2x4GB non-ECC - about $40-$45
And at those prices, a machine with 32GB of ECC isn't that much more expensive then one with 32GB of non-ECC. $260 vs $170 isn't a big deal when hard drives for the box cost $400-$600 each and the total price tag is up into the $5k to $12k range.
There's still about a $150-$200 premium on server motherboards, but that's mostly because of SAS/SATA chip license fees and getting (2) sockets instead of just one along with (8) or (12) slots for RAM. Also not a big deal when you're building a workstation level machine.
A modern SSD will last for years, or even decades, before it wears out.
Except that as the feature size on the chips go down and they make those MMC cells smaller and smaller, the number of read/write cycles you get before the cell dies goes down.
They're getting into the size already where this is becoming a huge problem.
Passwords get stored as "$id$salt$hash". The "id" bit lets you identify what hash method you're using and can be any sort of system that lets you keep track of what hash method a particular account is using to store the password hash. The "salt" bit is the random, per-user, salt (crypt allows up to 96 bits worth of salt, as it allows 16 characters chosen from a set of 64 possibles). The "hash" is the output of (salt + password -> hash algorithm).
On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it. Most people barely remember their username, nevermind their password.
How many sites do you *really* need to log in to outside of your own personal machine? Memorize those and use some sort of mechanical system for remembering the rest.
This could be as low-tech as a 3x5 index card that you keep tucked away in an envelope at home. Or a folded over scrap of paper in your wallet/purse. Or something as high tech as the various password safes or GPG encrypted text files or just letting the browser remember the password.
Or they did that in 2002, to launch a website in 2003, and have no idea how to transition a hashed password database from one system to another, which is a more difficult problem.
Basically, all hashes in the database should be stored in the format of:
$id$salt$encrypted
"id" is a code that tells you which hash was used. You can use the standard "crypt" identifiers, or make up your own if those aren't good enough.
"salt" is the unique salt for each user. Crypt allows for up to 16-character salts, drawn from the [a-zA-Z0-9./] set (64 possibles per position, total of 96 bits possible.
"encrypted" is the resulting hash.
That means that if you decide to upgrade your security by using a newer, fancier hash, you can do so in a transparent manner. The old hashes continue to work unless you specifically decide to break them and force users to enter a new password. But any new password updates can automatically update to the new hash system.
Oh look, that means the following phrase is appropriate:
Those who do not understand Unix are condemned to reinvent it, poorly.
When talking about password security you must assume that the attacker has access to your salt method, the hash function that you use and the hashed passwords.
That doesn't mean that you don't also do defense in depth such as account lockouts, increased response times for consecutive failures and limiting the number of tries. But at the end of the day you must make the assumption that the attacker can bypass those and make as many attempts per second as they have the money/resources for.
Then there's the enforcement of password complexity, which the marketing folks are at complete odds with the security folks about. Forcing users to use stronger passwords will drive them away and marketers will try to get those barriers lowered so they can build a user base.
You must make the assumption that the attacker knows both your salt(s) and how you apply the salt(s) to the password to create the hash.
Assuming otherwise allows you to do foolish things like use the same salt across multiple (or all) accounts. Which makes it trivial for an attacker to compute a single rainbow table and attack multiple accounts in one shot.
Having separate salts (at least 8-bit and preferably at least 16-bit or 32-bit) for every individual user gives you a last line of defense in the event that your password database is stolen and your salts/methods are exposed. With individual salts, the attacker is forced to brute-force attack every single account as a separate problem. Breaking one account doesn't automatically mean that other accounts are also broken.
If the site uses a single salt for all passwords, then as soon as you crack user A's password, you have user X, Y & Z passwords because they have the same account hash. (In fact, you would specifically target any hashes which appear more then once.)
The initial break of the hash is either done via a pre-gen rainbow table (which contains pairs of passwords and their hashes) or by brute-force approach (work through possible passwords, hash them, compare against the list of hashes, spit out the matches).
Also, since you have the hashes, and checking random passwords against the hashes is an embarrassingly parallel problem you can throw as many cores, machines, GPUs at the problem as you want. That lets you try millions of passwords per second. Which is fast enough that you can go through all 8-character passwords plus more advanced schemes like word-word-number-symbol.
While they don't compete in terms of storage/$ they are getting to the point where they are cheap enough for enough storage that people find them worthwhile. That's all it really takes. Few people actually need 2TB of storage, the idea that SSDs have to be dead equal to HDDs is silly. Many people will decide they can get on just fine with 160GB and would rather have the speed.
Yeah, they don't have to compete on a $/GB basis against magnetic HDs in all sectors. Once they got cheap enough for big enough (at around the $1.50/GB mark), uptake increases rapidly because there's a large segment of users who don't need terabytes of primary storage.
I still say the magic number is $1/GB. Although the current price points of $1.25-$1.50 per GB are close enough that 128GB drives are very affordable.
Without parity you're going to miss certain types of corruption so RAID6 is actually superior from a data reliability standpoint.
You're confusing parity with ECC or actual checksumming.
When you read a sector from a RAID-6 array, all you get back is that sector, it doesn't poll multiple disks and calculate whether the parity is good or not.
The older ext3 FS with lots of files (think "millions of files") takes a long time to fsck every N days or M boot cycles. The ext4 file system is definitely a step forward in that regard. Ext4 is also a lot faster at deletion of multi-gigabyte files when compared to ext3.
Ext4 is definitely a step up for most use cases over ext3. We now only use ext3 on things like/boot and / and other small file systems. All of the bigger file systems over a few GB (such as the mail files, or file shares, etc) are now all on ext4.
Those thinkpads are worth every penny too. My laptop is about 5-years old now, a dual-core 2GHz T61p with all new innards (repaired just before it left warranty).
Other then the fact that the Core 2 Duo CPU is a bit slow these days and the fact that I need to install the 8GB memory option, it still works perfectly fine. Especially once I swapped in a SSD, which made it measurably more responsive and pleasant to use for coding and task switching.
I sometimes wonder if MS might have actually been more successful if HAD been broken up by the DOJ and forced to actually innovate vs. just collecting rent from their monopoly positions.
Of that, I have little doubt.
Absolutely none. It would have been the best thing for Microsoft, even if painful in the short term.
We create separate files by service and encrypt the contents with GPG (regular old text files with ASCII armored encryption blocks).
Dead simple, other then the GPG key management and passing around public keys. There's also the issue that every time you add someone new, you need to re-encrypt all the files (but that's a key management / PKI issue).
Since they're regular text files, they can be emailed, printed, faxed, OCRd, stuffed in envelopes / safes, etc. We stuff ours into a version control system for simplicity.
It's also a good method to use for personal accounts. Create 1 file per account / service and just encrypt the contents with GPG.
Heavy instancing is very bad for the "M" part of MMO. Want to help your friends on a quest? Or just quest along side them to be companionable? Can't be done unless you both remain lockstep with each other as you move through the quest chains.
Instancing in WoW's WotLK made the latter zones a solo experience unless you worked and played on the exact same schedule as a few other people.
Instancing in Cata wasn't much better.
Sure, it's fun to see the world change, as if you are having an impact on the world, but it definitely harms the social aspect.
The other big problem with trying to turn a wonderful single-player game into an MMO: The Mary Sue problem.
In a single-player game, all the NPCs telling you that "you're special" and that you'll be the only one who can stop the big bad ugly works, because you are the central actor in the story. There's literally no other player who can do what you can do within that universe.
In a MMO, it rings false. While every NPC is busy trying to tell you that you are the special one, you can't help but notice them saying the exact same things to the dozens/hundreds of other players in the area. (This is a *huge* problem with the story in SWTOR.)
I think it does, because the world *seriously* needs a decent alternative to MS Access and neither OO nor LO have it.
Yeah, it's pretty obvious that the developers of Base have no clue as to how MSAccess gets used out in the business world.
To name a few more killer features:
It's extremely simple to use MSAccess to tie together different data sources and move data from one to the other. OOBase back in the v3 days couldn't talk to two different data sources at the same time.
Last time I looked at OOBase, I tried to do a CSV export. You had to copy the table contents into an OOCalc sheet and then export that to CSV, you couldn't just import/export into OOBase using CSV files directly.
As much as I hate the all-in-one binary format of the MDB, the ease with which you can copy queries/tables, setup stupid little macros, or do reports or little forms is unmatched.
Sometimes you just need a little "one-off" database to hold a disparate data set which has no structural similarities to anything else.
And is probably annoying as hell if you are remote controlling the unity desktop in a windowed session or trying to run a Synergy setup where there is a screen to the left of the Unity screen.
Slashdot Mirror
The unimportant accounts (forum logins, shopping carts), just let your browser store them and protect them with a master password. Firefox is okay in this, Internet Explorer is not (as it doesn't have a master password). Give those accounts a 10-20 randomized mix of letters/numbers. I use a tool called EPG (Extended Password Generator) to do quick random generation of passwords. But there are also linux shell tricks you can do to generate stuff.
As a backup, store those login details in GPG/PGP encrypted text files in your documents folder and include that folder in your backups. I suggest 1 file per site. Then, as long as you have your PGP/GPG keys, you can retrieve your passwords for those accounts. Since the content is ASCII armored and encrypted, you could even print those blocks of text out, or email them to friends to store, or email them to yourself at various services. As regular files, they can be trivially included in a backup along with the rest of your documents (mine get stuffed into a version control system, which lets me synchronize the files across multiple machines easily).
For the more important accounts, you can extend the above scheme, but don't let your web browser remember the passwords. You'll either have to memorize the passwords or fire up GPG/PGP every time you need to login to those important accounts. For the really important, gotta have it while away from your computer, jot the passwords down on a slip of paper, fold it over and tuck it in your wallet. Which is still safer then having a trivial password.
Note that the weak point in the above is your GPG/PGP key's passphrase. Make sure you choose a very good passphrase. Make sure that you backup your keys and keychain regularly (you can even print out your GPG keys as an ASCII armored block on a sheet of paper).
In general, hash results are a fixed length.
MD5 hashes always look like the following:
$ echo -n "password" | md5sum
5f4dcc3b5aa765d61d8327deb882cf99 -
SHA1 hashes always look like:
$ echo -n "password" | sha1sum
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 -
No matter what input you give, SHA1 and MD5 hashes are always the same length:
$ echo -n "short" | sha1sum
a0f4ea7d91495df92bbac2e2149dfb850fe81396 -
$ echo -n "Really Long Password" | sha1sum
b32aced0e8ccc1bfd8ee327455af67e196590371 -
So what IP in involved with APC UPS's new "Microlink" communication protocol that it uses over USB ports on the newer UPS units? Why won't APC release this information to the apcupsd developers?
NVIDIA is not the only company being stupid about this. We've bought APC Smart-UPS units for about 15 years now based on their reputation. Now we buy Tripp-Lite, because they play nicer with our Linux based servers.
ECC RAM is hardly any more expensive then regular RAM these days. There's still a price premium, but it's not much of one. Especially since individual sticks of RAM are now much cheaper then they used to be (when it was $100/stick).
DDR3 1333 2x4GB ECC - about $60-$70
DDR3 1333 2x4GB non-ECC - about $40-$45
And at those prices, a machine with 32GB of ECC isn't that much more expensive then one with 32GB of non-ECC. $260 vs $170 isn't a big deal when hard drives for the box cost $400-$600 each and the total price tag is up into the $5k to $12k range.
There's still about a $150-$200 premium on server motherboards, but that's mostly because of SAS/SATA chip license fees and getting (2) sockets instead of just one along with (8) or (12) slots for RAM. Also not a big deal when you're building a workstation level machine.
His books are "story, as a string of awesome anecdotes." I mean, anyone who can go on for pages about how to eat Captain Crunch cereal......
Translation: He needs a fucking editor to hold his head underwater until he learns how to stitch a story together and wrap it up properly.
There were some great concepts in Snow Crash, but the execution and pacing was just horrid.
A modern SSD will last for years, or even decades, before it wears out.
Except that as the feature size on the chips go down and they make those MMC cells smaller and smaller, the number of read/write cycles you get before the cell dies goes down.
They're getting into the size already where this is becoming a huge problem.
Go look at how "crypt" works.
$ man crypt
Passwords get stored as "$id$salt$hash". The "id" bit lets you identify what hash method you're using and can be any sort of system that lets you keep track of what hash method a particular account is using to store the password hash. The "salt" bit is the random, per-user, salt (crypt allows up to 96 bits worth of salt, as it allows 16 characters chosen from a set of 64 possibles). The "hash" is the output of (salt + password -> hash algorithm).
On the flip side, if you don't reuse your passwords, you're never going to remember how to access all 200 sites that require it. Most people barely remember their username, nevermind their password.
How many sites do you *really* need to log in to outside of your own personal machine? Memorize those and use some sort of mechanical system for remembering the rest.
This could be as low-tech as a 3x5 index card that you keep tucked away in an envelope at home. Or a folded over scrap of paper in your wallet/purse. Or something as high tech as the various password safes or GPG encrypted text files or just letting the browser remember the password.
Or they did that in 2002, to launch a website in 2003, and have no idea how to transition a hashed password database from one system to another, which is a more difficult problem.
If you design things properly, not hard at all.
Basically, all hashes in the database should be stored in the format of:
$id$salt$encrypted
"id" is a code that tells you which hash was used. You can use the standard "crypt" identifiers, or make up your own if those aren't good enough.
"salt" is the unique salt for each user. Crypt allows for up to 16-character salts, drawn from the [a-zA-Z0-9./] set (64 possibles per position, total of 96 bits possible.
"encrypted" is the resulting hash.
That means that if you decide to upgrade your security by using a newer, fancier hash, you can do so in a transparent manner. The old hashes continue to work unless you specifically decide to break them and force users to enter a new password. But any new password updates can automatically update to the new hash system.
Oh look, that means the following phrase is appropriate:
Those who do not understand Unix are condemned to reinvent it, poorly.
(Learn from those who have gone before.)
When talking about password security you must assume that the attacker has access to your salt method, the hash function that you use and the hashed passwords.
That doesn't mean that you don't also do defense in depth such as account lockouts, increased response times for consecutive failures and limiting the number of tries. But at the end of the day you must make the assumption that the attacker can bypass those and make as many attempts per second as they have the money/resources for.
Then there's the enforcement of password complexity, which the marketing folks are at complete odds with the security folks about. Forcing users to use stronger passwords will drive them away and marketers will try to get those barriers lowered so they can build a user base.
You must make the assumption that the attacker knows both your salt(s) and how you apply the salt(s) to the password to create the hash.
Assuming otherwise allows you to do foolish things like use the same salt across multiple (or all) accounts. Which makes it trivial for an attacker to compute a single rainbow table and attack multiple accounts in one shot.
Having separate salts (at least 8-bit and preferably at least 16-bit or 32-bit) for every individual user gives you a last line of defense in the event that your password database is stolen and your salts/methods are exposed. With individual salts, the attacker is forced to brute-force attack every single account as a separate problem. Breaking one account doesn't automatically mean that other accounts are also broken.
If the site uses a single salt for all passwords, then as soon as you crack user A's password, you have user X, Y & Z passwords because they have the same account hash. (In fact, you would specifically target any hashes which appear more then once.)
The initial break of the hash is either done via a pre-gen rainbow table (which contains pairs of passwords and their hashes) or by brute-force approach (work through possible passwords, hash them, compare against the list of hashes, spit out the matches).
Also, since you have the hashes, and checking random passwords against the hashes is an embarrassingly parallel problem you can throw as many cores, machines, GPUs at the problem as you want. That lets you try millions of passwords per second. Which is fast enough that you can go through all 8-character passwords plus more advanced schemes like word-word-number-symbol.
While they don't compete in terms of storage/$ they are getting to the point where they are cheap enough for enough storage that people find them worthwhile. That's all it really takes. Few people actually need 2TB of storage, the idea that SSDs have to be dead equal to HDDs is silly. Many people will decide they can get on just fine with 160GB and would rather have the speed.
Yeah, they don't have to compete on a $/GB basis against magnetic HDs in all sectors. Once they got cheap enough for big enough (at around the $1.50/GB mark), uptake increases rapidly because there's a large segment of users who don't need terabytes of primary storage.
I still say the magic number is $1/GB. Although the current price points of $1.25-$1.50 per GB are close enough that 128GB drives are very affordable.
Without parity you're going to miss certain types of corruption so RAID6 is actually superior from a data reliability standpoint.
You're confusing parity with ECC or actual checksumming.
When you read a sector from a RAID-6 array, all you get back is that sector, it doesn't poll multiple disks and calculate whether the parity is good or not.
The older ext3 FS with lots of files (think "millions of files") takes a long time to fsck every N days or M boot cycles. The ext4 file system is definitely a step forward in that regard. Ext4 is also a lot faster at deletion of multi-gigabyte files when compared to ext3.
/boot and / and other small file systems. All of the bigger file systems over a few GB (such as the mail files, or file shares, etc) are now all on ext4.
Ext4 is definitely a step up for most use cases over ext3. We now only use ext3 on things like
Those thinkpads are worth every penny too. My laptop is about 5-years old now, a dual-core 2GHz T61p with all new innards (repaired just before it left warranty).
Other then the fact that the Core 2 Duo CPU is a bit slow these days and the fact that I need to install the 8GB memory option, it still works perfectly fine. Especially once I swapped in a SSD, which made it measurably more responsive and pleasant to use for coding and task switching.
Oh, I have tried it many times and still hate trackpoints :) I know some people who love it, but I find them extremely frustrating.
Turn the mouse sensitivity up to the maximum. Makes the trackpoint much easier to use without wearing out your index finger.
(I'm a touch typist and love the trackpoint. It's the main reason I never bought an Apple laptop and have stuck with Thinkpads.)
I sometimes wonder if MS might have actually been more successful if HAD been broken up by the DOJ and forced to actually innovate vs. just collecting rent from their monopoly positions.
Of that, I have little doubt.
Absolutely none. It would have been the best thing for Microsoft, even if painful in the short term.
We create separate files by service and encrypt the contents with GPG (regular old text files with ASCII armored encryption blocks).
Dead simple, other then the GPG key management and passing around public keys. There's also the issue that every time you add someone new, you need to re-encrypt all the files (but that's a key management / PKI issue).
Since they're regular text files, they can be emailed, printed, faxed, OCRd, stuffed in envelopes / safes, etc. We stuff ours into a version control system for simplicity.
It's also a good method to use for personal accounts. Create 1 file per account / service and just encrypt the contents with GPG.
34064 unique pairs of usernames/passwords.
About 1/2 (15834) are @hotmail
(Yahoo and GMail each had about 2000-2200 occurences.)
So possibly phished or keylogged.
Or hotmail is a lot more popular then we realize.
This is likely the password file from a spambot c&c network.
You're reaching. A lot of the accounts/passwords are things like:
andre@someplace.com:andre
somebraindeaduser@somewhere:123456789
Once you get past the spam accounts, there's a lot of what looks like valid user accounts with weak passwords.
Heavy instancing is very bad for the "M" part of MMO. Want to help your friends on a quest? Or just quest along side them to be companionable? Can't be done unless you both remain lockstep with each other as you move through the quest chains.
Instancing in WoW's WotLK made the latter zones a solo experience unless you worked and played on the exact same schedule as a few other people.
Instancing in Cata wasn't much better.
Sure, it's fun to see the world change, as if you are having an impact on the world, but it definitely harms the social aspect.
The other big problem with trying to turn a wonderful single-player game into an MMO: The Mary Sue problem.
In a single-player game, all the NPCs telling you that "you're special" and that you'll be the only one who can stop the big bad ugly works, because you are the central actor in the story. There's literally no other player who can do what you can do within that universe.
In a MMO, it rings false. While every NPC is busy trying to tell you that you are the special one, you can't help but notice them saying the exact same things to the dozens/hundreds of other players in the area. (This is a *huge* problem with the story in SWTOR.)
I think it does, because the world *seriously* needs a decent alternative to MS Access and neither OO nor LO have it.
Yeah, it's pretty obvious that the developers of Base have no clue as to how MSAccess gets used out in the business world.
To name a few more killer features:
It's extremely simple to use MSAccess to tie together different data sources and move data from one to the other. OOBase back in the v3 days couldn't talk to two different data sources at the same time.
Last time I looked at OOBase, I tried to do a CSV export. You had to copy the table contents into an OOCalc sheet and then export that to CSV, you couldn't just import/export into OOBase using CSV files directly.
As much as I hate the all-in-one binary format of the MDB, the ease with which you can copy queries/tables, setup stupid little macros, or do reports or little forms is unmatched.
Sometimes you just need a little "one-off" database to hold a disparate data set which has no structural similarities to anything else.
And is probably annoying as hell if you are remote controlling the unity desktop in a windowed session or trying to run a Synergy setup where there is a screen to the left of the Unity screen.