1
edit
Firefox/Feature Brainstorming:Security: Difference between revisions
Jump to navigation
Jump to search
technique for solving the problem of phishing using bidirectional registrations
(Added: Secure Defaults/ No Security Pop-ups) |
(technique for solving the problem of phishing using bidirectional registrations) |
||
| Line 84: | Line 84: | ||
** Organizations could sign certificates not just (as today) in order to confirm the identity but to confirm that a web site belongs to the "good guys". Users could mark the certificate of such an organization as trustworthy. When displaying a site which has been approved that way the browser should mark it somehow (a green address field e.g.). This is just an infrastructure idea. If Firefox supports that people will start to offer whitelists. Whitelisting makes more sense than blacklisting - it's easier and safer. There are rather few web sites which are potential phishing targets so it should work. | ** Organizations could sign certificates not just (as today) in order to confirm the identity but to confirm that a web site belongs to the "good guys". Users could mark the certificate of such an organization as trustworthy. When displaying a site which has been approved that way the browser should mark it somehow (a green address field e.g.). This is just an infrastructure idea. If Firefox supports that people will start to offer whitelists. Whitelisting makes more sense than blacklisting - it's easier and safer. There are rather few web sites which are potential phishing targets so it should work. | ||
** Additionally, rather than just using a green address field: once a website is verified as trusted, the domain matches the certificate, the trusted domain's logo could be requested from a standard location on the trusted domain's server. This logo should be of a standard size and displayed near the browser acitivity icon. The intention is to give the impression of a holographic imprint of authenticity. Logo's should be tracked by root certificate authorities to ensure no two are similar.([[User:Randomly|Randomly]] 14:43, 7 December 2006 (PST)) | ** Additionally, rather than just using a green address field: once a website is verified as trusted, the domain matches the certificate, the trusted domain's logo could be requested from a standard location on the trusted domain's server. This logo should be of a standard size and displayed near the browser acitivity icon. The intention is to give the impression of a holographic imprint of authenticity. Logo's should be tracked by root certificate authorities to ensure no two are similar.([[User:Randomly|Randomly]] 14:43, 7 December 2006 (PST)) | ||
* new approach: bi-directional registrations. | |||
** When a user registers with a site, the browser submits a request to the site to send back a password (let's name this password the site password). This password is kept by the browser in the password list. When the user tries to login into a site, the browser sends the user password to the site and the site sends back the site password; then the browser compares the site password with the one stored internally and if they don't match, the site is not displayed in the browser. With bi-directional registration, both sides (the user and the site) must submit a password to each other in order to view the site. A phishing site can not know the site password (unless the original site is compromised during registration), so users are safe, even in the presence of identical web pages or domain names. | |||
** This approach requires a little more work from the web applications that must generate, keep and send site passwords. But from the client side, it is a flexible solution that can be automated at browser level. | |||
</td><td> | </td><td> | ||
certificate whitelisting - in German [http://www.hauke-laging.de/ideen/bsi-zertifikatsplugin/] | certificate whitelisting - in German [http://www.hauke-laging.de/ideen/bsi-zertifikatsplugin/] | ||