Realtime Check of Password Pages (RCP)

I have an idea. This came after I saw a tweet from @SwiftOnSecurity:

We definitely need login page check in our browsers.

The Idea

Built-in or plugin based login page check in browsers. There are checks for valid URLS.

How is this works?

1. The user enters any page.
2. Browser checks three things:
    • Have password field
    • Have form
    • URL is secure
3. If so, the browser checks the RCP database, sends 
    • the URL
    • the page certificate
4. Response from server: 
    • whitelisted
    • blacklisted (confirmed or community)
    • wrong CERT
    • unknown
    • and the response TTL
5. Based on user preferences, the browser notifies the user and disables the access to the form

What happens on non-secure login pages? See below.

User settings

Obviously, there is need a “security level” type configuration what level of protection user is required:

• whitelist only
• blacklist only

Also, there is a setting need to Browser action

• warning
• disable the form
• etc

Because the server can respond a community recommended blacklist, there is needed an option for include or not.

For unsecured forms, maybe there is an option where the user can protect non-secure forms.

• If disabled, the browser always warns there a connection not secure
• If enabled the browser still warns about connection, but handle it locally to build a local DB of password contained pages. So subsequent requests subtle or disables the warning

Behaviour of the Browser

Browsers can disable the form, display a warning message, such as display an icon (broken key on the URL bar for example). On whitelisted sites, there is not need any action.

Behaviour of the Server

The server only does one thing:
Search his databases for requested URLs, checks the matching Certificate and respond accordingly.

Server Management

Blacklist

• anybody can send a bogus/malicious page
• Already whitelisted pages automatically rejected, see Dispute
• The community vote, if enough vote — let’s say 1% — its introduced as `blacklisted-community`
• if vote increases — maybe 25% — , the server staff decide to add as `blacklisted-confirmed`

Whitelist

1. Web page operator request
2. The server staff connects to the web page owners, check the web page itself
3. Staff check the identity of page owners
4. If everything is all right, then insert as `whitelist` to the database

Dispute

There is also need to solve occasional problems such as

• Community mark page was not authentic but web page owner complain.
• The page was marked as `whitelist`, but someone else is claiming it is bogus.

Further consideration

• Obviously, the communication needs to be straightforward and secure, e.g. REST over HTTPS
• Due to the nature of the volume of this type of requests, maybe it is a good idea to implement as a distributed service. Servers can communicate each other like DNSSEC

Conclusion and Disclosure

I am a lone man, and I just scratching the surface of the Infosec field. That is why I try to avoid all the development details, technical consideration, or organisation requirements in this post. Moreover, it is clear to me there is two important factor for this type of service

1. How light, fast and secure (confidentiality, integrity, and availability) the implementation
2. How trustworthy and rapid is the server operating organisation

For now, there is just an idea. Is it worthy of consideration?

Time will tell.