Monday, June 16, 2008
Browser Security: What if Microsoft and Mozilla worked together...
Gunnar Peterson discusses Web 2.0 security issues where I wonder if the Web 1.0 input type=password should be the first thing to go...
We all understand that it is a good practice to protect all forms of credential exchange over a secured channel such as SSL, but nowadays, we have clever ways of injecting Javascript into applications such that the password can be stolen prior to transmission. There are better ways and I figured I would throw out some random ideas in hopes that others may run with them or at least amplify:
1. Microsoft is doing the right thing when it comes to CardSpace and has implemented an identity selector in Internet Explorer. The challenge is that Microsoft hasn't done much evangelism of this technology within the enterprise marketplace. It would seem as if Cardspace could be the mechanism that eliminates fugly passwords, prevents spoofing and hijacking of passwords yet if no one knows about it, the ecosystem can never be secure. With a little bit more evangelism and for the Mozilla folks to not think of an identity selector as an add-in, browser security can improve.
2. Why can't the inner workings of the password field, turn itself off from allowing it to be read by Javascript. Alternatively, you could introduce some notio of a key that read operations have to provide to read this field which could be generated based on header values passed when the page was rendered. Headers aren't visible to the page after rendered and therefore may serve as a weak implementation of out-of-band security. NOTE: Yes, this can be attacked, but it makes it more difficult.
3. What about the ability for a web-site to issue via headers, a seed value for password that populates the field, but doesn't show from a UI perspective those little dots. The thought says that script could hijack garbage while the user would think the field is empty and then populate. Kinda like a race condition where Javascript will execute faster than the user.
4. In the same way that Cardspace runs in its own process, why can't Microsoft make all plugs-in installed via ActiveX do the same? Separating out plug-in execution could provide the necessary constraints and even can allow for policies to be applied. It shouldn't be enough just to sign something, but should require user consent to run in the same address space of the browser.
Of course many of my thoughts have tons of holes and the point of sharing them isn't for folks to throw daggers at my ideas, but to focus on making browser security better...
| | View blog reactionsWe all understand that it is a good practice to protect all forms of credential exchange over a secured channel such as SSL, but nowadays, we have clever ways of injecting Javascript into applications such that the password can be stolen prior to transmission. There are better ways and I figured I would throw out some random ideas in hopes that others may run with them or at least amplify:
1. Microsoft is doing the right thing when it comes to CardSpace and has implemented an identity selector in Internet Explorer. The challenge is that Microsoft hasn't done much evangelism of this technology within the enterprise marketplace. It would seem as if Cardspace could be the mechanism that eliminates fugly passwords, prevents spoofing and hijacking of passwords yet if no one knows about it, the ecosystem can never be secure. With a little bit more evangelism and for the Mozilla folks to not think of an identity selector as an add-in, browser security can improve.
2. Why can't the inner workings of the password field, turn itself off from allowing it to be read by Javascript. Alternatively, you could introduce some notio of a key that read operations have to provide to read this field which could be generated based on header values passed when the page was rendered. Headers aren't visible to the page after rendered and therefore may serve as a weak implementation of out-of-band security. NOTE: Yes, this can be attacked, but it makes it more difficult.
3. What about the ability for a web-site to issue via headers, a seed value for password that populates the field, but doesn't show from a UI perspective those little dots. The thought says that script could hijack garbage while the user would think the field is empty and then populate. Kinda like a race condition where Javascript will execute faster than the user.
4. In the same way that Cardspace runs in its own process, why can't Microsoft make all plugs-in installed via ActiveX do the same? Separating out plug-in execution could provide the necessary constraints and even can allow for policies to be applied. It shouldn't be enough just to sign something, but should require user consent to run in the same address space of the browser.
Of course many of my thoughts have tons of holes and the point of sharing them isn't for folks to throw daggers at my ideas, but to focus on making browser security better...
