asharp

It was my understanding, having read the scrypt paper, that scrypt is significantly more secure then bcrypt (hence its existence).

Not particularly. An attack that leaves the attacker with password hashes is rare, as opposed to regular "brute force" attacks of various flavours.

To be more specific they are dictated by the hashing algorithm and how it is set up.

Say you have something like a straight md5/sha256/etc. It's fairly likely that there exist rainbow tables that will insta(for some reasonable value of insta) crack any reasonable password.

On the other hand, if you use a salted hash you arn't vulnerable to rainbow tables, but an attacker can still try an altogether silly number of passwords per second given enough hardware. (or again, more specifically GPUS against most common salted hashes).

On the other other hand, if you use a memory hard key derivation function (scrypt/etc.), you can quite easily set things up such that even with a ridiculous amount of hardware it is infeasible to launch any sort of attack. The problem then, is that the harder you make it for attackers to attack your passwords, the slower normal logins are for you, affecting scaling.

So at the end of the day you need to weight off how much of a problem this is in the specific circumstances you are in which will then dictate the solution you can provide.

Inject the users public key in as root and have pubkey only logins for root.

Now you are both secure and convenient.

I believe a similar idea (use hmac(url, password) as a password for websites) is used to great effect by a firefox plugin.

Also, please do not use hash(x + y), use hmacs. String concatenation in hashing breaks some of the complexity guarantees and will lead to your hashes getting cracked faster then you'd expect.

"You clearly didn't read the link I directed you at." I do believe your tone is rather counterproductive to the purpose of this forum.

I did in fact read the article, and I do now agree that you only need to send MD5(username:realm:password) to the remote server to do the authentication.

The problem that I do see is that it is trivial for a MITM to either intercept the transaction and force the client into a less secure mode (ie. basic auth), and then read in the password, or else just reuse the auth credentials for another transaction.

I would recommend that you look at http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol and the concept of a "zero knowledge password proof" which seems to be the concept you were looking for.

The problem is that you can't actually be secure. This applies in all real situations. You can, however, be secure enough (ie. you achieve your security goals), with some thought and planning. There is a difference though.

What is expected when you go through airport security is that you will be "secure", ie. absolutely secure. The problem is that this is impossible. There are a myriad of ways that a person can cause untold mayhem in what is arguably one of the safest modern forms of long distance travel. Due to this impossibility, you see the authorities forever imposing tighter and tighter safeguards without any real improvement to safety.

What is done, however, is "secure enough", ie. it achieves the required security objectives (chance of serious injury/death is negligible, chance of being able to hijack a plane is negligible, etc.).

This then leads to a problem when "secure enough" is not "completely secure" in a way that didn't lead to a failure in a security objective. Then you have political pressure to "tighten up security", with no actual need, thus you have what can only be termed "make work" programs that look reasonable but do basically nothing for security.

It seems as though you are correct. http://techcrunch.com/2009/10/13/grooveshark-slips-past-emis... They have signed with some labels and as such can legally play some content. On the other hand, they were recently kicked off android over copyright concerns, so apparently they arn't airtight http://arstechnica.com/gadgets/news/2011/04/google-kicks-gro...

It depends very much on what you want out of life.

Find what you want out of life, then find what you need to get it. Then work towards it.

Long story short, there are some tradeoffs involved. If you want a product that can make stupid amounts of money, it needs to be automated and scalable that provides people something they value in a way they cannot otherwise get it in a fashion such that competition is hard or impossible. It's also a good idea to have a clear income stream. It takes a lot of thought, a lot of effort and a lot of time to produce something like this.

So you need to ask yourself, do I really need the billions of dollars? Or would something more modest be "worth it". You are then a lot less limited in the things you can work on, and can think of other options. Small niche things that can't really be turned into the next blockbuster idea, but still make reasonable returns may still be worth your time if it achieves your goals in life.

Tl;dr: Learn what you want from life. Once you understand that, then you will have have solved this.

