Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Refine your definition of spam (Score 2) 265

by christopherfinke (#48133021) Attached to: Ask Slashdot: Why Can't Google Block Spam In Gmail?

Some of it is UCE, partially due to a couple dingbats with similar names who apparently think my gmail account belongs to them.

This isn't spam; at worst, it's bacn with a case of mistaken identity.

As someone whose full-time job is preventing spam (I work on Akismet, which checks about 380MM Web comments per day for spam), my general response to these kinds of questions is this: Fighting spam is hard because what's spam for you is not always spam for someone else, and spammers are continually changing tactics -- what worked to prevent spam yesterday may not work as well tomorrow, so it's a constantly moving target.

In my experience, GMail's filter is just ok. I see about 50 spam per day end up in my spam folder, 3 or 4 that make it to my inbox, and maybe one false positive per month (when I bother checking). That's a 94% success rate with a 0.3% FP rate (based on my ham email activity), assuming that they're not instantly discarding blatant spam that wouldn't even merit ending up in the spam folder (which they very well might be doing). If Akismet had this same success rate filtering comments on my blog, I'd have to manually mark 230 comments as spam each day instead of Akismet's missed spam average of about one per day. I don't complain about it though, since fighting spam is hard (see above).

Comment: Re:Hashed and salted is obsolete (Score 1) 80

by SUB7IME (#43565167) Attached to: LivingSocial Hacked: 50 Million Users Exposed

Also, the whole point is that key derivation is slow. Of course the "secret from which keys are derived" is available (it is necessarily so; it's stored, along with the cost factor, as part of bcrypt's output, for example). But the fact that you have to through 2^N iterations, where N is usually >= 10, throws a meaningful speedbump in front of high-speed cracking. Now instead of brute forcing any given 7-character alphanumeric case-sensitive passwords in ~half an hour, it'll take you > 20 days on average.

Comment: Re:Hashed and salted is obsolete (Score 1) 80

by SUB7IME (#43564919) Attached to: LivingSocial Hacked: 50 Million Users Exposed

The key derivation functions can be literally several orders of magnitude harder to brute force. And their difficulty can be chosen with simple parameters, with sane defaults. There is really no comparison between a singly salted hashed password and bcrypt/scrypt.

Check out table 1 in this paper to get a sense: https://www.tarsnap.com/scrypt/scrypt.pdf

Comment: Re:Hashed and salted is obsolete (Score 1) 80

by SUB7IME (#43564537) Attached to: LivingSocial Hacked: 50 Million Users Exposed

Assuming the cracker has access to the salt and a GPU, the only thing keeping users safe now is the entropy inherent in the passwords they chose.

It doesn't have to be like that. Instead of plugging in Good Salted Hashed Password Library, you can plug in Bcrypt Library or Scrypt Library *and protect even the users who chose bad passwords*.

Comment: Re:Hashed and salted is obsolete (Score 1) 80

by SUB7IME (#43564447) Attached to: LivingSocial Hacked: 50 Million Users Exposed

Can you explain this a bit more?

If the hackers didn't get the salt, and only have the salted hashes, and let's say the salt is, say, a 20 character random phrase using numbers, letters and symbols, what is the weak spot?

I'm sure many /. users are implementing systems like this using salted hashes, so if there's an inherent weakness (other than the salt becoming exposed) I'm sure it would be useful if there was a straightforward explanation.

The size of the salt is relevant only insofar as you want to be sure that each user has their own unique salt. The salt is stored in plaintext (or, I suppose, it could be encrypted, but then the decryption key must then be stored in an accessible place). The point is that the crackers must be assumed to have recovered the salts.

So now those salts protect you against pre-computed hashes. The cracker has to attempt each password individually. But most people use one of the few thousand most common passwords. And inexpensive modern hardware lets you attempt billions of SHA hashes per second. So... Salted and hashed does very little for you at this point.

Instead of salting and hashing, use a key derivation function (e.g., bcrypt, scrypt).

Comment: Some ideas (Score 1) 203

by VanillaCoke420 (#38407334) Attached to: Ask Slashdot: Technical Advice For a (Fictional) Space Mission?

As for the destination, the moon and Mars are the obvious choices, but what else would make sense?

For our first colony, the Moon or Mars makes sense. The Moon would be the easier choice, while Mars would be much farther away and perhaps be more interesting for that and other reasons. Ganymede or the other two big icy moons of Jupiter would be interesting too. Or maybe the first mission to establish a mining operation on an asteroid?

How long would it take to get there?

Depends. The Moon, a few days. Mars, with current technology around six months, although that could be reduced if you use plasma propulsion for example.

What could be the goals of the mission?

Maybe a precursor/pathfinder mission to prepare for the following big colony missions? Or maybe just a research base?

Any events or tasks that could punctuate an otherwise predictably boring long trip?

Just from our space missions there are a number of problems that has occurred in reality. Problems with heating or cooling, explosions, fires, collisions between ships, problems with carbon-dioxide scrubbing, loss of attitude control... The problems alone that can come up are many, if you add in the danger of space flight, the human factor, computer hardware/software failures. Also, radiation, micrometeorites, the effect of low G on the human body, the possible effects psychologically of living for months in a confined space far away from home, etc. Tasks could include course alterations, scientific experiments and observations, daily maintenance, etc.

Any possible sightseeing for beautiful VFX shots?

On Mars of course you have the Valles Marineris, Olympus Mons, dried up floodbeds, craters, volcanoes, dust deviles, the annual dust storm that pretty much covers up the entire planet... etc. If you establish a base on one of Mars's two moons, Mars itself would be prominent and probably a beautiful sight in the sky. On the Moon, all kinds of interesting things. Mountains, craters, maria, etc.

What would be the crew?

I'm thinking international, no matter if it's a government project or entirely private endeavour. Men and women, of course. For the establishment of a research base, I would have only adults. Could be different on a larger colony mission of course. Artificial intelligence would be part of it, whether it's the ship's computer, robots or intelligent systems built-in in the spacesuits for example.

Chemist who falls in acid is absorbed in work.