Equip cars with an array of tail lights like "welcome wagon" helos from ID4. Nerby vechicles could use CCDs to capture signals and convert them into usable instructions.
The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.
I'm sorry this is unacceptable and dangerous. Expecting developers to get this right is inviting platform failure the same way expecting developers to get SQL and HTML escaping right has earned PHP a certain reputation or expecting Android users to understand the repercussions of allowing n00b0wnrz flashlight app to run on their device has doomed millions of end users to ownage.
In 2013 random numbers should just work by default with no effort on the developers part either by an OS managed entropy pool (e.g./dev/urandom) and by assist of hardware features (e.g. thermal noise)
(Same as most other cryptographic problems, eg. correctly implementing AES isn't what makes your code secure, it's only the very first step...)
Implementing AES? Understanding high level crypto libraries and not ever calling AES is what gives your code any chance of being secure. The second you call AES you have already failed.
The inherent problem is that DNS uses a 16-bit number for the query id as a means to authenticate the response.
Correlating responses aint the only problem deploying cookies would solve. Amplification of bogus requests is a huge issue large scale deployment of DNSSEC will have made much worse.
Changing DNS to use a larger number would require a major re-architecture of the protocol.
I bet you didn't click on the ID link describing how to fix it did you? But yea major re-architecture..blah blah blah..
Um what? If I said WPA is vulnerable, replace it with WPA2, would your response be "Wait, WPA2 is glued on top of WPA!"
WPA analogue does not work. It is more like SSL v3 vs TLS v1.
Also I didn't recommend DNSSec. Dan Kaminsky and others did: "DNSSec has been proposed as the way to bring cryptographic assurance to results provided by DNS, and Kaminsky has spoken in favor of it."
Don't care about popularity contests or who said what.
The reality is DNSSEC is glued atop DNS and it does inherit all of the same transport problems from DNS. While it is true you can layer something on top of something else and improve a security aspect what good is that if your denied use of the network because DNSSEC is being leveraged to DDOS you or your upstream into oblivion? The transport picture and the risk it represents to the larger network is unacceptable regardless of how "secure" DNSSEC is.
EAP is performed when the EAP client is trying to establish layer 2 connectivity, before IP address aasignment can happed. Since there is no IP, there is no way to do a DNS lookup, and nothing to validate the subject cn against.
The CN in PEAP is the whatever the PEAP server says it is. Hint it is not a DNS name or a SID or anything globally recognizable.
The recent 'it just works' race to the least secure is not going to end well.
Users and operators should not have to go thru all this trouble deploying PKI if they don't want to or jumping thru difficult hoops simply because protocol designers are stuck in the 80's.
We can get a usable solution today using EAP-TLS method and simply negotiating TLS-SRP to verify mututal password knowledge and establish session encryption key rather than or in addition to mutual certificate authentication. More secure, PKI optional (identity protection). Best of all there is no new RFC/specification to invent and only glue code to write.
We can get an extremely usable solution with only minor RFC work to communicate password format/salt or challenges such that stored non-reversable passwords could also be authenticated using the zero knowledge channel.
I'm tired of all of the foolishness where it is not the user doing the wrong thing, it is not even the operator it is the vendors and the standards people who continue to tolerate unusable and or broken shit. PEAP as designed is simply too hard to deploy securely without an automated configuration push. It does not have to be this way.
The only thing you get is the encrypted credentials. Is PEAP-MS-CHAP v2 vulnerable to any practical attacks?
If the TLS certificate is not validated all protections of TLS are null and void as it can be MITMd. In other words PEAP-MS-CHAPv2 becomes just MS-CHAPv2.
I think technically the flaw cannot be patched, but the vulnerability can be mitigated. reading it, it seems to be an inherent problem with the algorithm.
This is not the case here. It is a flaw in the MS implementation of a technology rather than the technology itself. A flaw by the way does not exist in other versions in Microsofts own products if they are configured properly.
Presumably it is analogous to the DNS cache poisoning flaw that Dan Kaminsky discovered in 2008. DNS was patched to make it less vulnerable but the flaw existed in the protocol itself. There was no truly way to fix it without re-writing the protocol.
There was no way to fix SYN attacks against TCP without replacing it either...oh wait yes there was cookies were added to mitigate the problem and today are widely deployed. The same solution for DNS continues to sit on a shelf and collect dust for no sane reason.
Replacing it with DNSSec was the recommended course of action.
April 1st must come late this year cuz DNSSec is glued on top of DNS and has all the same insane transport issues that we continue to allow DNS to have. Only now now with significantly higher computational cost and DDOS amplification factors which just might give SNMP with public community strings a run for its money.
The fundamental problem you run into however, is that at the point where you need to verify the certificate you don't yet have a network connection. In a PEAP environment, the certificate is presented to the client before layer 3 connectivity has been established. The client obtains the certificate, sees that it has been signed by a valid CA, but it can not actually verify that the certificate is being presented by the right server since, well, there's no network connection yet. It's really one of those chicken and egg problems, there's no good way to resolve it.
You resolve it the way all browsers and sane operating systems resolve it. You load/keep a list of trusted root certificates against which the device can validate the server certificate by itself out of band of the wifi communication channel.
There are even extensions to TLS where OSCP can be performed over TLS such that revocation checking does not require network access.
I personally contacted MS security people about this years ago before WP8 was released and they told me they would look into this and get back to me guess what I tried to follow up and they never did.
To be very clear the problem is complete lack of necessary levers and knobs to validate the TLS certificate and common name of certificate in WP7-8. Without these options TLS is trivially MITMd this leaves only MS-CHAPv2 which has known to have been completely and publically broke for years.
What is worse they don't even try there is not even a leap of faith latch as there is in other mobile platforms whereby if the cert changes it at least tells you it is different... The system never warns you or anything.
To be even more clear this is not a problem that Microsoft just stumbled on... They knew full goddamn well what the implications of leaving those levers and knobs out of WP7 were... They knew about them circa 2002-2003 when their wireless supplicant was released for XP. They just didn't give a shit.
Yea I get the basic argument browser needs to be able to decrypt passwords somehow when needed this means either a password encrypting password thing or punting responsibility down the stack.
In many operating systems there are secure ways of doing precisely this. Use underlying operating systems keychain where available such as windows credential store (Sorry XP users). The credential store is at least protected by the users security context and syskey if non-default setting is used. On shared computers this will at the very least keep a users password stash safe from other users. It can also keep the users password stash safe in the event their computer is stolen.
It is easy to make argument in the real world doing x may practically offer little benefit but it is easy to be lazy. There is no harm in over delivering and under promising. Tell the user their stored passwords are insecure AND at least try to do the right thing anyway.
My personal view is that SSL provides adequate protection against casual passive observer. It would be very useful if we had means of communicating securely on the Internet, but we do not.
Go ahead and blame the technology for gross misuse and predictable outcome of errecting global trust anchors. SSL is plenty secure when used properly.
How about we don't send the same secret every freaking time? Maybe sign the message with the secret, or just trust that the darn TLS session is doing its job?
If any content (not just secrets) in the response can be altered as a result of the request the compression algorithm can be leveraged to leak information about the response.
Amused by notion one would expect a different outcome with HTTP layer vs TLS layer compression. In every way that matters it is exactly same issue only this time attack analysis is limited to response body.
Also have some trouble with assertion "it is very common to use gzip at the HTTP level." For static assets sure however I expect numbers for dynamic content to be a much different story.
I think users of foreign countries depending on US based infrastructure is a mistake. Not only can't we be trusted for obvious reasons the more power is disaggregated the better off everyone is. Don't send us your money...build more interconnects and hosting centers locally in your communities.
We are all better served when we take responsibility for our data and run/host our own services rather than depend on a handful of massive content companies to do everything for us.
The Internet is at no risk of being broken up into a series of disconnected tube islands. There is ever increasing value in maintaining global connectivity.
The network does seem to be at some risk of becoming a network of spectators.
Give you a choice if you want to allow your device to be controlled with strings from a google website remotely.
If someone has your Google account password and can sign into your Google account, they can probably already log on to your online banking and credit card accounts,
This could be a very compelling business model. Instead of producing physical goods like sofas and counches one could project them virtually using holograms and force fields. Couch service providers would be able to offer a wide array of couches virtually as a service. However I suspect if you fail to pay your bill on time your couch may become incresingly uncomfortable to sit in.
I think you are confusing a political system with a religion.
Saudi Arabia is a country that leverages their religion to implement a very conservative and authoritarian society.
Islam is a religion.
Except exerting political control is normally the point of religion. One could argue bit torrent is simply a means of transferring information logically distinct from piracy or that the Internet is logically distinct from porn. All of these things sound great and have a morsel of honest truth to them.
Remember, Christianity has been used throughout history as an excuse to kill, maim, rape, and torture millions of people too. Pretending that Islam is unique in the barbarism that is executed in its name is fuzzy logic at best.
Thats right, all religions are shit not just Islam.
It seems all TFA does is measure resistance to change and who all likes coke vs pepsi.
Back in the day I liked DOS word perfect... reveal codes and all just fine. What does that prove?
It would have been refreshing had there been any discussion of metrics or outcomes for users.. After all computers are just tools... Its not what you "like" its what the tool assists you to achieve.
(This is an HTC device rather than Samsung) When I origionally stumbled on this thread I assumed yea yea cyanogen must be doing something wrong using a shit driver or not doing something quite right using a conspiracy theory as an excuse to blurt out a lazy response.
I suspect that A benchmark manipulation is not limited to Samsung. B there is still something screwy going on in cyanogen and C we're going to find out pretty quickly what the truth is.
That's patently false. Public utilities are well within their rights to prohibit certain uses of their services. My local utility has a prohibition on using electricity for direct, resistive heating
Like an incandescent light bulb? They make good resistive heaters to keep engine blocks from dropping below freezing over the winter.
It's because the electricity infrastructure is old and was not expanded to keep pace with suburban growth
A good reason to fix the underlying problem rather than treating symptoms.
Utilities can enact any restriction they want in order to maintain reliability of service to everyone who uses it.
This argument is an oxymoron. Brittle systems in the real world are unreliable. Depending on humans to play by the rules or service is degraded for others shows the operators and engineers are fuckups and don't take their jobs seriously.
That include bandwidth caps, server restrictions, and anything else that is a measure to guarantee quality of service.
Anything at all like banning youtube, google and facebook forinstance cuz you know they consume too much bandwidth and ruin the network for other users.
No utility has an imperative to deliver quantity. Only quality and reliability.
Lack of quantity = lack of quality and reliability.
"Engineering" means operating in the real world not some academic fantasy land of half-baked ideas littered with buzzwords.
The Internet is not a decentralized network of ad-hoc peers it is a ridgid higherarchical network where the physical path reigns supreme. Even in nature and in brrraaaiiinnns there is higherarchical structure behind all transport of information and material.
The problem with all of the adhoc mesh, self organizing shit is it has all been tried and it mostly sucks, wastes resources and does not scale. You can be clever all you want but all the algorithms in the world have much less value compared with paying someone to run more fiber for a new physical path.
Intelligence is quite dangerous within the network given that humans are currently smarter than machines. When machines start making ASSumptions about the importance of packets each machine assumption becomes something a human can expliot. Intelligence belongs in the peers at the edge where we all have the ability to do really clever things without asking anyone else for permission, without turning the Internet into a "trusted" network and without having to worry about repercussions of the Internet being as "smart" as my fully buzzword compliant spam filter which regularly fails against human advasaries...surprise...
Slashdot Mirror
My heart almost sank until I realized IAB != IAB
Good IAB: http://www.iab.org/
Bad IAB: http://www.iab.net/
Equip cars with an array of tail lights like "welcome wagon" helos from ID4. Nerby vechicles could use CCDs to capture signals and convert them into usable instructions.
The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.
I'm sorry this is unacceptable and dangerous. Expecting developers to get this right is inviting platform failure the same way expecting developers to get SQL and HTML escaping right has earned PHP a certain reputation or expecting Android users to understand the repercussions of allowing n00b0wnrz flashlight app to run on their device has doomed millions of end users to ownage.
In 2013 random numbers should just work by default with no effort on the developers part either by an OS managed entropy pool (e.g. /dev/urandom) and by assist of hardware features (e.g. thermal noise)
(Same as most other cryptographic problems, eg. correctly implementing AES isn't what makes your code secure, it's only the very first step...)
Implementing AES? Understanding high level crypto libraries and not ever calling AES is what gives your code any chance of being secure. The second you call AES you have already failed.
I have to wonder did someone sit around a table and brainstorm the most innocuous repercussion of RNG failure possible?
The inherent problem is that DNS uses a 16-bit number for the query id as a means to authenticate the response.
Correlating responses aint the only problem deploying cookies would solve. Amplification of bogus requests is a huge issue large scale deployment of DNSSEC will have made much worse.
Changing DNS to use a larger number would require a major re-architecture of the protocol.
I bet you didn't click on the ID link describing how to fix it did you? But yea major re-architecture..blah blah blah..
Um what? If I said WPA is vulnerable, replace it with WPA2, would your response be "Wait, WPA2 is glued on top of WPA!"
WPA analogue does not work. It is more like SSL v3 vs TLS v1.
Also I didn't recommend DNSSec. Dan Kaminsky and others did: "DNSSec has been proposed as the way to bring cryptographic assurance to results provided by DNS, and Kaminsky has spoken in favor of it."
Don't care about popularity contests or who said what.
The reality is DNSSEC is glued atop DNS and it does inherit all of the same transport problems from DNS. While it is true you can layer something on top of something else and improve a security aspect what good is that if your denied use of the network because DNSSEC is being leveraged to DDOS you or your upstream into oblivion? The transport picture and the risk it represents to the larger network is unacceptable regardless of how "secure" DNSSEC is.
EAP is performed when the EAP client is trying to establish layer 2 connectivity, before IP address aasignment can happed. Since there is no IP, there is no way to do a DNS lookup, and nothing to validate the subject cn against.
The CN in PEAP is the whatever the PEAP server says it is. Hint it is not a DNS name or a SID or anything globally recognizable.
The recent 'it just works' race to the least secure is not going to end well.
Users and operators should not have to go thru all this trouble deploying PKI if they don't want to or jumping thru difficult hoops simply because protocol designers are stuck in the 80's.
We can get a usable solution today using EAP-TLS method and simply negotiating TLS-SRP to verify mututal password knowledge and establish session encryption key rather than or in addition to mutual certificate authentication. More secure, PKI optional (identity protection). Best of all there is no new RFC/specification to invent and only glue code to write.
We can get an extremely usable solution with only minor RFC work to communicate password format/salt or challenges such that stored non-reversable passwords could also be authenticated using the zero knowledge channel.
I'm tired of all of the foolishness where it is not the user doing the wrong thing, it is not even the operator it is the vendors and the standards people who continue to tolerate unusable and or broken shit. PEAP as designed is simply too hard to deploy securely without an automated configuration push. It does not have to be this way.
The only thing you get is the encrypted credentials. Is PEAP-MS-CHAP v2 vulnerable to any practical attacks?
If the TLS certificate is not validated all protections of TLS are null and void as it can be MITMd. In other words PEAP-MS-CHAPv2 becomes just MS-CHAPv2.
Cracking MS-CHAPv2 is trivial...
https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
Not just practical its EASY.
I think technically the flaw cannot be patched, but the vulnerability can be mitigated. reading it, it seems to be an inherent problem with the algorithm.
This is not the case here. It is a flaw in the MS implementation of a technology rather than the technology itself. A flaw by the way does not exist in other versions in Microsofts own products if they are configured properly.
Presumably it is analogous to the DNS cache poisoning flaw that Dan Kaminsky discovered in 2008. DNS was patched to make it less vulnerable but the flaw existed in the protocol itself. There was no truly way to fix it without re-writing the protocol.
There was no way to fix SYN attacks against TCP without replacing it either...oh wait yes there was cookies were added to mitigate the problem and today are widely deployed. The same solution for DNS continues to sit on a shelf and collect dust for no sane reason.
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03
Replacing it with DNSSec was the recommended course of action.
April 1st must come late this year cuz DNSSec is glued on top of DNS and has all the same insane transport issues that we continue to allow DNS to have. Only now now with significantly higher computational cost and DDOS amplification factors which just might give SNMP with public community strings a run for its money.
The fundamental problem you run into however, is that at the point where you need to verify the certificate you don't yet have a network connection. In a PEAP environment, the certificate is presented to the client before layer 3 connectivity has been established. The client obtains the certificate, sees that it has been signed by a valid CA, but it can not actually verify that the certificate is being presented by the right server since, well, there's no network connection yet. It's really one of those chicken and egg problems, there's no good way to resolve it.
You resolve it the way all browsers and sane operating systems resolve it. You load/keep a list of trusted root certificates against which the device can validate the server certificate by itself out of band of the wifi communication channel.
There are even extensions to TLS where OSCP can be performed over TLS such that revocation checking does not require network access.
I personally contacted MS security people about this years ago before WP8 was released and they told me they would look into this and get back to me guess what I tried to follow up and they never did.
To be very clear the problem is complete lack of necessary levers and knobs to validate the TLS certificate and common name of certificate in WP7-8. Without these options TLS is trivially MITMd this leaves only MS-CHAPv2 which has known to have been completely and publically broke for years.
What is worse they don't even try there is not even a leap of faith latch as there is in other mobile platforms whereby if the cert changes it at least tells you it is different... The system never warns you or anything.
To be even more clear this is not a problem that Microsoft just stumbled on... They knew full goddamn well what the implications of leaving those levers and knobs out of WP7 were... They knew about them circa 2002-2003 when their wireless supplicant was released for XP. They just didn't give a shit.
Yea I get the basic argument browser needs to be able to decrypt passwords somehow when needed this means either a password encrypting password thing or punting responsibility down the stack.
In many operating systems there are secure ways of doing precisely this. Use underlying operating systems keychain where available such as windows credential store (Sorry XP users). The credential store is at least protected by the users security context and syskey if non-default setting is used. On shared computers this will at the very least keep a users password stash safe from other users. It can also keep the users password stash safe in the event their computer is stolen.
It is easy to make argument in the real world doing x may practically offer little benefit but it is easy to be lazy. There is no harm in over delivering and under promising. Tell the user their stored passwords are insecure AND at least try to do the right thing anyway.
My personal view is that SSL provides adequate protection against casual passive observer. It would be very useful if we had means of communicating securely on the Internet, but we do not.
Go ahead and blame the technology for gross misuse and predictable outcome of errecting global trust anchors. SSL is plenty secure when used properly.
How about we don't send the same secret every freaking time? Maybe sign the message with the secret, or just trust that the darn TLS session is doing its job?
If any content (not just secrets) in the response can be altered as a result of the request the compression algorithm can be leveraged to leak information about the response.
Amused by notion one would expect a different outcome with HTTP layer vs TLS layer compression. In every way that matters it is exactly same issue only this time attack analysis is limited to response body.
Also have some trouble with assertion "it is very common to use gzip at the HTTP level." For static assets sure however I expect numbers for dynamic content to be a much different story.
I think users of foreign countries depending on US based infrastructure is a mistake. Not only can't we be trusted for obvious reasons the more power is disaggregated the better off everyone is. Don't send us your money...build more interconnects and hosting centers locally in your communities.
We are all better served when we take responsibility for our data and run/host our own services rather than depend on a handful of massive content companies to do everything for us.
The Internet is at no risk of being broken up into a series of disconnected tube islands. There is ever increasing value in maintaining global connectivity.
The network does seem to be at some risk of becoming a network of spectators.
I was really sad to get email they were closing down been a customer since the dawn of civilization.
But then they mentioned evertek.com and WTF it is essentially the geeks site and inventory just with a different skin.
What more could they require that's safer?
Give you a choice if you want to allow your device to be controlled with strings from a google website remotely.
If someone has your Google account password and can sign into your Google account, they can probably already log on to your online banking and credit card accounts,
I hope most people have more sense than this.
Dice only offered me about tree fiddy. But I accepted.
Well this explains why lochness monster owns a windows phone and thinks the NSA is cool.
This could be a very compelling business model. Instead of producing physical goods like sofas and counches one could project them virtually using holograms and force fields. Couch service providers would be able to offer a wide array of couches virtually as a service. However I suspect if you fail to pay your bill on time your couch may become incresingly uncomfortable to sit in.
I think you are confusing a political system with a religion.
Saudi Arabia is a country that leverages their religion to implement a very conservative and authoritarian society.
Islam is a religion.
Except exerting political control is normally the point of religion. One could argue bit torrent is simply a means of transferring information logically distinct from piracy or that the Internet is logically distinct from porn. All of these things sound great and have a morsel of honest truth to them.
Remember, Christianity has been used throughout history as an excuse to kill, maim, rape, and torture millions of people too. Pretending that Islam is unique in the barbarism that is executed in its name is fuzzy logic at best.
Thats right, all religions are shit not just Islam.
Drive of Sauron
It seems all TFA does is measure resistance to change and who all likes coke vs pepsi.
Back in the day I liked DOS word perfect... reveal codes and all just fine. What does that prove?
It would have been refreshing had there been any discussion of metrics or outcomes for users.. After all computers are just tools... Its not what you "like" its what the tool assists you to achieve.
(This is an HTC device rather than Samsung) When I origionally stumbled on this thread I assumed yea yea cyanogen must be doing something wrong using a shit driver or not doing something quite right using a conspiracy theory as an excuse to blurt out a lazy response.
http://forum.cyanogenmod.com/topic/75172-why-is-cyanogenmod-htc-one-so-slow-6250-on-quadrant-standard-instead-12500/
I suspect that A benchmark manipulation is not limited to Samsung. B there is still something screwy going on in cyanogen and C we're going to find out pretty quickly what the truth is.
That's patently false. Public utilities are well within their rights to prohibit certain uses of their services. My local utility has a prohibition on using electricity for direct, resistive heating
Like an incandescent light bulb? They make good resistive heaters to keep engine blocks from dropping below freezing over the winter.
It's because the electricity infrastructure is old and was not expanded to keep pace with suburban growth
A good reason to fix the underlying problem rather than treating symptoms.
Utilities can enact any restriction they want in order to maintain reliability of service to everyone who uses it.
This argument is an oxymoron. Brittle systems in the real world are unreliable. Depending on humans to play by the rules or service is degraded for others shows the operators and engineers are fuckups and don't take their jobs seriously.
That include bandwidth caps, server restrictions, and anything else that is a measure to guarantee quality of service.
Anything at all like banning youtube, google and facebook forinstance cuz you know they consume too much bandwidth and ruin the network for other users.
No utility has an imperative to deliver quantity. Only quality and reliability.
Lack of quantity = lack of quality and reliability.
"Engineering" means operating in the real world not some academic fantasy land of half-baked ideas littered with buzzwords.
The Internet is not a decentralized network of ad-hoc peers it is a ridgid higherarchical network where the physical path reigns supreme. Even in nature and in brrraaaiiinnns there is higherarchical structure behind all transport of information and material.
The problem with all of the adhoc mesh, self organizing shit is it has all been tried and it mostly sucks, wastes resources and does not scale. You can be clever all you want but all the algorithms in the world have much less value compared with paying someone to run more fiber for a new physical path.
Intelligence is quite dangerous within the network given that humans are currently smarter than machines. When machines start making ASSumptions about the importance of packets each machine assumption becomes something a human can expliot. Intelligence belongs in the peers at the edge where we all have the ability to do really clever things without asking anyone else for permission, without turning the Internet into a "trusted" network and without having to worry about repercussions of the Internet being as "smart" as my fully buzzword compliant spam filter which regularly fails against human advasaries...surprise...