Or using a system of time not correlated to the rotation of the planet. (It is convenient though :( )

I believe that the songs they play are properly licensed, much like radio stations. I also believe this cost them a stupidly large amount of money.

So I believe your question can be rephrased "Will the cut the studios ask for be insufficient to bankrupt grooveshark or other streaming media suppliers?"

Long story short, Th isn't actually fissable. It is fertile. You have to use something else (like U235/Pu/etc.) to create a stream of neutrons to turn Th into Pa which decays into U233 (iirc). which is then fissable. (and strangely enough, can be used to convert more Th...)

The problem is if the Pa absorbs another neutron, it no longer produces U233 and so it drops the yeild (and leads to other nasties, etc.).

This is, iirc. why the molten salt reactors are so appealing. You can run the reactor, continuously remove the Pa and let it decay into U233 which you then reintroduce into the reactor.

http://hal.archives-ouvertes.fr/docs/00/04/14/97/PDF/documen... is an interesting link discussing the feasibility of various reactor designs.

Digest mode has the issue that you need the plaintext password on the server side in order to do the authentication.

Salting is a process used in hashing. Hashing converts an input text (ie. a password) into an unintelligible mash of symbols, that cannot be reversed. If they were sending passwords in plaintext, they are not hashing it, as they are able to reverse it. I believe what you meant to say is "They may just be encrypting it, not hashing it".

A slight one if any.

If you store passwords plaintext in the database, a simple SQL injection can dump them out.

If you store passwords encrypted in the database, you need to get the code of the server software in order to extract the keys.

So at the end of the day, it depends on the probability of a complete server compromise vs. the probability of a successful SQL injection.

Surely your joking, Mr. Alterego?

Most certainly agree. Unfortunately, dropping the range limit from "Anywhere on earth" to "From a nearby mountain" doesn't fill me with all that much confidence.

Surprisingly not, mostly due to some very strange bits of the GSM protocol.

Basically, as long as you have enough signal such that the victims handset can hear your commands, you can tell it that you are stronger then any other signal, and the handset will instantly switch to your cell.

What's worse is that there exist secure GSM encryption/etc. standards, however as the cell tower chooses what encryption to use, it is mostly pointless. (I remember watching a video about this. Apparently your phone is meant to show a massive warning if they are using unencrypted GSM. None do).

http://www.youtube.com/watch?v=rXVHPNhsOzo is a good video about this.

Make sure you generate everything you need when processing data in one pass. ie. you take the last 100 data points, (or what have you), turn that into your graph. Then work on the next set of points, etc.

The key to this is to make sure that everything is constant sized. Don't have anything that has to run over every data point you collect.

As an example, you can take the last 5 minutes worth of data points (as a buffer), and then create a single five minute graph. You can then create an average of the 5 minutes worth of points and move that in to a second buffer which would have say an hours worth of points in 5 minute intervals, etc. Each step has a constant sized buffer and will draw in constant time.

Also, when you view your report, only view pregenerated graphs/tables/etc. It just makes things easier on you, and it stops you from having to care particularly about how long it takes to run your analysis.

Virtual machines receive very little entropy from their environment, which is a real problem when entropy is required for the generation of cryptographic keys.

There have been many attacks based upon vulnerabilities which exist due to misunderstandings entropy, and the need for a secure random number generator, for example the mozilla ssl vulnerability and the debian ssh key vulnerability.

I would agree with you that /dev/urandom can be used for one shot passwords, however I would disagree with you that getting in to the habit of using a non secure random number generator as a source of secure entropy is a bad idea and should be discouraged.

I'd also like to point out that "the standard openssl RSA encryption function" last time I checked worked to spec, and does in fact encrypt a symetric key used for AES (By default), using RSA, including proper cryptographic padding of the key using PKCS#1.

I'm not exactly sure why you thought otherwise.

I do agree with your final assertion, though. Unless you know what you're doing, it's very easy to make a mistake.

Why is it taking 17 seconds to load, if the page you are serving them merely contains links?

It still has the same problem that you can't "turn them up" to cope with higher demand over longish periods, which makes dealing with them tricky. They are a good step though.

Similarly if you look underground you will find a mantle hot with radioactivity.

Can you show that the rate of fatality for uranium mining is more then 13630 times the rate of fatality of coal mining per kilogram (or cubic meter)? (Including secondary effects of both)

At the end of the day, that specifically is what we are trying to find out.

From what i've heard, carrier grade nat is stupidly expensive and rather hard to scale nicely at reasonable speeds.

It would be fairly easy to implement say ipv6 in china, as it would be a closed system with everybody getting new gear and everybody in the same "we have no ips" boat.

To be honest, as the internet ecosystem in places such as china is mostly closed, I'd be surprised if they didn't go ipv6 only internally well before the rest of the world switches (what's the point in having a v4 address if everything you care about is on native v6 and you have a 64 gateway for everything that isn't).

Going to be interesting to see.

The candu reactors are thorium. As was AVR... Last I heard there were reactors in india/china using thorium.

All the gen IV reactors I remember are thorium based, however keep in mind that most of the gen IV reactors can be made with uranium, it's just that thorium is a rather nice fuel. Well, if you don't need to build any more nukes, that is.

To be perfectly honest, once you've mined out all of the nuclear materials out of nuclear waste, what you're left with is a fairly standard bundle of heavy metals that we deal with all the time in chemeng. (ie. what do you do to the Cad in Nicads?)

Anything that's fertile can be converted into fuel. Anything that's fissable is fuel. Anything that is usefully radioactive can be used either directly in a reactor or indirectly in betavoltaics and related.

One major problem at the moment is that it's not politically viable to reprocess waste anywhere near completely, and even though waste storage is basically solved in much the same way that the waste storage of garbase is basically solved (Where do you think the toxins go when you throw something else out?), we can't really do either and so you end up with waste just piling up in places where it honestly shouldn't be.

On virtual machines, /dev/urandom contains very little if any entropy.

Basically /dev/random takes entropy from the system and feeds it to you.

/dev/urandom is a psudorandom number generator that reseeds from entropy as it gets it. Ie. if it has no entropy, your random numbers are anything but random.

Not really.

If you take the waste out of a thorium cycle reactor (ie. no fission products with half lifes > 100 hears), burn it down until there is basically nothing left then turn it into glass and stick it underneath solid granite in the middle of the worlds most geologically stable tectonic plate then no. It's not exactly devistation.

Sure. Global warming can kill people for tens of thousands of years to come.

Newer processes produce no fission products with a half life > 100y. https://secure.wikimedia.org/wikipedia/en/wiki/Thorium_fuel_... Proper reprocessing can dramatically reduce the amount of waste produced, and the toxicity therein.

Just generally, but why would you expect insuring a nuclear plant to be any more painful then insuring a pesticide plant/etc? A leaky pesticide plant can easily wipe a town off the map. A leaky dam can wash away a city with ease.

I mean if you screw up your shale oil extraction you can end up with oil/natural gas leaking in to groundwater for hundreds of k's. Similarly with a burst dam at a gold mine, or....

There are large numbers of things that can cause massive ecological damage. A good number of them are that bad that they arn't ever really reported: http://newsdesk.org/2010/06/niger-delta-oil-spills-dwarf-bp-... as they continue on for years. It's just that some of them are easier to use to sell papers then others.

I do not believe that is his definition of safe.

I believe he is using the standard definition of safe, for a power source, which is expected deaths/Twh.