If you pass the output of bcrypt through SHA512 you'll have a hash that is weaker than either bcrypt or SHA512 alone.
Such an extreme statement, with no evidence backing it up. Should I even be taking that serious?
There are two requirements for a hash function used for password storage. The risk that an invalid password is accepted must be small, and it must be difficult to deduce the password from the hash.
If you look carefully at what I wrote, you'll see that the only way it could possibly accept an invalid password was if a collision happened in the SHA512 step. Thus in that respect it is trivially proven that the construction is secure if SHA512 is secure. Additionally I have seen no documentation of any way in which a SHA512 hash would leak information about the input.
Finally if it was true in general that applying a hash function and then applying a hash function again would weaken the security, then iterated hashes would get less secure the more iterations you use.
Those are the reason I have not to believe what you are saying. You have not given me even one reason to believe what you just claimed.
PBKDF2 is a wrapper around whatever hash function you want to use (say SHA-256 / 512, whatever). It was invented by some of the premier cryptographers in the world and has been thoroughly vetted.
However PBKDF2 doesn't even specify how to store information in a database, which can be used for password validation. It's a password based key derivation function. That means it can be used to generate a cryptographic key from a password, the key can be used for such usages as encryption and HMAC. It is not complicated to go from a key derivation function to validating a password with a database, but it is not specified in PBKDF2 how to do so. One seemingly obvious approach for that last step is to compute an HMAC on the password itself, and store that HMAC along with the salt in the password. But is that last step secure? It isn't specified in PBKDF2 what you should do, so that part hasn't been reviewed.
I am not very worried about the usage of PBKDF2 for such purposes though, I am more concerned with the recommendation for using other methods which have had much less review. Last time I tried searching for cryptographic papers on bcrypt, I didn't succeed in finding any.
The biggest problem is that those cryptographic hashes tend to be easily parallelizeable on a commercial GPU, resulting in a brute force attack many times faster than an ordinary CPU.
I still prefer that compared to the alternative of using algorithms that haven't had sufficient review. If you combine the algorithms in a construction that can be proven to be secure, then you may be on to something. For example if you passed the output of bcrypt through SHA512 together with the password, you could probably produce an actual security proof based on an accepted property of SHA512.
I guess a proof can be given for the security of storing salt||h(salt||password||f(salt||password)) with h being a cryptographic hash function with some standard property. Then plug in h=SHA512 and f=bcrypt.
So if you just want to check if your password was leaked, you can download my version and check. If you want to use the list for something else, such as statistics on used passwords or attacking affected users, then you'll need to keep looking for the plaintext version.
You don't store just any hash, you should store one that is expensive to compute, by using PBKDF2, bcrypt, scrypt or similar.
I don't see what is wrong with using a cryptographic hash function, which has had lots of review, like for example SHA256 or SHA512. I'd much rather use a fast hash, which has been reviewed by many cryptographers than a slow one, which has not had as much review.
Making changes that slows down legitimate usage by the same factor as brute forcing is not the kind of improvements I like to see. You can do it, but then you are going to make your service vulnerable to DoS attacks.
Last time this discussion was on slashdot an interesting question was raised about whether you can offload some of the CPU heave calculation to the client, to be performed in javascript. I made a proof of concept, which demonstrates how you can slow down password brute forcing without requiring more CPU usage on the server.
Since then I have thought about another scheme, which I think would be even better. Instead of the client performing calculations that have no purpose other than being slow, why not use those CPU cycles for something that can actually improve the security in other ways. The idea I came up with works as follows:
Client uses sitename, username, and password as input for a cryptographic PRNG
Client uses pseudorandom output as input for a key generation algorithm
Client sends public key of generated keypair to server
Server retrieves a salted hash of the public key from a database
Server verifies that the public key is correct
Client proves that it is in possession of the corresponding secret key
This approach not only requires a CPU intensive calculation to be performed by the client before it even has a value, that the server can compare against the salted hash. It also provides extra security since the password and secret key never reaches the server.
It could be done all in javascript. A different login page could be provided for users without javascript. The version without javascript would then be less secure since the password is sent to the server for validation, it would also be slower, since the server probably has less spare CPU cycles than the client, and during a DoS attacks only users with javscript will be able to login. It could also be done as protocol extension, which would be even faster and even more secure, since then the client code could be native code, and the javascript code couldn't be modified to send password to the server. It is entirely possible to design in such a way that the same entry stored in the database would work with all different methods.
Of course my approaches need to be review before they are used for any real system. Until then I suggest people stick with SHA256 or SHA512.
Technically literate people actually do not visit W3Schools. It's a terrible reference, and only exists so that PHP 'developers' can copy-paste SQL injection vulnerabilities.
I do occasionally find useful information there. I don't do much webprogramming, but I do know when there is a risk of injection vulnerabilities and how to protect against them. When I find information on that site it is usually as a result of searching through Google.
Even bad code examples can be useful to people who know how to write secure code, but are not experts in the specific language. Experience from other areas still helps you spot poor code and improve it.
And you can totally set the TTL on any DNS record, therefore preventing caching.
But in practice that only prevents caching in recursive resolvers, it does not prevent caching in browsers. A lot of browsers will deliberately keep using the result of the first DNS lookup even after it has expired for security reasons.
It's because ASNs do not identify providers, they identify networks. ISPs may own or control any number of individual networks.
But there is no limit on the number of address prefixes and network segments that you can have within the network identified by an AS number. In the case of Comcast you'll find that many of their individually numbered networks are in fact BGP peers with each other. I don't know of any technical reason why they would need multiple AS numbers for that kind of setup. With a proper IGP and a few routers that can push information from the IGP through BGP, they should be able to run those networks under a single AS number.
The cases where there is a technical need for separate AS numbers are when the different networks are not connected, or are so sparsely connected that you will sometimes route traffic between your networks through other providers.
If Comcast always use their own network for traffic between their customers, then they could run it all under a single AS number. If OTOH traffic between two Comcast customers will sometimes be routed outside of the Comcast network through their upstream providers, then those customers do need to be in different networks with different AS numbers. I doubt that Comcast will pay transit providers to handle traffic between Comcast customers.
There is a number of cases where a single company ends up with multiple AS numbers as a result of acquisitions. And once a company does have multiple independent networks for this reason, it doesn't always make sense to merge them. However in the case of Comcast it doesn't look like that is the result of any acquisitions.
BTW. Why are we still using the term ISP, when these days we mostly have connectivity and services separated?
Because connectivity is a service?
And what term would you then use about companies which do not provide connectivity, but provides other services such as websites, e-mail, irc, usenet, etc.
Redirect all requests to a page that says "Your computer has been compromised... blah blah blah. Your internet connection will stop working in N days. Click here to continue to the site you where visiting".
Simple yet effective.
I am sure they would have done something like that if it had been possible. But it is not. Once you hijack the first connection attempt, the browser is going to cache the DNS lookup. Clicking the second link is just going to go back to the hijack page again.
You can get such hijacking mostly working if you do it at the routing level (like most hotspot providers do). But you cannot hijack the connection at the routing level, when you only control DNS.
Also, keep in mind that most large ISPs have numerous ASNs. Comcast, for example, has somewhere around 50.
No wonder the AS numbers are running out. I cannot imagine any technical reason Comcast would need that many AS numbers. But 50 AS numbers for a single ISP has got to be unusual. I would guess there are too many ISPs in the world for them to have that many AS numbers each.
Maybe it could just redirect them to a page that tells them they should contact their Internet Service Provider for assistance fixing their DNS.
Sensible idea. But actually if each ISP set up the page instead, it could be customized for that ISP, which in some sense would be even better. All the ISP would have to do is to route the IPs of the malicious DNS servers to one machine which they control themselves and have that reply with the same IP address to every query.
BTW. Why are we still using the term ISP, when these days we mostly have connectivity and services separated?
Also it would set a really bad precedent for the FBI to start redirecting internet traffic without a warrant.
But it wouldn't be FBI that redirected the traffic. It would be the malware that redirected it, FBI would just be in control of where it got redirected to. And actually I read somewhere that FBI wasn't even doing this themselves, they left the technical part to ISC.
Except once Red Hat is using a Microsoft-signed boot loader, most server admins will just install and go and not worry that Microsoft can withdraw that at any time.
And you think admins will allow the BIOS to communicate over the network?
Actually I didn't realize I was affected by this bug until a few minutes ago, when I used strace to see why firefox was using up all the time on one of my cores.
You don't need a leap second in order for that to happen. Firefox does that regularly.
If someone could explain to me why x86 architecture is suddenly named x32
It's not. X32 is the name of a programming model, not an architecture. And the X32 programming model cannot be used on the x86 architecture, X32 is a programming model for the AMD64 architecture.
The most important aspect of a programming model for C is that it defines the sizes of basic types like char, short, int, long, and pointers. Many other aspects follow more or less directly from the sizes of those types. X32 is unusual in that it is 64 bit code, but pointers are only 32 bits. When a pointer is in a CPU register the lower 32 bits is the actual value, and the upper 32 bits are always zero.
Not a trick question - but now you're exactly where you were before you tried to fix it...
No. You know something you didn't know before you tried it. Use that knowledge to research the newly identified problem.
In most cases the update goes fine and you won't need to spend more time on it. In the rare cases where the update does break, you'll have to spend some more time to work out all the problems.
If the only difference between the old and the new kernel is the few lines of changes to fix a known bug, then it is highly unlikely to introduce new problems. If however you switch to a new kernel, which not only has the bugfix you need, but also has a ton of new features as well as a rewritten version of a subsystem that you heavily depend on, then the update is more likely to introduce problems.
This is why you will see people starting out from one version and then keep applying bugfixes and nothing else.
i suppose if you could retransmit the encrypted message on an extremely short delay and get it to accept your signal because it is the strongest one, you probably could introduce an error into its position calculation, and continuing to do this over time eventually cause it to go off-course.
Exactly.
it seems even with a challenge/response such as the ggp mentioned, if the enemy can delay the signal by even a fraction of a second, by retransmitting a stronger version, it could throw off the gps calculations.
The point is that the receiver knows what roundtrip time it got. The adversary can only delay the signal, not speed it up. So the receiver will know that it is within a ball of a certain radius around the satellite. That's a huge ball, several times larger than the Earth. However by having this done against multiple satellites means you'll know your position to be within the overlap between multiple such balls. If you combine that with a somewhat reliable measurement of altitude based on air pressure, you can narrow down the position. And most importantly, you will know how accurate the position is. An attacker can then only make the measurements less accurate, effectively the same as jamming the signal altogether.
The reason the adversary can only delay the signal is that the legitimate signal would take the fastest possible path. It is not physically possible to send the signal faster than c. If the legitimate signal had not been radiowaves but for example photons in an optic fibre, then speeding up the signal would be possible to an adversary. Some of the suggestions on how to attack flawed quantum crypto hardware involves using a line of sight radio link to speed up the signal in order to compensate for the latency introduced by the eavesdropping.
And military GPS signals are encrypted, specifically to prevent spoofing.
Encryption doesn't prevent spoofing. When people who thinks it does are involved with designing cryptographic systems we end up with insecure systems that are broken the first time somebody knowledgeable looks at it.
You can add message-authentication-codes or digital signatures to your data. That will ensure the data is authentic, but it won't stop replay attacks.
If you replay the authentic signals a little bit delayed and with a little bit more power than the authentic signal, you can throw off the navigation even without knowing the actual meaning of the signal.
To protect against that sort of attack, you are going to need a challenge response protocol. The receive will need to send a signal to the satellite, and the satellite will need to respond. The roundtrip time will give the receiver a maximum distance between itself and the satellite. With a few such maximum distances the position can be narrowed down.
The code creates a variable called v of type struct s, in which the field v is initialized with the value 0. There is a different syntax for such initializations in which you just list all the values for individual fields. The other syntax is supported in both C and C++, but it is less readable, and it has the drawback that changing the definition of the struct changes the semantics of the initialization.
I could have written struct s v={0}; which would initialize the first field with value 0. If p was the first field, it would do the same. But now when you read the code, you won't know which field is being initialized. And if the struct is changed such that p is no longer first, the code will no longer do what it used to do.
You can basically take your existing C code and compile it with a C++ compiler in C++ mode, and with a very few exceptions it will compile and work just fine.
I tried that a while ago. It doesn't even compile. I get this error message
error: expected primary-expression before ‘.’ token
I have no idea how to fix that error. The line which triggers it looks like struct s v={.p=0}; AFAIK there is no C++ equivalent for this.
Slashdot Mirror
Such an extreme statement, with no evidence backing it up. Should I even be taking that serious?
There are two requirements for a hash function used for password storage. The risk that an invalid password is accepted must be small, and it must be difficult to deduce the password from the hash.
If you look carefully at what I wrote, you'll see that the only way it could possibly accept an invalid password was if a collision happened in the SHA512 step. Thus in that respect it is trivially proven that the construction is secure if SHA512 is secure. Additionally I have seen no documentation of any way in which a SHA512 hash would leak information about the input.
Finally if it was true in general that applying a hash function and then applying a hash function again would weaken the security, then iterated hashes would get less secure the more iterations you use.
Those are the reason I have not to believe what you are saying. You have not given me even one reason to believe what you just claimed.
However PBKDF2 doesn't even specify how to store information in a database, which can be used for password validation. It's a password based key derivation function. That means it can be used to generate a cryptographic key from a password, the key can be used for such usages as encryption and HMAC. It is not complicated to go from a key derivation function to validating a password with a database, but it is not specified in PBKDF2 how to do so. One seemingly obvious approach for that last step is to compute an HMAC on the password itself, and store that HMAC along with the salt in the password. But is that last step secure? It isn't specified in PBKDF2 what you should do, so that part hasn't been reviewed.
I am not very worried about the usage of PBKDF2 for such purposes though, I am more concerned with the recommendation for using other methods which have had much less review. Last time I tried searching for cryptographic papers on bcrypt, I didn't succeed in finding any.
I still prefer that compared to the alternative of using algorithms that haven't had sufficient review. If you combine the algorithms in a construction that can be proven to be secure, then you may be on to something. For example if you passed the output of bcrypt through SHA512 together with the password, you could probably produce an actual security proof based on an accepted property of SHA512.
I guess a proof can be given for the security of storing salt||h(salt||password||f(salt||password)) with h being a cryptographic hash function with some standard property. Then plug in h=SHA512 and f=bcrypt.
I don't want to take part in distributing the plaintext version, so what I did instead was as follows.
So if you just want to check if your password was leaked, you can download my version and check. If you want to use the list for something else, such as statistics on used passwords or attacking affected users, then you'll need to keep looking for the plaintext version.
I don't see what is wrong with using a cryptographic hash function, which has had lots of review, like for example SHA256 or SHA512. I'd much rather use a fast hash, which has been reviewed by many cryptographers than a slow one, which has not had as much review.
Making changes that slows down legitimate usage by the same factor as brute forcing is not the kind of improvements I like to see. You can do it, but then you are going to make your service vulnerable to DoS attacks.
Last time this discussion was on slashdot an interesting question was raised about whether you can offload some of the CPU heave calculation to the client, to be performed in javascript. I made a proof of concept, which demonstrates how you can slow down password brute forcing without requiring more CPU usage on the server.
Since then I have thought about another scheme, which I think would be even better. Instead of the client performing calculations that have no purpose other than being slow, why not use those CPU cycles for something that can actually improve the security in other ways. The idea I came up with works as follows:
This approach not only requires a CPU intensive calculation to be performed by the client before it even has a value, that the server can compare against the salted hash. It also provides extra security since the password and secret key never reaches the server.
It could be done all in javascript. A different login page could be provided for users without javascript. The version without javascript would then be less secure since the password is sent to the server for validation, it would also be slower, since the server probably has less spare CPU cycles than the client, and during a DoS attacks only users with javscript will be able to login. It could also be done as protocol extension, which would be even faster and even more secure, since then the client code could be native code, and the javascript code couldn't be modified to send password to the server. It is entirely possible to design in such a way that the same entry stored in the database would work with all different methods.
Of course my approaches need to be review before they are used for any real system. Until then I suggest people stick with SHA256 or SHA512.
I do occasionally find useful information there. I don't do much webprogramming, but I do know when there is a risk of injection vulnerabilities and how to protect against them. When I find information on that site it is usually as a result of searching through Google.
Even bad code examples can be useful to people who know how to write secure code, but are not experts in the specific language. Experience from other areas still helps you spot poor code and improve it.
And you can totally set the TTL on any DNS record, therefore preventing caching.
But in practice that only prevents caching in recursive resolvers, it does not prevent caching in browsers. A lot of browsers will deliberately keep using the result of the first DNS lookup even after it has expired for security reasons.
But there is no limit on the number of address prefixes and network segments that you can have within the network identified by an AS number. In the case of Comcast you'll find that many of their individually numbered networks are in fact BGP peers with each other. I don't know of any technical reason why they would need multiple AS numbers for that kind of setup. With a proper IGP and a few routers that can push information from the IGP through BGP, they should be able to run those networks under a single AS number.
The cases where there is a technical need for separate AS numbers are when the different networks are not connected, or are so sparsely connected that you will sometimes route traffic between your networks through other providers.
If Comcast always use their own network for traffic between their customers, then they could run it all under a single AS number. If OTOH traffic between two Comcast customers will sometimes be routed outside of the Comcast network through their upstream providers, then those customers do need to be in different networks with different AS numbers. I doubt that Comcast will pay transit providers to handle traffic between Comcast customers.
There is a number of cases where a single company ends up with multiple AS numbers as a result of acquisitions. And once a company does have multiple independent networks for this reason, it doesn't always make sense to merge them. However in the case of Comcast it doesn't look like that is the result of any acquisitions.
BTW. Why are we still using the term ISP, when these days we mostly have connectivity and services separated?
Because connectivity is a service?
And what term would you then use about companies which do not provide connectivity, but provides other services such as websites, e-mail, irc, usenet, etc.
Redirect all requests to a page that says "Your computer has been compromised ... blah blah blah. Your internet connection will stop working in N days. Click here to continue to the site you where visiting".
Simple yet effective.
I am sure they would have done something like that if it had been possible. But it is not. Once you hijack the first connection attempt, the browser is going to cache the DNS lookup. Clicking the second link is just going to go back to the hijack page again.
You can get such hijacking mostly working if you do it at the routing level (like most hotspot providers do). But you cannot hijack the connection at the routing level, when you only control DNS.
Also, keep in mind that most large ISPs have numerous ASNs. Comcast, for example, has somewhere around 50.
No wonder the AS numbers are running out. I cannot imagine any technical reason Comcast would need that many AS numbers. But 50 AS numbers for a single ISP has got to be unusual. I would guess there are too many ISPs in the world for them to have that many AS numbers each.
Sensible idea. But actually if each ISP set up the page instead, it could be customized for that ISP, which in some sense would be even better. All the ISP would have to do is to route the IPs of the malicious DNS servers to one machine which they control themselves and have that reply with the same IP address to every query.
BTW. Why are we still using the term ISP, when these days we mostly have connectivity and services separated?
But it wouldn't be FBI that redirected the traffic. It would be the malware that redirected it, FBI would just be in control of where it got redirected to. And actually I read somewhere that FBI wasn't even doing this themselves, they left the technical part to ISC.
And you think admins will allow the BIOS to communicate over the network?
You don't need a leap second in order for that to happen. Firefox does that regularly.
Look at the spec. You only have to read the first sentence. The chapter on X32 starts
It's not. X32 is the name of a programming model, not an architecture. And the X32 programming model cannot be used on the x86 architecture, X32 is a programming model for the AMD64 architecture.
The most important aspect of a programming model for C is that it defines the sizes of basic types like char, short, int, long, and pointers. Many other aspects follow more or less directly from the sizes of those types. X32 is unusual in that it is 64 bit code, but pointers are only 32 bits. When a pointer is in a CPU register the lower 32 bits is the actual value, and the upper 32 bits are always zero.
No. You know something you didn't know before you tried it. Use that knowledge to research the newly identified problem.
In most cases the update goes fine and you won't need to spend more time on it. In the rare cases where the update does break, you'll have to spend some more time to work out all the problems.
If the only difference between the old and the new kernel is the few lines of changes to fix a known bug, then it is highly unlikely to introduce new problems. If however you switch to a new kernel, which not only has the bugfix you need, but also has a ton of new features as well as a rewritten version of a subsystem that you heavily depend on, then the update is more likely to introduce problems.
This is why you will see people starting out from one version and then keep applying bugfixes and nothing else.
Exactly.
The point is that the receiver knows what roundtrip time it got. The adversary can only delay the signal, not speed it up. So the receiver will know that it is within a ball of a certain radius around the satellite. That's a huge ball, several times larger than the Earth. However by having this done against multiple satellites means you'll know your position to be within the overlap between multiple such balls. If you combine that with a somewhat reliable measurement of altitude based on air pressure, you can narrow down the position. And most importantly, you will know how accurate the position is. An attacker can then only make the measurements less accurate, effectively the same as jamming the signal altogether.
The reason the adversary can only delay the signal is that the legitimate signal would take the fastest possible path. It is not physically possible to send the signal faster than c. If the legitimate signal had not been radiowaves but for example photons in an optic fibre, then speeding up the signal would be possible to an adversary. Some of the suggestions on how to attack flawed quantum crypto hardware involves using a line of sight radio link to speed up the signal in order to compensate for the latency introduced by the eavesdropping.
Look up malleability. There are plenty of papers on the subject.
According to some sources the end of Gaddafi's regime was indirectly caused by Wikileaks.
Encryption doesn't prevent spoofing. When people who thinks it does are involved with designing cryptographic systems we end up with insecure systems that are broken the first time somebody knowledgeable looks at it.
You can add message-authentication-codes or digital signatures to your data. That will ensure the data is authentic, but it won't stop replay attacks.
If you replay the authentic signals a little bit delayed and with a little bit more power than the authentic signal, you can throw off the navigation even without knowing the actual meaning of the signal.
To protect against that sort of attack, you are going to need a challenge response protocol. The receive will need to send a signal to the satellite, and the satellite will need to respond. The roundtrip time will give the receiver a maximum distance between itself and the satellite. With a few such maximum distances the position can be narrowed down.
If that happens I will give my code another try with g++. Then it might become feasible for me to write code, which compiles with both C and C++.
Another comment says this feature is not in any C++ standard. I don't know which is true.
The code creates a variable called v of type struct s, in which the field v is initialized with the value 0. There is a different syntax for such initializations in which you just list all the values for individual fields. The other syntax is supported in both C and C++, but it is less readable, and it has the drawback that changing the definition of the struct changes the semantics of the initialization.
I could have written struct s v={0}; which would initialize the first field with value 0. If p was the first field, it would do the same. But now when you read the code, you won't know which field is being initialized. And if the struct is changed such that p is no longer first, the code will no longer do what it used to do.
I tried that a while ago. It doesn't even compile. I get this error message
I have no idea how to fix that error. The line which triggers it looks like struct s v={.p=0}; AFAIK there is no C++ equivalent for this.