Raw List of Recommendations
These are all the recommendations given at the workshop. They are listed in the order the talks were given. The organizational label is given simply as a means to identify each talk.
CMU
Where Where Our Group is Looking
- Heuristic Detection
- Link Characteristics and HTML tricks
- Header Information
- Domain Age
- “Inbox context”
- Collaborative Approaches
- Leverage economies of scale
- Publish warnings, or “vaccines” (think virus definitions)
- Issues of trust in reporting, detecting misinformation
Where Our Where Our Group is Looking (2)
- 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
- Leveraging Out-Of-Band Communications
- Salvaging PKI
- Building on current relationship establishment procedures
- Facilitating support technologies
Where Our Where Our Group is Looking (3)
- Understanding the Users: Interviews
- 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
Where Our Group is Looking (4)
- Educating the User
- Providing training in the context of the user's inbox
- Tailoring the training to the specific user's needs, adapting to strengths and
weaknesses
- Creating an educational game to teach antiphishing skills
Concluding Remarks
- 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
SIZ
Conclusion 1/2
- It is important for users to recognize whether a web page they open in their
browser is authentic or faked.
- 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.
- Phishing attacks causing financial damage will continue.
- This will damage the reputation of e-business and the internet as a whole.
- To counteract this problem, browser vendors need to create new, optimised and
standardised authentication features which will be difficult to fake and will be accepted by users.
- In addition, users must be made aware of these issues and helped to feel
confident about using authentication features.
FSTC
What should W3C do?
- Coordinate industry efforts to continuously improve Web authentication
- Promote cross-industry cooperation
- Bring together technology developers, service providers, and relying parties
- 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
- Establish new standards for interoperable solutions
- Define new or improved Web authentication techniques
- Specify infrastructure and services to support Web authentication
- Stipulate consistent Web authentication practices
Summary: 5 Key Principles of a Solution
- 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.
Yahoo
Three issues that are important to Yahoo!
- Pseudonymous delegation of partial rights
- Revocation on Yahoo! Password change
- Opaque Identifiers
World Savings
The Internet Access Software
- Must contain consistent security/auth processes and indicators for consumers
- Must not try and re-invent the security wheel
The Financial Services Software Vendors
- Must interface with browser and OS auth processes
- Best position to enable rich meta data review and transaction scoring
- Could enable data sharing for fraud detection
The Holy Grail - Strong Authentication:
- Customer auth credentials must be usable in multiple channels
- Authenticators cannot be passed between humans for authentication
- Must scale well - (avoid token necklace or fat wallet syndrome)
- Scale auth technique to transaction risk (profile transactions and respond as
needed) Steps 2-10 - We Must Partner
- Standardize . . . Process
- Standardize . . . Consumer Visible Indicators
- Standardize . . . Credentials
Conclusion(s) We must form a long-term partnership to ensure that the critical online channel is not lost to fraud and other criminal operations Innovation and standardization will present mitigating alternatives to online (and offline) risks We cannot afford to focus on securing only one channel . . .fraud will move to the path of least resistance
Quatro
Human verified content labels
IBM
Metadata tied to past personal actions, past community activity, and authority recommendations can combat large categories of web site scams – Integration with mail infrastructure can provide additional benefits
- * *More potential issues
– Bootstrapping – Roaming, multiple computers – Design that makes all the metadata consistently usable – Attacks on both technical and social aspects of metadata – Gaps from anything not absolute – Human ingenuity x human naiveté
- * *Just need to make some other scam easier and more profitable
World Bank
Personalized visual indicators such as:
- Background Color
- Font Color
- Text Message
- Graphic Image
- Phrases Greeting
- Voice Greeting
- Session Timer
- Transactional History
- Security Checklist
Conclusion:
- Personalize experience for the end-user
- Consistent authenticator across the web
- Better placement of fraud tips and info
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.
HP
Petname plugin Matching of TLS Certificate fields User controlled notation
Bar Ilan University
We should protect average Net users
- Usability is key to security
- Specific proposals:
- Site Identification Widget
TrustBar :<name/logo> Identified by <CA>
Single-click logon: define login site modifier format
- Public-protest-period certificate: define publishing mechanism
- Certificate validation service: define configuration file
- Default blocking mode; define labeling, resolution mechanism
AmirHerzberg.com/TrustBar
HGI
Candidate Solution I: Secure Mode Browser
Security Mode
- Limit the functionality * *“zero-footprint”
- –User should always be aware of “what he sees is what he gets” –Does not solve completely phishingproblem –Domesticates the “tools” of illusion attacks
- Non-cryptographic presentation of SSL
- Context-sensitive presentation of security indicators
- Highlight the trustworthiness of certificate authorities
Candidate Solution II: PERSEUS
Security Architecture against MalwaredPhishing
- Software-based security kernel (secure operating system)
- Trusted Computing (TC) functionalities
- –More and more vendors integrate a Trusted Platform Module (TPM)
- Provides elementary security properties (e.g., trusted channels,process
isolation)
- PERSEUS: A generic security architecture
- Abstraction of underlying hardware (e.g., CPU, interrupts)
- Offer an appropriate management interface
- Enforce resource-based access control policy
- Trusted Software Layer
- Trusted GUIsecure path to applications (identify applications and thus
protects against Trojan horse attacks like faked dialogs)
- Application Managerenforces a security policy defining the applications that
are allowed to be executed, measures the application’s integrity
- Trust Managercreates and certifies keys bounded to applications
- Storage Managerenables other applications to persistent store their states and
data
Summary
Proof-of-Concept for Online-Banking on-going
Challenges we face
- User-friendly presentation of a trusted compartment
- Policies how to automatically activate a new compartment
- Secure and efficient migration of compartments
Verisign
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
Yahoo
New Metadata exchange protocol
Nokia/Sun
SSAApproaches Summary Approach ECP IDP shared secret IDP Portal Benefits Trusted intermediary (IDP) Limitations Inherent portal limitations Additional Component? Specification Involved ID-FF Changes to Client? No Possibly No General, active component manages meeting mutual authentication requirements Scalable shared secret with minimal client changes Requires enhanced client or proxy. Agreement on the representation of the secret and implementation on the client. Yes (Enhanced client or Proxy) Liberty Authentication Service technology – ID-FF Liberty ID-FF technology or equivalent SAML 2.0 ECP or Liberty Alliance LECP ID-FF & ID-WSF (partial for AS)
MIT Lincoln Lab
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
RSA
Standardization Prospects
- *Interoperable hash-based constructions and protocol representations for
authenticator data, confirmation values
*Methods (e.g., embedded <Object> tags) to indicate support for specific
transforms and algorithms
- *User interface characteristics (e.g., placement, indicators, control
sequence)
SXIP
SXIP Protocols Anti-Phishing…
- Consistent User-Experience
- Fewer Authentication Points
- Increased ROI for Strong Authentication
Identity Commons Non-technical proposals Identity Rights Agreements Range of Choices Privacy Concerns
Microsoft
Identity Metasystem Infocard New protocols based on WS- * Standards
KDE
Usability and Content
- 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
- The content should not be able to manipulate the chrome
- Again, breaks the Internet
- IN THE CONTENT REGION, ALL BETS ARE OFF
Active Approaches To Security
- OCSP – Ability to shut down the bad guys
- Similarly should be applied to DNS
- 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
- What's the problem with all of these things?
Conclusion
- 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.
Mozilla
Requirements
- 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) Leverage new features
- Updates to SSL interface
- Places (Petname, Trustbar)
- APIs for anti-phishing and SSL tools
<xul:browsermessage>
- yes, it’s spoofable, I know
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)
Opera
No technical proposals