Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:The bravest astronaut (Score 1) 50 50

F9 #4 is the one where "a first stage engine acted up", but (contrary to your claim) it is inaccurate to say that "the secondary payload failed to reach orbit". With the loss of one engine from the first stage, the remaining engines burned longer to reach the desired orbit. This was successful (F9 being one of very few rocket boosters capable of mission completion despite an engine loss at any stage of the flight).

HOWEVER, while both payloads successfully made orbit, the secondary payload would have required an additional burn to place it in its intended orbit. The F9 second stage almost certainly could have done this; it had the fuel, and it had the relight capability. However, the primary payload was bound for the ISS, and that means that the secondary payload would need to be placed in a safely different orbit. The confidence that F9's second stage could do so dropped below the extremely high threshold set by NASA (IIRC, it dropped to a mere 95% confidence), so NASA told them not to conduct the second burn. Consequently, the second payload was released in lower-then-designed orbit (though still in orbit) and re-entered after a relatively brief period.

Comment: Re:Ummmm... (Score 1) 243 243

There's better options than PBKDF2, like scrypt. Also, both require you to chose some parameters; PBKDF2 with a salt of String.Empty, hash algorithm of MD5, and iteration count of 1 is... just an MD5-hashed password. Obviously, those are terrible and stupid parameters, but if people were *good* at choosing secure options then this whole thread wouldn't exist. At least scrypt *only* has the work factor, and it's pretty straightforward.

Comment: Re:Security theater questions (Score 1) 243 243

There's generally no way to send the user a secure (i.e. encrypted) message. All you can do is make the token short-lived and hope that nobody is intercepting server-to-server email traffic (and that the user's email account is secure, both from malicious clients and from server-to-client interception). It sucks, but until email encryption of one sort or another becomes more ubiquitous, it's the only workable option.

Comment: Don't encrypt! (Score 1) 243 243

Don't ever store passwords (reversibly) encrypted. Don't even (just) hash them; hash functions are way too fast (and yes, fast is bad here). There should be no way for anybody to get the password out of the info stored in the database, even if they know all your keys.

Use a slow key derivation function instead. PBKDF2 is popular, because it's easy to understand and widely supported; it's basically just taking a value (the password), salting it (you are using a strong, cryptographically random, per-user salt... right?) hashing it, salting the resulting digest again, hashing the salted digest, and repeating the last two steps over and over (tens of thousands of iterations are common). At the end of that, you compare the resulting digest to the value stored in the database; if they match, the user is authenticated. Obviously, don't try implementing this yourself; even simple crypto should always be written by an expert, and you should use the resulting library. There are lots of places to find it, though.

Alternatively, you can use the purpose-built algorithms like scrypt or bcrypt. These are more complex (and less widely implemented) than PBKDF2, but they also offer more advantages against brute forcing, such as requiring a lot of RAM during the computation so you can't build a massively parallel hash-cracking machine (a commodity GPU can do billions of hashes per second in parallel; these algorithms make those parallel attacks harder).

Comment: Re: Fine, I'll explain again (Score 1) 72 72

Not in line with any of SpaceX's launch sites, I think. You could probably find some suitable sites that are reachable on certain launch trajectories, but for most launches that would be a pretty huge diversion. Also, the desert may be clear but the coastlines are generally not, and - at least for the first launches - I think the goal was to avoid having the first stage do its boostback burn towards *anything* inhabited, even if it was expected to fly over the inhabited region a few miles up. That's just a guess though.

Comment: A useful site for tracking SpaceX launch dates (Score 4, Informative) 49 49

For anybody who doesn't know about it, is a neat site that lists upcoming SpaceX missions with countdowns to expected launch times, or estimates where the exact time isn't yet determined. It also has some statistics (though, sadly, they're almost always out of date) about things like launch records, flight times, payload mass, and so on. Obviously not as useful as itself on launch day, but handy for checking when launch day will come (or when, for example, the first flight of a new vehicle is expected). It also has links to info about past launches.

I'm not affiliated with the site in any way (if I were, it'd keep those statistics better up to date) but I thought it might interest some other folks who like to follow SpaceX. Oh, and for the record, the link to tomorrow/today's launch is

Comment: Fine, I'll explain again (Score 4, Informative) 72 72

