Recommendations – Categories
The out of scope recommendations have been dropped and the remaining ones organized into general categories.
Semantic Approaches
- User's environment knows more about the user than the ISP does
- Detect deviance from normal user behavior
- Semantic approaches, including digital wallets or federated identity management systems
* Building on current relationship establishment procedures
What doesn't work
- People misunderstand many cues the browser provides:
- Some are alarmed by 'warnings' that they are entering a secure site
- Certificates, especially self-signed, and encryption are confusing to users:
“I guess I'm not fully sure what 'encrypted' means.” - user
- Some are highly affected by targeted attacks
- Past “experience” doesn't necessarily help
- Web browsers are capable of verifying web page authenticity, but these capabilities do not work for two reasons:
- Authentication features are not known to all users, require technical expertise and sometimes complex procedures. This is why acceptance is low.
- Authentication features can be faked and fakes are also difficult to recognize.
Education
- Educating the User
* Tailoring the training to the specific user's needs, adapting to strengths and weaknesses
- Creating an educational game to teach antiphishing skills
General Principles
- New solutions must take usability into account
- Security should be analyzed from a holistic perspective, including user analysis
- What do we rely upon the user doing?
- Can the user be tricked into doing a “bad” action at any stage?
- Expectations for user action should be minimal
- Active, positive indicators of problems
- It is important for users to recognize whether a web page they open in their browser is authentic or faked.
- In addition, users must be made aware of these issues and helped to feel confident about using authentication features.
- Trusted user interface for authentication must be based on a secret, since all user interface is spoofable.
- A trusted channel can’t be trusted, since an attacker can use a trusted channel.
- The client must authenticate the server, since an unauthenticated server can ask for confidential information.
- A cleartext password must not be revealed during any phase of authentication, since an attacker will fool the user into completing any standard process.
- The anti-phishing solution must integrate with existing password based authentication, since users are trained to use passwords.
- Must contain consistent security/auth processes and indicators for consumers
- Must not try and re-invent the security wheel
- If widely accepted this method of personalized visual and behavioral indicators can heighten an end-user consciousness of safe data sharing procedures over internet channels.
We should protect average Net users
- Usability is key to security
- *User interface characteristics (e.g., placement, indicators, control sequence)
* The interface should make it possible to access all information about the connection
- The interface should not force the user to make too many decisions or do too many actions
- There are many areas to tackle, and we need to do it in a co-ordinated manner to avoid breaking the Internet
- Playing around with the user-agent UI (browser, e-mail client, etc.) is error prone and of questionable value
- Our current UIs fail users badly
- We need to act now, and we need to act for the future. The entire system is at risk.
- Be open to innovation
- Give the user choice
- Make sure to provide clear signals
- Think about what is being said by omission
(we’re at a critical juncture here, and need to be wary of creating another failed metaphor like the padlock)
New Indicators
- To counteract this problem, browser vendors need to create new, optimised and standardized authentication features which will be difficult to fake and will be accepted by users.
Personalized visual indicators such as:
- Background Color
- Font Color
- Text Message
- Graphic Image
- Phrases Greeting
- Voice Greeting
- Session Timer
- Transactional History
- Security Checklist
- Non-cryptographic presentation of SSL
- Context-sensitive presentation of security indicators
- Highlight the trustworthiness of certificate authorities
- The content should not be able to manipulate the chrome
Process Recommendations
- Coordinate industry efforts to continuously improve Web authentication
- Promote cross-industry cooperation
- Bring together technology developers, service providers, and relying parties
- Establish new standards for interoperable solutions
- Innovation and standardization will present mitigating alternatives to online
(and offline) risks Write an extension
- Trial by fire
- Call it a “proof of concept” if you want / if it helps to get funding
- Popular extensions often get “uplifted”
- There’s a community out there to help
(I know this sounds like a cop-out, but it’s a really well proven model for innovation in our market)
Technical Recommendations
- Develop a comprehensive architecture for Web authentication
- Incorporate all viable authentication techniques
- Map to platforms and services
- Clarify functional roles and responsibilities
- Establish a framework for interoperability
- Address extensibility so authentication can be continuously improved
- Specify infrastructure and services to support Web authentication
- Stipulate consistent Web authentication practices
- Metadata tied to past personal actions, past community activity, and authority recommendations can combat large categories of web site scams
– Design that makes all the metadata consistently usable – Attacks on both technical and social aspects of metadata – Gaps from anything not absolute
- Personalize experience for the end-user
- Consistent authenticator across the web
- Better placement of fraud tips and info
- Petname plugin
- Matching of TLS Certificate fields
- User controlled notation
- Specific proposals:
- Site Identification Widget
TrustBar :<name/logo> Identified by <CA>
Single-click logon: define login site modifier format
- Certificate validation service: define configuration file
- Default blocking mode; define labeling, resolution mechanism
Try and use TrustBar: http://AmirHerzberg.com/TrustBar
- Secure Mode Browser
- Limit the functionality * *“zero-footprint”
Secure Letterhead
- Standards based: X.509 / PKIX Digital Certificate
- IETF LOGOTYPE Extension
- Longstanding prior art
- Can be supported by any high assurance Certification Authority
- Competitive market anticipated
Browser Support
- Require consensus user interface guidelines
- Require support from CAs
LOGOTYPE Certificate Issuers
- Require defined issue practices
- Require browser support
The SSR Record’s Capabilities Enables sites to raise security level of users’ configurations (exactly what Chuck Wade requested)
Require protocols & protocol options
– Cipher, keylength, etc. – E.g. HTTPS using SSLv3 and AES-256
Forbid protocols & protocol options
– E.g. no HTTP, no SHA1
- Securely redirect
– E.g. etrade.com + secure.us.etrade.com
- Restrict subdomains
– E.g. acceptable subdomains are login.w3.org, www.w3.org
- Anti-phishing databases
- Great success for similar initiatives against SPAM
- Should be built into the browser, not an add-on
- Live content information in the chrome
- Co-ordinated active software updates
Leverage new features
- Updates to SSL interface
- Places (Petname, Trustbar)
- APIs for anti-phishing and SSL tools
<xul:browsermessage>