Your proposal fails for the same reason that countless other "pay" proposals fail.
The spammers already use hacked systems to send out their email. It's no big leap for them to also hijack the stamp/payment system to have the hacked system's owner pay for the spam run.
Basically, the bad guys will get away with paying nothing - and the burden will fall on legitimate users of e-mail.
The only possible upside to your proposal is that it would cost the hacked system's owner in a way that might encourage them to get their infected machine fixed. But the downsides far outweigh that negligible upside (and the ISPs can already identify and disconnect infected machines - a class action lawsuit against ISPs who don't would work better).
"dropping to the floor" means that you accepted the message for local delivery (or further handling) and then silently discarded it.
If you're rejecting at SMTP connection time - you're not dropping mail on the floor - you're doing it properly by giving the origin server a 4xx or 5xx code.
(The worst thing you can do is to 2xx the message, and then decide later that it's undeliverable. At that point, you're either not obeying RFCs by dropping it on the floor or you're going to generate backscatter if you send out a bounce message.)
Or for the terminally lazy and understaffed departments - throw the whole system (excluding log files, temporary files, and user data files) into a version control system. I heartily recommend FSVS which uses SVN as the back-end database. Now you have a full history of what changed, when it changed, with the ability to browse the repository using 3rd party tools to see how it changed.
I recommend a daily cron job to commit any changes that the admin forgot to check-in.
Usual work flow is:
# cd/etc/somefolder
# (vi|emacs) somefile
# fsvs ci -m "FSM: changed XYZ to support a new ABC and to fix issue 123" somefile
Now when stuff inevitably breaks, you have the ability to quickly see what changed. Not to mention the number of times where it's helped me remember why something changed, or as a quick way to reference "how did I do that before?" type configs.
At work, I call it my "hit by a bus insurance plan". Anyone who can't browse a version control system, look at the comments, do diffs on the configuration files... is probably over-paid.
I wouldn't classify RHEL v5 as "cheap". The cheap shops go with CentOS and pay nothing. The annual cost for RHEL is far from nothing (although less expensive than Windows - especially once you start factoring in the costs for all of the server apps that you put on top of RHEL).
The real value of RHEL is that they will help you out with things that are not specific to their distro. Unlike, say Microsoft, where any problems with a 3rd party application are pretty much yours and yours alone. RH is small enough to still be hungry for business and the real value of RHEL is in the ecosystem of the applications that run on top of RHEL.
What in the world does religion have to do with morality?
It means, generally, that there is a prevailing wind in the direction of moral behavior being valued. Often lauded as gaining favor with some higher power who does not change what is moral on a whim. The cultural norm is therefore, to act in a moral manner and the morals are fixed and rarely change.
As opposed to a culture where the majority do not believe in a higher power and believe that all morals are relative and can be redefined at will. In which case morality becomes "what is convenient to me and which benefits me". Since there is no higher power (other then obeying those who can punish you), the cultural norm becomes "whatever I can get away with is okay".
Basically, it's the difference between morals that are considered to be absolute and unchanging because they were handed down by $diety - and cultural mores which can shift in the slightest breeze.
Yah, you can cut the rate of bad connections down by about 50%+ if you force the sending host to follow the RFCs.
- Incorrectly formatted HELO/EHLO greeting? 5xx Doesn't catch too many connections as the other end would have to massively screw up in order to trigger the invalid HELO rule.
- Giving a HELO/EHLO that is not a FQDN (fully qualified domain name)? 5xx Many botnets don't follow the FQDN rule and will give a randomly generated HELO name. I've never had a false-positive with checks like this.
- Giving a HELO/EHLO that does not resolve via DNS (see RFC 5321, section 2.3.5 where it talks about this issue in the 1st bullet point)? 5xx or 4xx if there was a DNSFAIL issue
- SPF record says "-all" for the MAIL FROM or HELO lookup and it fails to pass SPF? 5xx (At which point, you're simply following the instructions of the sender. If the record says "-all", they WANT you to reject non-conforming mail.)
- HELO/EHLO which purport to be from your own system? 5xx Know your servers, know who is allowed to put your domain into the HELO/EHLO and boot the pretenders. Easily done in Postfix with a few simple rules.
Most of those are standard checks in Postfix and will greatly reduce the amount of spam that you have to analyze in a more in-depth manner. Which results in a huge CPU/bandwidth savings if you can tell them to bugger off before the DATA command is issued.
I prefer to save block lists for the spam scoring system as there are too many false positives (and sometimes abuses of power) in the DNSBLs. Far safer to score rather then block - although Spamhaus' Zen list is extremely good.
What do you do if you need to use a public computer? A lot of times, computers at places like libraries, college computer labs, etc won't allow you to run any programs which weren't installed by an Admin. If you rely on something like KeePass, don't you run the risk that you won't be able to access one of your passwords when you need to? Also, with KeePass, you run some possibility that once you decrypt the password database, some sort of spyware on the computer might hoover up all your passwords?
a) Don't.
That's pretty much what it boils down to. Personally, I use a set of GPG-encrypted text files to store my passwords, no more then 1 site per file. For the sites that I don't care if I can't get access to them until I can decrypt the text files, I simply generate a random passphrase (completely randomized, not pronounceable at all) and use that.
For sites that I do need to get into, I use a more memorable passphrase.
But really... if you can't trust the computer with your GPG key, do you REALLY want to be logging into a sensitive website using the same computer?
(We really need an open hardware solution like a credit card sized calculator where you type in a 4 digit challenge and get back an 8 digit response that you have to key in. Combined with passwords it would be "good enough" and a big step up from today's systems.)
I don't know about everyone else, but I don't use my work credentials or my root password when I visit sites that look like rockyou.com. They just aren't important enough for me to use secure passwords. Five letters and a digit is more than enough for me to use on most forums, Myspace, and other unimportant sites -- all of whom I don't trust to actually store my passwords in a secure manner. So I am refraining from commenting on the horrible state of passwords when it concerns a horrible state of a website, because I don't think I'm the only one who acts this way.
I just tell a program like EPG or md5 (or some other hash program) to generate a 15-20 random alphanumeric password, use that, and store the result in a text file for throwaway accounts on unimportant sites. Then I have the browser remember the darned thing. Usually I'll GPG encrypt the contents of the text file (along with other information about the site).
If the site is unimportant - it doesn't matter to me if I can't get immediate access to it without decrypting a text file using my GPG key. Doubly so if the program (such as the e-mail program or web browser) can remember the password in exchange for my using a more secure pass phrase to guard all stored passwords. If the computer can remember it - why not use a completely random password?
If you're using complete words in your pass phrase, the combinations are actually a lot smaller then that.
There are roughly 300k words in english and related languages that can easily be typed on an english keyboard. So 3 words is only (300k ^ 3) or about 27,000,000 billion combinations. In reality, it's generally a lot smaller (25k ^ 3) which is only 15625 billion combinations. An 8-char password (approximately 72 possibles per position) is around 722200 billion combinations.
Basically, a randomly generated password is around 6.0 to 6.2 bits of entropy per character. A word is a lot lower, down around 3-4 bits of entropy per character.
Cheap systems can run through a very large volume of brute-force attacks per second now. Especially with the addition of NVIDIA CUDA cards, which are amazingly good at doing brute-force attacks. For md5 passwords, even salted, anything of 8 chars or less can easily be cracked in under a day.
Past a certain salt size (say 16 or 24 bits), having a longer salt really doesn't change things. The attacker is going to have to switch to a brute-force attack in that situation anyway, so having a 32bit vs a 64bit salt isn't a big improvement. Once you get into brute-force, your only hope is that password length and complexity will take too long to crack.
Basically: 8 chars or less, even randomly typeable characters, is pretty much trivial to break in under a day. And that's with a system costing maybe $800. Going with 10-12 characters is going to be safe against all but the most determined adversaries (who have 10k host botnets to throw at the problem).
I had erased MOOIII from memory. I loved MOO1&2, i told my roomate how great the games were, so we went half in on 3 and got it, played it for a few days, and i think i actually threw it away after about a year of it sitting on my shelf. they ruined the best part of the game, massive ship battles!
There was an awesome game hidden inside MOO3. Sadly, it was impossible to play.
I really really wanted to like MOO3 as it brought the concept of terrain and choke-points back into the series. (Unlike late-game MOO2 where you can pretty much fly over/around any worm-holes or nebula without worries and your ship range pretty much makes all systems within range.)
There were some other great concepts deep within MOO3, but it was badly mismanaged and the UI was horrid at presenting those concepts.
At this point, I'm mostly hoping that Stardock will move GalCiv away from the flat 2D plane in their current incarnation and switch to a flattened 3D universe with star lanes.
My company wants me to change my pass every 2 months. Guess what happens to the password strength over time.
It's a leftover idea from a bygone decade.
The primary advantage of a required monthly or bi-monthly change is that if a password is compromised, it's only useful for about 1/2 of the expiration period. So it's a way of reducing risk in the case of accidental or nefarious disclosure.
But the big downside is that it requires users to be constantly learning new passwords every month or so. And unless these passwords are automatically assigned, users WILL pick weaker and weaker passwords over time or passwords that fit into an easily remembered sequence. So you really end up back where you started.
Forced password renewal is a valid strategy in a small number of cases. Such as a system which protects billions of dollars in assets or is super super critical to the business. But in those cases, there should be 2-factor authentication in play anyway and the passwords probably only need to be changed every 3-6 months and should be randomly assigned.
For end users? Limit their permissions, force complex passwords, but don't require them to change frequently (*maybe* once every 2 years). Tell them to go ahead and write the passwords down and store them in their wallet next to their credit cards. Which is at least a huge step up from putting it under the keyboard or stuck to the monitor.
Longer passwords are also easier to remember if they are used frequently (at least daily). But for some users, it may take as long as 2-3 weeks for them to remember it without looking.
Of course, this is relevant because in the event of an LHC-created black hole destroying the planet, we will of course launch into space a "lifeboat" containing a judge, defense and plaintiff lawyers, Rusty the Bailiff to keep everyone in line, and one token normal person to be the plaintiff. Justice will be served no matter what the damage to the planet is.
So we'll be acting out the "Forge of God" story?
(End of the book, the young people on the lifeboat style arks are brought to the observation ports in order to watch the destruction. Then they get inducted into the force that is bent on punishing the planet destroyers.)
I'll bite... (it's been a few years, but the lingo is mostly the same).
"x up" - someone wants to form a fleet, everyone is in a channel (either the corp channel, the alliance channel or a custom channel). The fleet commander (FC) says that they need N people to perform task Y and that you should put an "x" (literally) in the channel. The FC can then right-click on the people who X'd up and add them to the fleet. Which is a lot easier then trying to find people in the "local" list (a list of everyone in the star system or docked at a station).
"module lag" - Weapons and active defenses (active shielding that draws power) and things like tractor beams, warp inhibitors, or speed boosts are all called modules. In a busy fight, you'll press the key associated with said module and find that the server takes anywhere from a few seconds to a few minutes before it registers. Of course, if you're jumping into a system or into a hot fight, your system will lag while it downloads the new location information from the server. Meanwhile, the enemy has probably targeted you and blown you up before your screen clears and you can activate modules.
"e-warp" - When a player disconnects from the server (pulling the plug, going linkdead, etc), their ship will after a few seconds turn and warp away to a random location in the star system. Also known as emergency warp. Not to be confused where a pilot aligns with a distant object and then warps out of the fight in an attempt to get away. Ships don't turn on a dime, they have to first align with their destination before the warp engine can cut in. Emergency warps can also happen if the lag is so bad that the server thinks you've disconnected, even if you really hadn't.
"gates" - All jumps into a system (barring some other tricks such as setting up a jump bridge by sneaking a covert ship into the system ahead of time) come through the small handful of gates. Upon arrival in a system, you'll appear at a few km from the gate in a random direction after which you have to turn/align before you can warp away from the gate. The goal of a gate camp is to catch (tackle) ships that have jumped in so that they can't warp away.
I once got a shock during enclosure maintenance when I touched a secondary supply that wasn't powered off. It was a minor shock, but that's partly because I was wearing insulated boots and had the other hand in my pocket. (i.e. there was no path to ground.)
I thought the purpose of keeping one hand in your pocket is so that the current doesn't cross the center of the chest cavity and play havoc with your heart. The idea being that the current will travel down one side or the other to the floor.
What was so special about Duke Nukem 3D compared to Doom, Quake, or 3D Realms' own Rise of the Triad?
The humor, the environment, the subtle digs at authority. The first level in DN3D is very memorable, starting out on a roof with Duke muttering about those aliens destroying his ride. Followed up almost immediately by pig cops flying around on hover bikes.
At the time there was a fair amount of interaction with the environment as well. Lots of destructible props scattered around.
Doom was just a "scary" shooter. Quake really didn't have a memorable story line and was mostly a multi-player game. Rise of the Triad never made it onto my radar screen.
P.S. My favorite fight scene in fiction is probably from the story "Gulf" by Robert A. Heinlein. The protagonist is a super-intelligent spy, and he is expecting some sort of trouble from the bad guys; since he is in a public place he figures their first move will be some kind of diversion. The bad guys light off some fireworks, and almost everyone around the spy turns to look in the direction of the bang; two people near the spy do not look and head straight for him. Without hesitating he attacks them, and lays them out instantly, and then walks away as if nothing had happened. I thought that was a lot cooler than a three-page fight scene would have been.
See also most of the Quiller novels by Adam Hall.
Throw the ferret down the hole, see what he comes back with.
I'm fairly certain actually realistic shooters exist. It's just that realistic mechanics, from a player perspective, are extremely boring, except for in a few limited cases (only one I can think of that is fun and isn't at least a bit fantastic or sci-fi is Counter Strike).
Combat is boredom punctuated with moments of pure terror.
(Also a key reason why nobody likes to play defense in a team-oriented FPS game. It's a lot of waiting around during a 15-20 minute match for a target to enter the area that you're defending. Yet two dedicated defenders can hold off multiple attackers for long enough to get reinforcements in place.)
I agree that key management remains an issue. Subversion is the worst popular example, with its habit of storing your passwords in your home directory in plain text, with no expiration and no utility for flushing them.
The primary alternative (and it's a good one) is SSH public keys stored in a ssh-agent process.
(There's simply no other way for SVN to function in a way that keeps it from prompting you for your password at every turn, because there's no such thing as a standard 'password agent' similar to SSH. That's not to say that there couldn't be, but every system rolls their own while OpenSSH is fairly standard. GPG encoding might have worked, but would require reliance on yet another package along with running some sort of GPG key ring. And the SVN developers chose not to rely on security through obscurity by trying to hide the storage of the password. There's simply no easy way to store a plaintext password that has to be fed to another system in a secure manner.)
Key management is truly a bitch, especially when you have a secret (password) that has to be provided to another system in the clear.
Re:Is the newest version deployed everywhere?
on
GSM Decryption Published
·
· Score: 2, Insightful
This sort of statement is equally dangerous by leading people to believe that just because they are using a strong cipher they are secure. Basically, unless a cryptography expert is designing your entire system, you're going to fuck SOMETHING up. There is no magic bullet.
That something is almost always key management.
(Encryption is simple compared to the complexities involved in keeping key management secure.)
Interestate 795 (the Northwest Expressway) outside of Baltimore, MD did this. But not for high-speed rail (which requires things to be too straight). They did it as part of the Baltimore subway system. The tracks run between the two sections of highway, including a station out at Owings Mills being placed between the two sides.
The major downside from the point-of-view of the passengers... putting your station in the middle of a divided highway means that it's already 25-50 meters away from any useful destination. That station could have been located a lot closer to the Owings Mills mall (just west of the station).
... the marketplace will respond. At those sorts of prices, all of the alternatives, like solar, that are impractical today will be cheap by comparison. I don't think high speed rail will necessarily have anything to do with it, however.
That, is a guarantee.
The big question is, however, "how fast will the price spike and stay elevated?".
If gas prices rise at a rate of say 5-15% per year, things probably won't be too bad and the economic shocks will be minimal. But if it spikes too quickly, people won't have time to react and switch to better alternatives. People will have to cut back in other areas very suddenly, which tends to cause things like recessions and other social problems.
We're running at around $3/gal here in the NYC area. If I was planning out for the next 5-10 years, in a situation where fuel cost is a primary issue (such as evaluating a new vehicle), I'd plan in the $5-$6 per gallon range to be safe. But even then, the price of a more fuel efficient car may be too expensive to compete with a gas guzzler that can be had for 1/2 the cost.
(You can see the same thing when evaluating an office full of 17" CRTs that use about 90W. At current electricity prices of $0.18/kWh, the replacement monitors would have to cost less then $100 to have less then a 4 year payback. Yes it would be better for the environment and the monthly electrical bill to cut that by 3/5, but the near-term outlay of cash has too long of a payback period.)
People generally avoid it because, even during rush hour when an 11-mile trip takes 25-30 minutes by car, using the light rail system will be 50-60 minutes.
It's the problem of too many stops. Buses have the same issue, except that they also fight with traffic. Back when I used to commute from central Pennsylvania up to NYC via Amtrak, the train took close to 4 hours, mostly due to stopping at every podunk little town along the way. They could've shaved at least 40 minutes off of that by skipping the tiny 1 red-light town stops where maybe 2-3 people would get off of a train of 200+.
Now, personally, I think trains are an excellent form of mass transit. They fit in well with suburban architecture (they can go underground if electric is used), the stations are *tiny* compared to airports, and it's easy to build inter-modal and go from city center to city center. The downsides is that you have to lay and maintain track and right of way, and there aren't enough straight sections to allow for high speed rail to work well.
The other problem is that you need a critical mass of people all going in the same direction at roughly the same time. Which is why rail systems like the LIRR work well (a large number of people commute into NYC daily). Or you need a highly localized population density (such as Japan or places like the Netherlands) where everyone lives within walking distance of the various mass-transit solutions. Spread-out suburbs and McMansions where everyone lives as far as possible away from their neighbors are the main problem that causes mass transit to underperform.
Slashdot Mirror
Your proposal fails for the same reason that countless other "pay" proposals fail.
The spammers already use hacked systems to send out their email. It's no big leap for them to also hijack the stamp/payment system to have the hacked system's owner pay for the spam run.
Basically, the bad guys will get away with paying nothing - and the burden will fall on legitimate users of e-mail.
The only possible upside to your proposal is that it would cost the hacked system's owner in a way that might encourage them to get their infected machine fixed. But the downsides far outweigh that negligible upside (and the ISPs can already identify and disconnect infected machines - a class action lawsuit against ISPs who don't would work better).
"dropping to the floor" means that you accepted the message for local delivery (or further handling) and then silently discarded it.
If you're rejecting at SMTP connection time - you're not dropping mail on the floor - you're doing it properly by giving the origin server a 4xx or 5xx code.
(The worst thing you can do is to 2xx the message, and then decide later that it's undeliverable. At that point, you're either not obeying RFCs by dropping it on the floor or you're going to generate backscatter if you send out a bounce message.)
Configuration Management
/etc/somefolder
Or for the terminally lazy and understaffed departments - throw the whole system (excluding log files, temporary files, and user data files) into a version control system. I heartily recommend FSVS which uses SVN as the back-end database. Now you have a full history of what changed, when it changed, with the ability to browse the repository using 3rd party tools to see how it changed.
I recommend a daily cron job to commit any changes that the admin forgot to check-in.
Usual work flow is:
# cd
# (vi|emacs) somefile
# fsvs ci -m "FSM: changed XYZ to support a new ABC and to fix issue 123" somefile
Now when stuff inevitably breaks, you have the ability to quickly see what changed. Not to mention the number of times where it's helped me remember why something changed, or as a quick way to reference "how did I do that before?" type configs.
At work, I call it my "hit by a bus insurance plan". Anyone who can't browse a version control system, look at the comments, do diffs on the configuration files... is probably over-paid.
I wouldn't classify RHEL v5 as "cheap". The cheap shops go with CentOS and pay nothing. The annual cost for RHEL is far from nothing (although less expensive than Windows - especially once you start factoring in the costs for all of the server apps that you put on top of RHEL).
The real value of RHEL is that they will help you out with things that are not specific to their distro. Unlike, say Microsoft, where any problems with a 3rd party application are pretty much yours and yours alone. RH is small enough to still be hungry for business and the real value of RHEL is in the ecosystem of the applications that run on top of RHEL.
What in the world does religion have to do with morality?
It means, generally, that there is a prevailing wind in the direction of moral behavior being valued. Often lauded as gaining favor with some higher power who does not change what is moral on a whim. The cultural norm is therefore, to act in a moral manner and the morals are fixed and rarely change.
As opposed to a culture where the majority do not believe in a higher power and believe that all morals are relative and can be redefined at will. In which case morality becomes "what is convenient to me and which benefits me". Since there is no higher power (other then obeying those who can punish you), the cultural norm becomes "whatever I can get away with is okay".
Basically, it's the difference between morals that are considered to be absolute and unchanging because they were handed down by $diety - and cultural mores which can shift in the slightest breeze.
Yah, you can cut the rate of bad connections down by about 50%+ if you force the sending host to follow the RFCs.
- Incorrectly formatted HELO/EHLO greeting? 5xx Doesn't catch too many connections as the other end would have to massively screw up in order to trigger the invalid HELO rule.
- Giving a HELO/EHLO that is not a FQDN (fully qualified domain name)? 5xx Many botnets don't follow the FQDN rule and will give a randomly generated HELO name. I've never had a false-positive with checks like this.
- Giving a HELO/EHLO that does not resolve via DNS (see RFC 5321, section 2.3.5 where it talks about this issue in the 1st bullet point)? 5xx or 4xx if there was a DNSFAIL issue
- SPF record says "-all" for the MAIL FROM or HELO lookup and it fails to pass SPF? 5xx (At which point, you're simply following the instructions of the sender. If the record says "-all", they WANT you to reject non-conforming mail.)
- HELO/EHLO which purport to be from your own system? 5xx Know your servers, know who is allowed to put your domain into the HELO/EHLO and boot the pretenders. Easily done in Postfix with a few simple rules.
Most of those are standard checks in Postfix and will greatly reduce the amount of spam that you have to analyze in a more in-depth manner. Which results in a huge CPU/bandwidth savings if you can tell them to bugger off before the DATA command is issued.
I prefer to save block lists for the spam scoring system as there are too many false positives (and sometimes abuses of power) in the DNSBLs. Far safer to score rather then block - although Spamhaus' Zen list is extremely good.
What do you do if you need to use a public computer? A lot of times, computers at places like libraries, college computer labs, etc won't allow you to run any programs which weren't installed by an Admin. If you rely on something like KeePass, don't you run the risk that you won't be able to access one of your passwords when you need to? Also, with KeePass, you run some possibility that once you decrypt the password database, some sort of spyware on the computer might hoover up all your passwords?
a) Don't.
That's pretty much what it boils down to. Personally, I use a set of GPG-encrypted text files to store my passwords, no more then 1 site per file. For the sites that I don't care if I can't get access to them until I can decrypt the text files, I simply generate a random passphrase (completely randomized, not pronounceable at all) and use that.
For sites that I do need to get into, I use a more memorable passphrase.
But really... if you can't trust the computer with your GPG key, do you REALLY want to be logging into a sensitive website using the same computer?
(We really need an open hardware solution like a credit card sized calculator where you type in a 4 digit challenge and get back an 8 digit response that you have to key in. Combined with passwords it would be "good enough" and a big step up from today's systems.)
I don't know about everyone else, but I don't use my work credentials or my root password when I visit sites that look like rockyou.com. They just aren't important enough for me to use secure passwords. Five letters and a digit is more than enough for me to use on most forums, Myspace, and other unimportant sites -- all of whom I don't trust to actually store my passwords in a secure manner. So I am refraining from commenting on the horrible state of passwords when it concerns a horrible state of a website, because I don't think I'm the only one who acts this way.
I just tell a program like EPG or md5 (or some other hash program) to generate a 15-20 random alphanumeric password, use that, and store the result in a text file for throwaway accounts on unimportant sites. Then I have the browser remember the darned thing. Usually I'll GPG encrypt the contents of the text file (along with other information about the site).
If the site is unimportant - it doesn't matter to me if I can't get immediate access to it without decrypting a text file using my GPG key. Doubly so if the program (such as the e-mail program or web browser) can remember the password in exchange for my using a more secure pass phrase to guard all stored passwords. If the computer can remember it - why not use a completely random password?
If you're using complete words in your pass phrase, the combinations are actually a lot smaller then that.
There are roughly 300k words in english and related languages that can easily be typed on an english keyboard. So 3 words is only (300k ^ 3) or about 27,000,000 billion combinations. In reality, it's generally a lot smaller (25k ^ 3) which is only 15625 billion combinations. An 8-char password (approximately 72 possibles per position) is around 722200 billion combinations.
Basically, a randomly generated password is around 6.0 to 6.2 bits of entropy per character. A word is a lot lower, down around 3-4 bits of entropy per character.
Cheap systems can run through a very large volume of brute-force attacks per second now. Especially with the addition of NVIDIA CUDA cards, which are amazingly good at doing brute-force attacks. For md5 passwords, even salted, anything of 8 chars or less can easily be cracked in under a day.
Past a certain salt size (say 16 or 24 bits), having a longer salt really doesn't change things. The attacker is going to have to switch to a brute-force attack in that situation anyway, so having a 32bit vs a 64bit salt isn't a big improvement. Once you get into brute-force, your only hope is that password length and complexity will take too long to crack.
Basically: 8 chars or less, even randomly typeable characters, is pretty much trivial to break in under a day. And that's with a system costing maybe $800. Going with 10-12 characters is going to be safe against all but the most determined adversaries (who have 10k host botnets to throw at the problem).
I had erased MOOIII from memory. I loved MOO1&2, i told my roomate how great the games were, so we went half in on 3 and got it, played it for a few days, and i think i actually threw it away after about a year of it sitting on my shelf. they ruined the best part of the game, massive ship battles!
There was an awesome game hidden inside MOO3. Sadly, it was impossible to play.
I really really wanted to like MOO3 as it brought the concept of terrain and choke-points back into the series. (Unlike late-game MOO2 where you can pretty much fly over/around any worm-holes or nebula without worries and your ship range pretty much makes all systems within range.)
There were some other great concepts deep within MOO3, but it was badly mismanaged and the UI was horrid at presenting those concepts.
At this point, I'm mostly hoping that Stardock will move GalCiv away from the flat 2D plane in their current incarnation and switch to a flattened 3D universe with star lanes.
They don't even do a simple dictionary check. Same is true in the OS from what I've seen so far.
How long has that been built into Linux?
And the old adage "Those who do not understand Unix are condemned to reinvent it, poorly" rings true.
My company wants me to change my pass every 2 months. Guess what happens to the password strength over time.
It's a leftover idea from a bygone decade.
The primary advantage of a required monthly or bi-monthly change is that if a password is compromised, it's only useful for about 1/2 of the expiration period. So it's a way of reducing risk in the case of accidental or nefarious disclosure.
But the big downside is that it requires users to be constantly learning new passwords every month or so. And unless these passwords are automatically assigned, users WILL pick weaker and weaker passwords over time or passwords that fit into an easily remembered sequence. So you really end up back where you started.
Forced password renewal is a valid strategy in a small number of cases. Such as a system which protects billions of dollars in assets or is super super critical to the business. But in those cases, there should be 2-factor authentication in play anyway and the passwords probably only need to be changed every 3-6 months and should be randomly assigned.
For end users? Limit their permissions, force complex passwords, but don't require them to change frequently (*maybe* once every 2 years). Tell them to go ahead and write the passwords down and store them in their wallet next to their credit cards. Which is at least a huge step up from putting it under the keyboard or stuck to the monitor.
Longer passwords are also easier to remember if they are used frequently (at least daily). But for some users, it may take as long as 2-3 weeks for them to remember it without looking.
Of course, this is relevant because in the event of an LHC-created black hole destroying the planet, we will of course launch into space a "lifeboat" containing a judge, defense and plaintiff lawyers, Rusty the Bailiff to keep everyone in line, and one token normal person to be the plaintiff. Justice will be served no matter what the damage to the planet is.
So we'll be acting out the "Forge of God" story?
(End of the book, the young people on the lifeboat style arks are brought to the observation ports in order to watch the destruction. Then they get inducted into the force that is bent on punishing the planet destroyers.)
Looks like they've changed it so that unless you pass it a specific User Agent it won't display anything - anyone know what the user agent is?
I'll bite... (it's been a few years, but the lingo is mostly the same).
"x up" - someone wants to form a fleet, everyone is in a channel (either the corp channel, the alliance channel or a custom channel). The fleet commander (FC) says that they need N people to perform task Y and that you should put an "x" (literally) in the channel. The FC can then right-click on the people who X'd up and add them to the fleet. Which is a lot easier then trying to find people in the "local" list (a list of everyone in the star system or docked at a station).
"module lag" - Weapons and active defenses (active shielding that draws power) and things like tractor beams, warp inhibitors, or speed boosts are all called modules. In a busy fight, you'll press the key associated with said module and find that the server takes anywhere from a few seconds to a few minutes before it registers. Of course, if you're jumping into a system or into a hot fight, your system will lag while it downloads the new location information from the server. Meanwhile, the enemy has probably targeted you and blown you up before your screen clears and you can activate modules.
"e-warp" - When a player disconnects from the server (pulling the plug, going linkdead, etc), their ship will after a few seconds turn and warp away to a random location in the star system. Also known as emergency warp. Not to be confused where a pilot aligns with a distant object and then warps out of the fight in an attempt to get away. Ships don't turn on a dime, they have to first align with their destination before the warp engine can cut in. Emergency warps can also happen if the lag is so bad that the server thinks you've disconnected, even if you really hadn't.
"gates" - All jumps into a system (barring some other tricks such as setting up a jump bridge by sneaking a covert ship into the system ahead of time) come through the small handful of gates. Upon arrival in a system, you'll appear at a few km from the gate in a random direction after which you have to turn/align before you can warp away from the gate. The goal of a gate camp is to catch (tackle) ships that have jumped in so that they can't warp away.
Not sure what else there is to explain.
I once got a shock during enclosure maintenance when I touched a secondary supply that wasn't powered off. It was a minor shock, but that's partly because I was wearing insulated boots and had the other hand in my pocket. (i.e. there was no path to ground.)
I thought the purpose of keeping one hand in your pocket is so that the current doesn't cross the center of the chest cavity and play havoc with your heart. The idea being that the current will travel down one side or the other to the floor.
What was so special about Duke Nukem 3D compared to Doom, Quake, or 3D Realms' own Rise of the Triad?
The humor, the environment, the subtle digs at authority. The first level in DN3D is very memorable, starting out on a roof with Duke muttering about those aliens destroying his ride. Followed up almost immediately by pig cops flying around on hover bikes.
At the time there was a fair amount of interaction with the environment as well. Lots of destructible props scattered around.
Doom was just a "scary" shooter. Quake really didn't have a memorable story line and was mostly a multi-player game. Rise of the Triad never made it onto my radar screen.
P.S. My favorite fight scene in fiction is probably from the story "Gulf" by Robert A. Heinlein. The protagonist is a super-intelligent spy, and he is expecting some sort of trouble from the bad guys; since he is in a public place he figures their first move will be some kind of diversion. The bad guys light off some fireworks, and almost everyone around the spy turns to look in the direction of the bang; two people near the spy do not look and head straight for him. Without hesitating he attacks them, and lays them out instantly, and then walks away as if nothing had happened. I thought that was a lot cooler than a three-page fight scene would have been.
See also most of the Quiller novels by Adam Hall.
Throw the ferret down the hole, see what he comes back with.
I'm fairly certain actually realistic shooters exist. It's just that realistic mechanics, from a player perspective, are extremely boring, except for in a few limited cases (only one I can think of that is fun and isn't at least a bit fantastic or sci-fi is Counter Strike).
Combat is boredom punctuated with moments of pure terror.
(Also a key reason why nobody likes to play defense in a team-oriented FPS game. It's a lot of waiting around during a 15-20 minute match for a target to enter the area that you're defending. Yet two dedicated defenders can hold off multiple attackers for long enough to get reinforcements in place.)
I agree that key management remains an issue. Subversion is the worst popular example, with its habit of storing your passwords in your home directory in plain text, with no expiration and no utility for flushing them.
The primary alternative (and it's a good one) is SSH public keys stored in a ssh-agent process.
(There's simply no other way for SVN to function in a way that keeps it from prompting you for your password at every turn, because there's no such thing as a standard 'password agent' similar to SSH. That's not to say that there couldn't be, but every system rolls their own while OpenSSH is fairly standard. GPG encoding might have worked, but would require reliance on yet another package along with running some sort of GPG key ring. And the SVN developers chose not to rely on security through obscurity by trying to hide the storage of the password. There's simply no easy way to store a plaintext password that has to be fed to another system in a secure manner.)
Key management is truly a bitch, especially when you have a secret (password) that has to be provided to another system in the clear.
This sort of statement is equally dangerous by leading people to believe that just because they are using a strong cipher they are secure. Basically, unless a cryptography expert is designing your entire system, you're going to fuck SOMETHING up. There is no magic bullet.
That something is almost always key management.
(Encryption is simple compared to the complexities involved in keeping key management secure.)
Interestate 795 (the Northwest Expressway) outside of Baltimore, MD did this. But not for high-speed rail (which requires things to be too straight). They did it as part of the Baltimore subway system. The tracks run between the two sections of highway, including a station out at Owings Mills being placed between the two sides.
The major downside from the point-of-view of the passengers... putting your station in the middle of a divided highway means that it's already 25-50 meters away from any useful destination. That station could have been located a lot closer to the Owings Mills mall (just west of the station).
... the marketplace will respond. At those sorts of prices, all of the alternatives, like solar, that are impractical today will be cheap by comparison. I don't think high speed rail will necessarily have anything to do with it, however.
That, is a guarantee.
The big question is, however, "how fast will the price spike and stay elevated?".
If gas prices rise at a rate of say 5-15% per year, things probably won't be too bad and the economic shocks will be minimal. But if it spikes too quickly, people won't have time to react and switch to better alternatives. People will have to cut back in other areas very suddenly, which tends to cause things like recessions and other social problems.
We're running at around $3/gal here in the NYC area. If I was planning out for the next 5-10 years, in a situation where fuel cost is a primary issue (such as evaluating a new vehicle), I'd plan in the $5-$6 per gallon range to be safe. But even then, the price of a more fuel efficient car may be too expensive to compete with a gas guzzler that can be had for 1/2 the cost.
(You can see the same thing when evaluating an office full of 17" CRTs that use about 90W. At current electricity prices of $0.18/kWh, the replacement monitors would have to cost less then $100 to have less then a 4 year payback. Yes it would be better for the environment and the monthly electrical bill to cut that by 3/5, but the near-term outlay of cash has too long of a payback period.)
People generally avoid it because, even during rush hour when an 11-mile trip takes 25-30 minutes by car, using the light rail system will be 50-60 minutes.
It's the problem of too many stops. Buses have the same issue, except that they also fight with traffic. Back when I used to commute from central Pennsylvania up to NYC via Amtrak, the train took close to 4 hours, mostly due to stopping at every podunk little town along the way. They could've shaved at least 40 minutes off of that by skipping the tiny 1 red-light town stops where maybe 2-3 people would get off of a train of 200+.
Now, personally, I think trains are an excellent form of mass transit. They fit in well with suburban architecture (they can go underground if electric is used), the stations are *tiny* compared to airports, and it's easy to build inter-modal and go from city center to city center. The downsides is that you have to lay and maintain track and right of way, and there aren't enough straight sections to allow for high speed rail to work well.
The other problem is that you need a critical mass of people all going in the same direction at roughly the same time. Which is why rail systems like the LIRR work well (a large number of people commute into NYC daily). Or you need a highly localized population density (such as Japan or places like the Netherlands) where everyone lives within walking distance of the various mass-transit solutions. Spread-out suburbs and McMansions where everyone lives as far as possible away from their neighbors are the main problem that causes mass transit to underperform.