I'm going to assume you've been doing the /. equivalent of living under a rock, since this question comes up (and gets answered) every single time this topic is discussed, and that's a lot. But what the hell...

Landing on solid ground is, generally, preferable. However, unlike the ocean where you can tell all the boats to get out of a safety zone, land has these inconvenient things like buildings and infrastructure that can't simply be told to stay away for their own safety. Until it was clear how precisely SpaceX could bring the rocket down - and remember, we're talking about something returning from the edge of space, at supersonic speeds, with barely any fuel remaining, in a maneuver that had never been attempted before - it would have been foolish to bring the rocket down anywhere near any inhabited regions. Given the geography around the launch sites they use, that means the ocean is the best bet by far.

Also, sometimes they may not have a choice. The rocket *really* doesn't have a lot of fuel left as it returns, and it's going really, really fast in a direction that is decidedly away from the launch site (but not fast enough to make it all the way around the world, or the second stage wouldn't be needed to actually achieve orbital velocity). SpaceX pulls a lot of cool tricks to guide the rocket's return, like using the stage as a lifting surface (with a truly abysmal lift/drag ratio, I assume, but they're also trying to scrub speed) while controlling it with little folding grid fins (which are quite effective at those speeds). However, at the end of the day, even Falcon 9 may not have the fuel margin to return to the spaceport after launches even though it has enough fuel to launch *somewhere*. The center core of the Falcon Heavy - which flies for much longer than the F9 first stage - will be much too far downrange to boost back to the spaceport in most cases. Thus, for FH's center core, the barge may be the only landing option. Landing on a ship may be harder than landing at a conventional spaceport, but the ship can be almost anywhere there's ocean, while land-based spaceports are not noted for their mobility.

Now, with all that said, the goal is to, eventually, be able to land at the spaceport. The next F9 launch after this one will, according to a cool site called SpaceX Stats, attempt to return to the launch site and land there. This presumably demonstrates that SpaceX has been found to have sufficient precision in the first-stage landing attempts so far for it to be safe to land near people and expensive buildings. I wish them the very best of luck!

Comment: Re:So long, Chrome. (Score 1) 328 328

Oh look, somebody else who apparently doesn't understand how computers work. How do you expect to stop a program[me] from changing a setting in another program[me] when they both run under the same privileges? Chrome has to store its default search provider configuration somewhere. The Java installer can edit that "somewhere" and change the stored configuration. Even if Chrome stores its search configuration in "the cloud", the installer could just use Chrome's cached credentials to change the configuration there.

The only way to change this is if apps don't have the ability to interact with each other's data (something like the isolation/sandboxing used for mobile apps). Anything else, any setting that you (the user) can change, any software running on your behalf can change (whether you want it to or not). I'd expect readers of this site to be able to grasp that, but it keeps coming up so maybe not...

Comment: Re:Not a bad price (Score 1) 192 192

Yeah, the limiting it to only the highest editions of Windows was stupid. It was in XP Pro, and in all editions of Server, but in anything non-server with an Enterprise or Ultimate SKU, it was only in those editions. You could force it to run, in much the same way you can trick Home editions of Windows so they'll join a domain, but it was a hassle.

For what it's worth, Windows has a built-in grep alternative. Findstr.exe (in System32, so it's in the PATH) has slightly different syntax than grep, but it's generally not too hard to switch between them. Windows also has, and has had since DOS, more (it's actually still called, though it's a full 32-bit or 64-bit Windows application), but it's grossly inferior to the options on anything *nix-like.

No equivalents of tail, sed, ssh, curl, whois, etc. or of course *nix shells (Powershell has some cool tricks but it's not the same thing) without installing recompiled versions, though, and those usually don't work as well anyhow.

Comment: Re:Not a bad price (Score 4, Informative) 192 192

XP, being NT, still has the POSIX subsystem. It probably still works with NetBSD's pkgsrc, too.

Also, it's not so useless as you claim; Microsoft themselves used it internally for years to host Hotmail, and right up until Win8.1 it was a viable alternative to Cygwin for anybody with a compatible version of Windows (or who wanted to force it to run anyhow). It handles/handled some things, such as SetUID/SetGID, which Cygwin couldn't (and I believe still can't) emulate, supported case-sensitivity on NTFS (though this could be used to confuse the hell out of Win32 programs), had a couple of different choices of package managers available, and could compile and run most source code intended for *nix systems (third-party compatibility layers added support for some of Linux's extensions to POSIX).

Comment: Re:Pronoun Game Anyone? (Score 2) 122 122

BZZZZT try again. Chrome used (and still uses) its own JS engine, distinct from the built-in JS support in WebKit. Apple didn't let them do that on iOS; they had to use the JS engine that runs in the WebKit that is used in the webview widget, no exceptions. Until a recent iOS version (8, I believe), that WebKit build didn't even use JIT-compiled JavaScript, so it was always a lot slower than Safari.

The JS engine (including both its performance and its behavior) is a hugely important part of a modern browser. By that standard, Chrome-on-iOS definitely wasn't the same thing as Chrome-on-PC.

Comment: Re:HSTS for all government sites (Score 1) 111 111

That's not how HSTS preload works. Or rather, it is, but you're missing a vital step. The preload list won't accept sites that don't specify the "preload" flag in their Strict-Transport-Security header. It ought to go without saying that they won't accept sites which don't serve HTTPS at all...

The max-age and includeSubDomains directives are relevant to browsers. The preload directive is relevant to HSTS preload list maintainers (or rather, to their servers). I guess the government could try coercing the preload list maintainers into including the relevant .gov sites even if they don't meet the requirements for inclusion in the list, but I'm pretty sure that won't happen.

Comment: Re:4000 (Score 3, Interesting) 98 98

Space is really, *really* fucking big. Even low earth orbit at any given altitude is vast; it's literally larger than the surface of the planet. Add altitude shells to that - go up a few KM and you're now a few KM away from anything in the lower shell, even at closest point of approach - and there's an astonishing amount of room in space.

You wouldn't ask if there's room for 4000 more ships on the ocean, despite the fact that there's a lot less ocean and a lot more things crossing it vs. what we have in LEO. You wouldn't even ask if there's room for 4000 more cars on the road in the continental US, despite there being many orders of magnitude less space on US roads than there is in any given LEO altitude. Satellites, functional or not (including debris), move in predictable patterns, and functional satellites have thrusters that allow them to alter or maintain their course.

Agreed, of course, that the satellites should be capable of de-orbiting. But seriously, this "is there enough space in LEO?!?" meme is kind of dumb, at least right now. Let's assume you put each satellite in the middle of 20x20 KM non-overlapping exclusionary zone (omitting the third dimension for now). 400 KM^2 per bird. 1,600,000 KM^2 total. Sounds big, right? You could fit that entire collection, with a hundred thousand square KM left over, into Alaska. Don't get me wrong, Alaska is a big place, but it's not *that* big on the world scale. That's all in one orbital shell.

Comment: Re:Update for IE6 (Score 1) 56 56

Well, MS isn't always the fastest on rolling out security features. Somebody else may need to lead the way. If the Mozilla foundation releases HSTS for Firefox 1.0, it might be possible to persuade MS to do the same for their similarly-aged browser...

Comment: Re:Please support TLS-SRP in IE11 as well (Score 1) 56 56

SRP has a number of problems, the most notable being that there's no way to securely *distribute* (or create) the password without falling back to some other TLS suite, or doing it out of band. This really limits the usefulness of SRP in a browser.

Additionally, I'm not sure how browser support for SRP is supposed to make phishing stop working. If the user still needs to enter their password somewhere, then the phishing attack just has to look like wherever they usually enter their password. Yes, an attacker intercepting the network traffic of a legitimate handshake won't be able to extract any useful info about the password (or be able to replay it blindly), but a phishing site that gets users to enter their password and then sends that password back to the (attacker's) server via whatever mechanism it cares to will still work just fine.

On the other hand, there are definitely places that I'd like to see SRP deployed. A key one, which I consider a lot more important than in browsers, would be as a replacement for NTLM hashes (which are antique and terrible) in SMB (Windows networking, Samba, etc.) traffic. It also makes sense for things like remote desktop or ssh (where, at least for password auth, you assume that both sides already know the password so the distribution problem is taken care of). Once you have it in those places, putting it in the browser seems reasonable enough - after all, enterprises do use IE's built-in support for NTLM auth to web servers, which sucks about as much as NTLM for SMB - but I'd put the other areas ahead of the browser.

365 Days of drinking Lo-Cal beer. = 1 Lite-year