What kind of e-mail service do you use? Or what kind of e-mails do you get?
I'm using Gmail, and maybe 2 or 3 spam emails per month get through to the inbox (of around 1000 spam emails per month in the spam folder). On top of that maybe 1 or 2 legit e-mails are classified as spam per month. With one exception from two years ago (flight confirmation e-mails), none of these false positives are critical; they are usually just advertising from companies I bought something at some point.
I understand that Chromium is open-source, but I am sure there are closed-source bits in Chrome.
Not really in the browser - only the PDF viewer and Flash Player, which are built-in plug-ins that are based on the respective Adobe products (I think), and which you can disable. Oh, and the auto-updater, which is really a separate programme.
Yes, they will be the same. There is actually a service called AccurateRip which compares the hash of your ripped copy with a database of user submitted copies. If it matches several other ripped versions you can be pretty sure it was ripped correctly.
No, mergers also generate efficiencies, and efficiencies are good for everyone. Especially true for vertical mergers (i.e. for firms producing complementary products). Look up "double marginalisation".
Since no one would volunteer to be the victims of such deflation, BitC's are doomed to irrelevancy.
Don't quite agree - I'd be happy to have deflation in Euros as my savings will become worth more.
However, the large expected deflation means that it does not make sense to spend Bitcoins on anything now as the value of a Bitcoin is expected to go up a lot if it becomes a ubiquitous currency. This hoarding behaviour in turn actually stops Bitcoins from becoming a common currency to trade goods in.
Incidentially, this shows that there is a reason why central banks try to keep currencies stable. In practice, they mostly target a small inflation, which is useful to allow nominally sticky prices (such as wages) to adjust downwards in real terms when the economy is in a downturn.
It is not secure at all because of all the reasons Opportunist mentions above:
Allow me to elaborate on the timeline of bank phishing, why this is horribly insecure and how even one time pads failed. I've spent my time in the early/mid 2000s working on this problem for some bigger banks in Europe, and if anyone feels like challenging this court's decision, I'll gladly come as expert witness, just to make this judge look like the clueless person he obviously is.
The first and foremost reason why this is insecure is that all these "security" (I'll use the term loosely here) schemes fail rely on a single channel: The user's computer. Now, I guess it isn't hard to understand that this machine can be compromised. The bank, OTOH, has no way to verify whether the machine they are talking to has been compromised or not. If anything, the bank could retreat on the position that if the user somehow "lost" his credentials or told them to someone else (accidentally, i.e. by using online banking and having a phishing trojan installed on his machine) it is not their fault, but secure it is not.
Now, why "code+question" isn't secure is obvious to anyone who ever dealt with security. Both are reusable and hence if they get lost once they can be used by an attacker at leisure. Now, what could be added is a security feature that ensures that it is indeed the correct user sitting in front of the machine, e.g. by adding a physical security item that cannot be stolen without the user noticing (e.g. a bank card + reader that would have to be attached to the computer), another security feature would be one time pads (where the user has to confirm his identity by a challenge for a once-valid password that would be submitted to him on a separate channel, e.g. paper in the mail). Both have been tried in Europe, both have failed.
The reason for this is that the computer, if compromised, can execute a man in the middle attack. The way this works has been demonstrated plenty of times and I still have my pet "trojan" I wrote for such a demonstration which I would of course gladly bring along. The way it works is rather trivial, allow me to gloat, erh, I mean, elaborate.
What said trojan consists of is a BHO, a browser helper object (for IE, but it works just as well as a plugin for Firefox or any other browser supporting plugins). Now, as we know from plugins that we enjoy, like ad-suppressors, these plugins are very capable of altering the contents of the display, and of course the contents of data submitted. What the plugin does is simply checking who you wanted to transmit money to, and the amount, and changing both in the background while displaying to you what you entered. The workflow runs like this:
1. When viewing your statement, the BHO checks for your balance to see what it can actually steal from you.
2. User enters his intended transaction (e.g. 100 bucks to "Water + Power")
3. BHO transmits "1000 bucks to "Mike Moneymule" to the bank.
4. Bank confirms "you want to transmit 1000 bucks to Mike Moneymule, please confirm this transaction with your one-time key".
5. BHO displays "you want to transmit 100 bucks to W+P, please confirm this transaction with your one-time key".
6. User searches his one-time pad for the requested code and enters it.
7. BHO sends one-time key
8. Bank confirms "Ok, 1000 bucks sent to Mike Moneymule".
9. BHO displays "Ok, 100 bucks sent to W+P".
Of course, this scheme also works like a dream if only code+secure question is used, but it would be a tad bit too sophisticated for this weaker way of authentication, since stealing code+question works just as well and allows the attacker to siphon money when he wants and doesn't need wait for the genuine user to make a transaction.
So what most banks here use now is a second channel for the one time key. When you send your request for transfering those 100 bucks to W+P, yo
As I have mentioned in another comment - even if you increase the time it takes to hash password+salt to 0.05 seconds, this will make an attack very difficult compared to the time it takes to calculate a normal hash. This will allow 10 logins in the same second with only 50% CPU load. I doubt that there are many sites out there that have such a large amount of logins on a single server. By the way, the article doesn't talk about a lot of specialised hardware - just a simple GPU.
Maybe, but since you need to calculate only one hash per login attempt, increasing the time it takes to calculate this hash is fairly negligible in most scenarios. On the other hand, it makes attacks as the one described magnitudes more difficult.
All you're doing is moving the decimal point a few positions when you use an iterative hash. Plus if the server takes a full second to calculate the hash, you're going to have some very pissed off users. What happens when the average server load has a dozen users all logging in at the same time? Each one probably has to wait 6-12 seconds as the server tries to handle calculating the passwords at the same time as getting work done.
OK, if you have a server where you expect that many logins at the same time, just go for a shorter time, say 0.05 s. If you have 10 users logging in within the same second (and where does that happen except at the most high-volume sites?), the server will still be at 50% CPU load only. However, the security will still be magnitudes better than the 50 ns or whatever it takes with a simple hash now. With slow hashing and per-user salt, even short passwords (7 or 8 digits) are pretty well protected. And there is really no reason not to do it.
And that is exactly what is being done essentially.
I was not very verbose - I would call the hashing function "run MD5 1,000,000 times iteratively" a function in its own right, and I would also call it a slow hashing function.
Well, I *was* talking about the NTLM hash obviously (LM hashes are a joke basically). Even though it is much better than the LM hash (especially on passwords longer than 8 characters), it is still very easy to bruteforce (as the article says), in particular compared to better alternatives.
This is really a Windows problem. Windows uses a simple, fast hashing function (I think some version of HMAC). This means that an attacker can churn through many passwords very quickly (apparently billions per second per the article). You should really use a slow hashing function that takes around 0.1 to 1 seconds to calculate one hash on the server. Even a GPU will then take very long! Plus don't forget salt (different per user) against rainbow table attacks, plus key strengthening. Something like bcrypt is pretty good, but scrypt is probably even better as it does not only require a lot of CPU time but also significant memory (making dedicated hardware crackers much more expensive).
If you're hashing a password, use a slow hash, one that can be "stretched" to take seconds of CPU time. If it takes a second of CPU time to hash a password, your attacker is going to need 6622 years of CPU time to break an 8 character A-Z password, whereas you'll need one second to approve a valid user.
Don't try to roll your own slow hash by using many rounds of a fast hash, there are slow hashes that have been designed and reviewed by the security community. bcrypt is one I often hear about, but search around, there are others.
Agree entirely with you. However, you could do even better than bcrypt (which is very good already). The reason is that bcrypt (and the like) only depend on a lot of CPU time, but do not demand a lot of memory. CPU time is much easier to come by than memory, and easier to parallelise. One algorithm that uses both a lot of CPU time and a lot of memory is scrypt. The author estimates that (with the same constraints on the time taken to calculate the derived key from the password) scrypt is typically at least 30 times more expensive to an attacker than bcrypt.
Firefox 3.5 has known security issues that will never be fixed by Mozilla and this has been the situation for several months.
Not quite true. The last version of Firefox 3.5 (3.5.19) was released on 28 April 2011, the same day that the last version of Firefox 3.6 (3.6.17) was released. Since then, Firefox 3.5 has been unsupported, but it is unlikely that any security issues would have come up for 3.5 that would not also apply to 3.6.
Bold move to stop supporting IE7 - but it is the only way to go in the long run. I hope that other websites do the same. Once IE8 support is dropped as well (when IE10 comes out in about one year), everything will be pretty good. People should just upgrade, it is not that hard. And don't say that IE9+ don't work on Windows XP. Just update to Win already 7 - XP is 10 years old! And if you really want to use XP, go for Chrome or Firefox.
I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?
Regarding Chrome specifically, it is very simple. Virtually nobody has an old version of Chrome as it gets updated automatically (and this really works - look at the statistics two weeks after a new version came out). So just test against stable, beta and dev.
These days you can't get a cheap monitor with 1200+ vertical pixels.
Yes, you can. Virtually every screen can have more than this - mine has 1650 vertical pixels, and 1050 horizontal pixels. Just turn it 90 degrees. Seriously, for almost everything I do except watching videos, a 9:16 screen is better than a 16:9 screen. Actually, I have two vertical screens next to each other. I can wholeheartedly recommend it.
I for one, would not by a b/w device in this age anymore. I know the Kindle has it as well, but I think you really need colour for web browsing. Just for this reason alone, I think that this will not sell a lot. (Although I have to admit that I did not look at any videos demonstrating the UI, maybe they found a way of making it look good anyway.)
I was under the impression that the sea level is rising a few mm every year. Seems also quite logical with global warming both increasing the volume of the water and melting ice.
Slashdot Mirror
Half my email ends up in a SPAM bucket.
What kind of e-mail service do you use? Or what kind of e-mails do you get?
I'm using Gmail, and maybe 2 or 3 spam emails per month get through to the inbox (of around 1000 spam emails per month in the spam folder). On top of that maybe 1 or 2 legit e-mails are classified as spam per month. With one exception from two years ago (flight confirmation e-mails), none of these false positives are critical; they are usually just advertising from companies I bought something at some point.
Call it "Nautilus File Browser". "Synaptic Software Installation". Etc.
I understand that Chromium is open-source, but I am sure there are closed-source bits in Chrome.
Not really in the browser - only the PDF viewer and Flash Player, which are built-in plug-ins that are based on the respective Adobe products (I think), and which you can disable. Oh, and the auto-updater, which is really a separate programme.
Yes, they will be the same. There is actually a service called AccurateRip which compares the hash of your ripped copy with a database of user submitted copies. If it matches several other ripped versions you can be pretty sure it was ripped correctly.
Mod up parent who I believe is the product manager of Firefox.
Vertical mergers (like the MS-Skype merger) do not remove competition!
No, mergers also generate efficiencies, and efficiencies are good for everyone. Especially true for vertical mergers (i.e. for firms producing complementary products). Look up "double marginalisation".
Since no one would volunteer to be the victims of such deflation, BitC's are doomed to irrelevancy.
Don't quite agree - I'd be happy to have deflation in Euros as my savings will become worth more.
However, the large expected deflation means that it does not make sense to spend Bitcoins on anything now as the value of a Bitcoin is expected to go up a lot if it becomes a ubiquitous currency. This hoarding behaviour in turn actually stops Bitcoins from becoming a common currency to trade goods in.
Incidentially, this shows that there is a reason why central banks try to keep currencies stable. In practice, they mostly target a small inflation, which is useful to allow nominally sticky prices (such as wages) to adjust downwards in real terms when the economy is in a downturn.
It is not secure at all because of all the reasons Opportunist mentions above:
Allow me to elaborate on the timeline of bank phishing, why this is horribly insecure and how even one time pads failed. I've spent my time in the early/mid 2000s working on this problem for some bigger banks in Europe, and if anyone feels like challenging this court's decision, I'll gladly come as expert witness, just to make this judge look like the clueless person he obviously is.
The first and foremost reason why this is insecure is that all these "security" (I'll use the term loosely here) schemes fail rely on a single channel: The user's computer. Now, I guess it isn't hard to understand that this machine can be compromised. The bank, OTOH, has no way to verify whether the machine they are talking to has been compromised or not. If anything, the bank could retreat on the position that if the user somehow "lost" his credentials or told them to someone else (accidentally, i.e. by using online banking and having a phishing trojan installed on his machine) it is not their fault, but secure it is not.
Now, why "code+question" isn't secure is obvious to anyone who ever dealt with security. Both are reusable and hence if they get lost once they can be used by an attacker at leisure. Now, what could be added is a security feature that ensures that it is indeed the correct user sitting in front of the machine, e.g. by adding a physical security item that cannot be stolen without the user noticing (e.g. a bank card + reader that would have to be attached to the computer), another security feature would be one time pads (where the user has to confirm his identity by a challenge for a once-valid password that would be submitted to him on a separate channel, e.g. paper in the mail). Both have been tried in Europe, both have failed.
The reason for this is that the computer, if compromised, can execute a man in the middle attack. The way this works has been demonstrated plenty of times and I still have my pet "trojan" I wrote for such a demonstration which I would of course gladly bring along. The way it works is rather trivial, allow me to gloat, erh, I mean, elaborate.
What said trojan consists of is a BHO, a browser helper object (for IE, but it works just as well as a plugin for Firefox or any other browser supporting plugins). Now, as we know from plugins that we enjoy, like ad-suppressors, these plugins are very capable of altering the contents of the display, and of course the contents of data submitted. What the plugin does is simply checking who you wanted to transmit money to, and the amount, and changing both in the background while displaying to you what you entered. The workflow runs like this:
1. When viewing your statement, the BHO checks for your balance to see what it can actually steal from you.
2. User enters his intended transaction (e.g. 100 bucks to "Water + Power")
3. BHO transmits "1000 bucks to "Mike Moneymule" to the bank.
4. Bank confirms "you want to transmit 1000 bucks to Mike Moneymule, please confirm this transaction with your one-time key".
5. BHO displays "you want to transmit 100 bucks to W+P, please confirm this transaction with your one-time key".
6. User searches his one-time pad for the requested code and enters it.
7. BHO sends one-time key
8. Bank confirms "Ok, 1000 bucks sent to Mike Moneymule".
9. BHO displays "Ok, 100 bucks sent to W+P".
Of course, this scheme also works like a dream if only code+secure question is used, but it would be a tad bit too sophisticated for this weaker way of authentication, since stealing code+question works just as well and allows the attacker to siphon money when he wants and doesn't need wait for the genuine user to make a transaction.
So what most banks here use now is a second channel for the one time key. When you send your request for transfering those 100 bucks to W+P, yo
And what is the advantage over IPv6? In fact, what is different of your "IPv5" except the location and the number of of the additional bits?
As I have mentioned in another comment - even if you increase the time it takes to hash password+salt to 0.05 seconds, this will make an attack very difficult compared to the time it takes to calculate a normal hash. This will allow 10 logins in the same second with only 50% CPU load. I doubt that there are many sites out there that have such a large amount of logins on a single server. By the way, the article doesn't talk about a lot of specialised hardware - just a simple GPU.
Maybe, but since you need to calculate only one hash per login attempt, increasing the time it takes to calculate this hash is fairly negligible in most scenarios. On the other hand, it makes attacks as the one described magnitudes more difficult.
All you're doing is moving the decimal point a few positions when you use an iterative hash. Plus if the server takes a full second to calculate the hash, you're going to have some very pissed off users. What happens when the average server load has a dozen users all logging in at the same time? Each one probably has to wait 6-12 seconds as the server tries to handle calculating the passwords at the same time as getting work done.
OK, if you have a server where you expect that many logins at the same time, just go for a shorter time, say 0.05 s. If you have 10 users logging in within the same second (and where does that happen except at the most high-volume sites?), the server will still be at 50% CPU load only. However, the security will still be magnitudes better than the 50 ns or whatever it takes with a simple hash now. With slow hashing and per-user salt, even short passwords (7 or 8 digits) are pretty well protected. And there is really no reason not to do it.
Yes
And that is exactly what is being done essentially.
I was not very verbose - I would call the hashing function "run MD5 1,000,000 times iteratively" a function in its own right, and I would also call it a slow hashing function.
Well, I *was* talking about the NTLM hash obviously (LM hashes are a joke basically). Even though it is much better than the LM hash (especially on passwords longer than 8 characters), it is still very easy to bruteforce (as the article says), in particular compared to better alternatives.
This is really a Windows problem. Windows uses a simple, fast hashing function (I think some version of HMAC). This means that an attacker can churn through many passwords very quickly (apparently billions per second per the article). You should really use a slow hashing function that takes around 0.1 to 1 seconds to calculate one hash on the server. Even a GPU will then take very long! Plus don't forget salt (different per user) against rainbow table attacks, plus key strengthening. Something like bcrypt is pretty good, but scrypt is probably even better as it does not only require a lot of CPU time but also significant memory (making dedicated hardware crackers much more expensive).
If you're hashing a password, use a slow hash, one that can be "stretched" to take seconds of CPU time. If it takes a second of CPU time to hash a password, your attacker is going to need 6622 years of CPU time to break an 8 character A-Z password, whereas you'll need one second to approve a valid user.
Don't try to roll your own slow hash by using many rounds of a fast hash, there are slow hashes that have been designed and reviewed by the security community. bcrypt is one I often hear about, but search around, there are others.
Agree entirely with you. However, you could do even better than bcrypt (which is very good already). The reason is that bcrypt (and the like) only depend on a lot of CPU time, but do not demand a lot of memory. CPU time is much easier to come by than memory, and easier to parallelise. One algorithm that uses both a lot of CPU time and a lot of memory is scrypt. The author estimates that (with the same constraints on the time taken to calculate the derived key from the password) scrypt is typically at least 30 times more expensive to an attacker than bcrypt.
More information on scrypt here: http://www.tarsnap.com/scrypt.html
Firefox 3.5 has known security issues that will never be fixed by Mozilla and this has been the situation for several months.
Not quite true. The last version of Firefox 3.5 (3.5.19) was released on 28 April 2011, the same day that the last version of Firefox 3.6 (3.6.17) was released. Since then, Firefox 3.5 has been unsupported, but it is unlikely that any security issues would have come up for 3.5 that would not also apply to 3.6.
Once 3.6.18 comes out though, you are right.
Bold move to stop supporting IE7 - but it is the only way to go in the long run. I hope that other websites do the same. Once IE8 support is dropped as well (when IE10 comes out in about one year), everything will be pretty good. People should just upgrade, it is not that hard. And don't say that IE9+ don't work on Windows XP. Just update to Win already 7 - XP is 10 years old! And if you really want to use XP, go for Chrome or Firefox.
I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?
Regarding Chrome specifically, it is very simple. Virtually nobody has an old version of Chrome as it gets updated automatically (and this really works - look at the statistics two weeks after a new version came out). So just test against stable, beta and dev.
2500 W? Where do they plug it in?
In any normal socket? My kettle even has 3.0 kW
These days you can't get a cheap monitor with 1200+ vertical pixels.
Yes, you can. Virtually every screen can have more than this - mine has 1650 vertical pixels, and 1050 horizontal pixels. Just turn it 90 degrees. Seriously, for almost everything I do except watching videos, a 9:16 screen is better than a 16:9 screen. Actually, I have two vertical screens next to each other. I can wholeheartedly recommend it.
I can't believe no one has picked up on this yet:
"It will be available in black and white"
I for one, would not by a b/w device in this age anymore. I know the Kindle has it as well, but I think you really need colour for web browsing. Just for this reason alone, I think that this will not sell a lot. (Although I have to admit that I did not look at any videos demonstrating the UI, maybe they found a way of making it look good anyway.)
I was under the impression that the sea level is rising a few mm every year. Seems also quite logical with global warming both increasing the volume of the water and melting ice.