See also: IRC log
<jose-ny> scribe: Jose Kahan
<jose-ny> scribenick: jose-ny
Dan Schutzer: Financial Services Consortium
DS: Concerned about vendor authentication on
the web, and authentication of users
... requirement is to have mutual authentication
... they have requirements, but need to work with customers and vendors so
that the infrastructure is trusted, easy to use and integrate
Danny Weitzner (W3C)
DJW: This workshop is the second act of the W3C
and financial services working together
... first round of requirements led to xml-sig, xml-enc, and xkms.
... The hope is to get a clear set of requirements from this WS
... Consider that we're not considering just browsers on computers, but on
any mobile device
... W3C has workshops because it's a pretty unique opportunity to develop
consensus on an area of work that can be interested, what are the common
threads and where we can get some useful work done
<beltzner> DJW: standard UI wasn't thought to be the solution, but a lack of shared UI metaphors for security has been identified as a weakness
DJW: We have a critical mass of people here. We
should not aim at solving every problem, but try to identify short term,
quick term solutions that we can get together on. Try to avoid having a
long-time rec. creation
... We expect to have a ff2 end of year, if not sooner.
<scribe> scribe: Dan Connolly
<scribe> scribenick: DanC_lap
- Mike Beltzner Mozilla (http://wiki.mozilla.org/Firefox2 if anyone wants to see the plans)
Rachna Dhamija from Harvard
Drew Dean from Yahoo
- Jeffrey Nelson, Google
- Charles McCathieNevile, Opera software. Opera's chief standards officer, fascinated by security and trust (Yngve P is our real paranoiac - I am like the drummer hanging around the musicians). Looking for long-term work to get underway - we have started a bunch f short-term work among browser groups already, and welcome feedback on that. Opera runs across mobile platforms, TVs, and various other platforms as well as desktops, and we want stuff that works for users in all those environments
- Dieter Bartl, SIZ
- Andy Ozment MIT Lincoln Laboratory
- Daniel J. Weitzner W3C/MIT
- Peter Lipp IAIK, Graz University of Technology
- Ami Grynberg Protecteer, LLC
- Phillip Hallam-Baker Verisign, Inc. I'm interested in federated identity and such, but perhaps more: authentication of the bank/service _to_ the user; I think that's a hole that needs filling. We want something that reduces the return to the bad guys - doesn't have to be perfect, we're trying to make stuff better
- Daniel Schutzer FSTC (Financial Services Technology Consortium)
- Shivaram Mysore Microsoft Corporation
- Amir Herzberg Bar Ilan University
- Chuck Wade Financial Services Technology Consortium (FSTC), Better Mutual Authentication Project
- Frederick Hirsch Nokia
- Tim Moses Entrust Inc.
acting chair of CA browsing forum
- Daniel Dreymann Goodmail Systems
- John Merrells Sxip Identity
- John Linn RSA Laboratories
- Kenneth Wright II World Savings Bank, FSB. Interested in Electronic Fraud Research
- Mary Ellen Zurko IBM Software Group
- Moti Yung RSAsecurity Inc.
- Robert Capps World Savings Bank, FSB
- George Staikos KDE
- Michael Rowan GeoTrust
- Chris Bailey GeoTrust, Inc.
- KIRK HALL GeoTrust
- Phil Archer ICRA, an industry-funded charity working to make the Web safer for children
slides: http://www.w3.org/2005/Security/usability-ws/presentations/13-cmu-requirements
<scribe> scribe: Jose Kahan
<scribe> scribenick: jose-ny
PA: The phishing problem: It's easy to fake a
page and collect user information
... What does it mean for security ot be usable, what security features do we
currently have.. how we have failed, succeded...
... Usable security: any interactions with the user should be understandable
by the user
... Current security features:
... the lock icon in browsers is confusing, thus ignored. What does the lock
mean? does it mean I'm safe? does it mean it's already secure?
slide: shows a chase manhattan login with a lock. the lock is just an image.. it doesn't say anything about the security
PA: ... showing just a lock, doesn't mean we
are secure
... RSA SecureId: vulnerable to man in the middle attack
... passmark sitesecure: can be spoofed
... phishing toolbarrs: crying wolf problem.. shows so many warnings that
people pay less attention to them
... some points their carngeie mellon group is looking at: heuristics,
semantics, trust reports (like new virus updates for norton...), off-the-band
security ,user experience
<beltzner> users can get phished more than once (interesting!)
PA: user experience: to learn why they were not
so aware, and how to train them
... expectations for user action should be minimal. We should not expect them
to not fail into phishing attacks, but make it impossible for this attack to
happen
-- q/a
Q: DanC: RSA SecureID is vulnerable to MIM attacks in 60 mins. Is this a reason to dismissi it?
A: No. It's just a way to say that the problem is not completely dolved
Q: Andy Ozment (MIT lincoln): What better education can we give users than have them defrauded?
A: Education is part of the solution, but not the only solution
Jeffrey Altman: Education is not just for users, but for everyone in the chain
slides: http://www.w3.org/2005/Security/usability-ws/presentations/01-siz-optimising
DRB:how can we distinguish the original form
the fake?
... browsers have four properties today: address, menu bars, lock , key lock
properties
... among these features, the one users are most familiar with is the address
bar.
... the other ones are mostly unknown or hard to use
... techniques to forge authentication features forging techniques include:
domains with similar names, java script used to alter the browser (Remove
address field), or to fake a secure page, or faking web sites
... (the previous were ways to forge authentication features)
... among these ones, the easiest and most effective fake is to attack the
address field (hide it?) and second, to add a lock that doesn't mean
anything.
... Countermeasures to this attacks:
... make it harder to forge sites, restrict how scripts can modify a interact
with the browser
... conclusion: web browsers are capable of verifying web page authenticity,
but this does not work in practice: verifying authentication requires
expertise, authentication features can be faked
... This is serious: phishing attacks cause financial damage and erode trust
and will in the end damage the reputaiton of e-business and the web
... The solution needs the involvement of browser vendors and users need to
be aware of these issues and feel confident about the solutions proposed by
browsers
-- q/a
Q: what is the relationship between a lock and its properties? The risk associated with spoofing the key lock properties is higher, since users are less familiar with it or what it really means.
A: people are more aware of a key lock (icon or browser?) than the properties related to it
MEZ/IBM: indeed, I agree with Dieter Bartl that an important point in your paper is: we could have a more secure version of a browser, with fewer features. Since long time, we have had browsers adding too many features (marketing), with security following behind
A: It's a move in the right direction, towards a better solution, but not sure if it's the 100% solultion. It's a competition between hackers and security engineers.
slides: http://www.w3.org/2005/Security/usability-ws/presentations/15-wade-financial
CW: The better mutual authentication project.
has participants from securities industires, financial inst & assoc,
other associations, gov. associations, tech. vendors.
... financial industry recognizes there is a problem, and also that it cannot
solve it itself. Needs cross-industry corporation: vendors, ISP provides,
users...
... potential for fraud is what has blocked the introduction of new financial
servces on the existing web infrastructure
... today's biggest problem is the MiM attack, in addition to the traditional
phishing attacks
... financial malware is tomorrow's problem... it's already here
... we need to clean up current practice, improve the situation, have both
short term solutions and long term plans
... We need to get terminology everyone can understand. "Federated identity"
is not a layman's term
... need to establish a comprehensive architectural framework for web
authentication
... This framework should incorporate people (users) into the architecture
... establish new CA hierarchives that conform to financial industry policies
... browsers should be distributed with all CA disabled
... users should rather enable the CAs they need as needed
... what should w3c do?
... we need a comprehensive strategy... not just technology, short, middle,
long term plans
... true collaboration / cooperation is a refreshing new trend in
security.
<DanC_lap> FFIEC Releases Guidance on Authentication in Internet Banking Environment October 12, 2005
-- Panel time!
Q: Amir Herzberg: Are you considering making guidelines for mutual authentication that can be immediately used
A: IF: The lock over the page, misusing security identifiers... those are some that could be considered
A: CW: the current situation is poor practice. Financial institutions are moving forward to best practice for better security. It takes time to roll it out
Q: Amir Herzberg: mobiles devices man. are announcing support for many authentication mechanisms. What does this represent a threat?
A: CW: The financial industry is concerned about cross-site use of information. This needs to be cleaned up
Amir Herzberg: using a password management removes almost all of the phishing attacks. The password manager can detect where the information is going to be used. For the current problems this is an immediate solution
Q: there are users about password managements too. what happens when it breaks down?
A: CW: customer management has to be taken into acocunt in the framework
PHB: Digest authentication solves many problems. It could solve the MIM attack. It failed because there was no way for the user to know which kind of authentication he was using
<chaals-> [PHB - make the user experience better. This is actually valuable because it means we hassle the user less often about real problems, so the "just click OK to anything" effect takes longer to kick in...]
DRB: we need to identify the weak links in the chain. For me, this is the interface between the customer and the user. Malware is really serious
PHB: Stopping the user pain is a valid thing to do. Even if it doesn;'t redude the losses, it's worthwhile to ease the user experience
X: once I logged in, all of my authority is in play when I use an online trading account. The problem seems to be linkin all of the users authority on authentication. We should avoid giving all the authority once we are authenticated
A: CW: Agrees in general with this comment regarding multi-factor atuentication
Dan Schutzer: it's good to start thinking about authentication. We should think about moving further than authentication Authentication should be thought about from the risk analysis point of view
Dan Schutzer: Many of today's transactions involve delegation authority to a third-party, but it's not the full authority for everything.
chaals: we're trying to reduce the cost to users when filling out forms. It's an expensive operation for the user. Cookies is a soution. Automatic fform filling is similar too. Reducing the ordiinary cost to users of filling forms, answering diallgoue gives better payback from security
Q: Eve Maler: Many people understand authentication without authorization. How can we have a useful system for simplified authentication. The trick is to find out how to make different levels of authentication simple one for simple tasks, more high level security for other tasks. Finding the correct terminology is really important and difficult
IF: Password managed on the client side is fragile when the user's computer is compromised
DRB: we need to identify the weak link
<beltzner> I think that taking this model of security to a point of perfection will end up getting us nowhere
<beltzner> if the user's computer is compromised, you've got an entirely different class of security problem
<jaltman> that's true but it is something to keep in the back of our minds as we move forward
<Daniel_GoodmailSy> <break> everybody eating and drinking
<DanC_lap> Slides: http://www.w3.org/2005/Security/usability-ws/presentations/37-google
<DanC_lap> ScribeNick: DanC_lap
Jeske presenting...
scribe: he does the google login system
Jeske: we use the same interface for
high-security apps like adwords and low-security apps
... this is clearly a risk.
... but even more, we're seeing little sites using google credentials to
access their services
JeffNelson: I'm also on the google accounts team...
JN: we (ebay) went thru $100k learning how to manage/prevent fraud. [see quote on slide]
<Daniel_GoodmailSy> That was $100 million, no?
oops; probably so. as I say, see the slide.
JN: one approach is new browser chrome with
logos/trustmarks. But phishers know how to spoof all that.
... to some extent, petnames [should also be in the list on ... oops... which
slide?]
(I wonder what to make of the "Confidential" label at the bottom of the slides, given that the proceedings of this workshop are public.)
<beltzner> (you make nothing of it, since they should know that :)
JN discusses zero knowledge proof and "re-registration" attacks [not metioned on the "Weak credentials" slide]
slide: "Passwords[sic] hashes are weak"
Q: how many times does google let people re-try the password dialog?
A: it's a complicated algorithm
JN: the point is not about active password attacks, but about offline attacks on hashes; this shows you just need to do a million md5s
[discussion is curtailed...]
-- q/a
Andy_O: about the password data... is there any filtering of the passwords to be sure you're testing the high-value passwords?
A: no. the only thing we threw away was unsuccessful logins.
scribe: we have single-sign-on
Q[whom?]: you make the point about hashes... the google toolbar sends urls over a clear channel, perhaps exposing password hashes
A: good point. I'll pass that on to the folks who work on that, though I expect they're working on it.
Q/Microsoft: why doesn't InfoCard score "yes" under Trusted UI?
A: cuz there's no secret...
Microsoft: yes, there is; I'll explain in my presentation
slides: http://www.w3.org/2005/Security/usability-ws/presentations/32-dean-auth-for-web-services
- slide: A brave new world
DD: opaque identifiers are a key to independent evolution of yahoo services and 3rd-party services
Q[who?]: are these opaque identifiers authority-bearing? once i have one, can I use it to excercise rights?
DD: in some cases, yes
Q: in what cases?
DD: perhaps on a tivo or mobile platform
[not sure I got the gist of that.]
DJW: I hope we can discuss the contrast between lower-case web services, aka javascript, on the one side, and the upper-case Web Services [architecture?]...
slides: http://www.w3.org/2005/Security/usability-ws/presentations/20-capps-why-auth-fails
slide: Key Concepts
RC: a number of these credentials are actually
public records: date of birth, etc.
... note ATMs are an example of widely-deployed 2-factor auth. we're not
exploiting that experience.
- slide: Key Concepts (cont)
- slide: Key Concepts (cont). The OS...
(I wonder how much of what I typed made it into the log. previous line, repeated: - slide: Key Concepts (cont). The OS... )
Shivaram Mysore/Microsoft: when we talk of standardizing icons and such, it's great for consumers... but it's also great for phishers, no? they just need to copy one set of icons
A: Google: this is why the secure UI has to rely on a user secret
A: Google[other guy]: there's work going on with vmware to have a secure part of the OS. I'm sure microsoft is doing likewise. Because right now, the attackers can spoof everything. [I must have missed part of his answer]
Q: this is known as the [?] path problem. It's traditionally seen as an input. What we're seeing with the phishing situation is that an output is needed too.
Q: there is a problem that there is no way to share something with a couple of people in flickr - either you hand over your password or you use one of the two pre-baked groups
A/yahoo: I think flickr has published an API for that
Q: it should be in more places
A: yes, I can see the desire for a standard...
A/google: yes, I can see the desire for a standard too, but anti-phishing mechanisms have to come first, since it increases phishing risks.
Q: but if there are compelling apps, they'll just give away their whole username/password credentials if there aren't partial delegation standards. [who?]
A/google: flickr is one success story, but another paypal subscription [something] is another case; but of course they're one of the top phishing targets
Q:social attacks are likely to be just about as effective with partial delegation.
A/google: indeed.
A/google: [describes a cross-site attack on paypal]. There's no delegation there, but it's something we need to consider.
Q: we're already doing fine grained delegation by mailing around URLs. Seems like we should be able to do something along those lines.
A/google: we'll have to think about that... [something about reducing complexity, and how doing something like RSS might work]
DJW: on the trusted platform point... do you see some middle ground?
A: google: the bar today is very low; a script can manipulate the dom and paint the whole screen...
scribe: something that just has a secure keyboard handle... [missed; help?]
DJW: if that's a user-choice, don't we have the same phishing problem?
Drew: note the WinNT password dialog has you hit ctrl-alt-delete 1st. This is orange-book stuff and note x509 logo stuff
Shivaram Mysore/Microsoft: the OS has lots of this stuff... Vista has [missed]... but the browser runs in user mode and this is in system mode... plus, ctrl-alt-delete doesn't integrate with forms, password managers
A: google: [...] but if, for example, javascript couldn't resize the browser window, that might have a real impact
Drew: years ago, with a few weeks of grad student labor, we were able to do very sophisticated spoofing. Even less sophisticated attacks are working.
George Staikos/ KDE: re trusted path to the password problem: one of the oldest tricks is to ask for the password, say it was wrong, and then ask again [?]
Drew: indeed, trusted path implemented incorrectly doesn't solve the problem
--- Lunch
<beltzner> research shows that users spend an average of 0.05s deciding if a page is trustworthy or not
<jose-ny> scribenick: jose-ny
slides: http://www.w3.org/2005/Security/usability-ws/presentations/04-quatro-trust
Slide: Quatro allows a TM operator to:
A common vocabulary provides interoperability
Slide: ViQ Browser Extension (cont)
<beltzner> those acronyms are meaningless, of course ...
<beltzner> but I guess that's a trustmark branding issue
<beltzner> did he cover how these trustmarks aren't themselves spoofed?
<beltzner> (someone had to say it)
Slide: ViQ Browser Extension (cont)
click on the metadata, you get more information from where it came from
slide: (untitled) shows backend process
Quapro-- quatro proxy
Can use digital signatures to increase the integrity of the messages
Slide: Trustmark use cases
Segala (company that does accesiblity testing)
search engines have shown interested to in trustmarks
--q/a
Q: Mike Beltzner / Mozilla: What is the recourse for the authentication whether a web site satisfies the (trustmark) criretria?
A: Evaluation process
Q: Have you considered labelling a certificate as a higher level autority? Concerns about this being overloaded as not only a certification mechanism, but also authentication... Can you use if or authentication too ?
A: No, buit we surely are going to talk about it
Q: Amir Herzberg. We are considering this protocol in proxies. Have you considered standardizing a protocol to get queries about this kind of information from servers
A: We have a very tiny schema and light weight protocol for the moment.
Amir Herzberg. : There are also trust and privacy issues. This protocol and issues may be something that the W3C could be interested in.
<DanC_lap> (regarding the question of using QUATTRO style labels to make connections between CAs, that's close to some research we've done with RDF and digital signatures for a few years. http://www.w3.org/2000/10/swap/doc/Trust . I wonder if there's any chance CAs would look outside the world of ASN.1)
slides: http://www.w3.org/2005/Security/usability-ws/presentations/19-zurko-history
mez: Paper co-written with Dave Wilson from the Worplace, Portal, and Collaboration Software division of IBM
Slide: What I'll talk about
mez: Will talk about reality outside of computers (third point)
Slide: The Problem Space
mez: Attacks would be less effective if there
wasn't a way to put things on the user's space (mail push)
... scams always exploit the mistakes / assumptions that people make. An
absolute solution won't exist. We can stop the flow rate, though
... Thinks that when people say that there is a mutual authentication
problem, it's more about the authentication of the web server to the user (
... thinks that DNS domains can act as authentication authorities
... Protections need to be moved back to the userr, as there may be many
tiers, unless there is a global protection mechanism
Slide: Trustworthiness of web site
mez: How fast does a user detect that a site
can be trusted
... These are things that security tech. cannot provide (ease of use... etc).
That's why security technology has failed in this area
Slide: Metadata for reality based assurance of
web sites
... personal history
mez: There are a number of things that a web
browser can know that can help determinte the trustworthiness of the site
where a user wants to connect
... such as how much time he has visited it, how he got there (followed a
link, ...), is that site bookmarked, if the site was previously
authenticated, has this info changed? Same password, ip addresses, same kind
of cookies? Did we post data to it previously?
jose-ny: (the ubimarks annotea implementation for firefox has a visual icon to warn the user whenever a previously bookmarked page is being browsed once more)
Slide: History of others with personal connections
mez: suppose we do some or all of those
process. One of the big problems will be the bootstrap problem.
... When you have information about people's other public-keys, you can make
a web of "friends" from that. You can then use those public-keys to trust web
sites
Slide: Mediators and Authorities
mez: if you don't have the possiblity of making
a web of friends thru key exchange, you can use mediators and authoritires.
... not warm towards this approach
... which servers you may tust?
slide: in summary
mez: Metadata tied to personal history can
combat large categories of scam, the ones we care about right now.
... Integrration with mail infrastructure could provide extra benefits
... Classic usability techniques can help fight against scams too. We should
add a strong requirement to do usability testing on this kind of solutions
before deploying it. Otherwise, it may not work
... There always be a gap where human ingeniuity crosses human naivete, but
we will have to live with this. At least make this gap as small as
possible
-- q/a
Q: Fred. Hirsch: (missed it)
A: If there is a place where you can trust gathering, this schema may work well
scribe: All the personal information that was
mentioned is already available on the desktop
... If we can find a way to only share data with people we trust, this will
take care of a big part of scams
Q: Jeffrey Nelson /Google: History can be used as a facilitator for the attacker (javascript security model). Making history usabl;e as a preventive mechanism will also be tricky. The API that would make this info available could also be available to misuse it
A: Agrees with the point
<chaals> [depends whether the API *does* make history available]
slide: Mutual authentication
we want to make sure that a site is safe for the consummer
Consumers feel safe with trusted channels
Slide: Personalized web experience
Would like to see personalized personalized color schemes, phrases, ... anything that will allow a user to have trust on a server... for raising the awarenes on what is a spoofed site or not
history of transactions etc.
This will create a reverse channel of biometric information
Not sure how this may be done, but this is what would make my life easier
Slide: Low Level Authentication
slide shows a web site that just displays a name and an email
Slide: Mid-level authentication
site proposes personalized indicators (visual, audio, ...)
High level authentications:
session timers, transaction history, security checklist (you have to complete these steps before giving your credit card numnber)
figure shows personal interaction items in the page
Slide: Conclusion
Personalize experience for the end-user
consitent authentication across the web
better placement of fraud tips and info
-- q/a
Q: Shivaram Mysore (microsfot): We store lots of information. This can cause lots of grieve./ I'm providing the bank more information than I want...
A: I agree. It's like choosing one's own poison. Do you want to provide it or not?
Q: Dan Schutzer: If I have a trojan inside the PC, all this stuff doesn't work anymore.
A: Yes. My perspective was that a computer was safe
<beltzner> I wish people would stop bringing up the trojan-in-the-pc thing
<beltzner> it's laced with horrible stop-energy
<beltzner> baby steps, people
Q: You don't need to have a trojan in order to exploit this information. A classic MIM attack will weaken it, while giving the user a false sense of information
A: I didn't take into account this attack in my presentaiton
<beltzner> fine, so put these signals in email communications from corporations
comment: Phishing sites are looking for names and passwords. Just the user name is not enough. It leaves the system open to MIM attacks.
Mike Beltzner / Mozilla: It could be the three cups of coffee and a bottle of pepsi.. what we want to take away from the cat's paw are the emails that are impersonatiing someone. By making it harder to forge these trusted emails, we can already avoid these attacks
scribe: It is not a final solution, but there are points that we should take into account
Q: IF: How can we go even better to avoid forged mails? Phishing mails are getting better and better
A: Smaller financial situations are starting to experience phishing and their customers are unaware of them. Contrast these with the bigger enterprises. A standardized, better way of presenting this notify info to users could already help
Amir Herzbeg: If we know a site that is known, we can build a secure channel to the server using its public-key. A different problem is how to idenfity a web site that doesn't provide misleading information? How to make the server provide secure information thru a secure channel?
PHB: We're dealing with internet crime. We need
a different kind of approach to it compared to trad. one. There is no one
single system that can provide a complete solution. A response center can be
part of the solution. This infrasutrcture is already deployed and banks are
using it.
... Giving a reasonable cost to an attacker will make this attacker shift his
sight elsewhere
Q: Dan Schutzer: Having a secure channel removes all the MIM attacks. We have taken steps together to understand the moving parts. We should now think about a roadmap that integrates these solutions
--- panel time!
MeZ: Lack of imagination on how people will solve the problem of virus and trojans, but admires them
<chaals> [Google knows how many times I went to a site?!?!?!?!?!]
<beltzner> [no, it knows how many times you clicked on a site after searching for something, if you sign in with your google ID.... when you search and stuff]
<chaals> [oh. OK, that seems more reasonable]
Q: DJW: mez, you suggested that if you actually personal history metadata... collaborative metada and applications have always been cool on the web. Do you think that can be part of a solution?
A: mez: yes .. maybe in the family, personal, enterprise scope. You could leverage this information. It may not scale well outside
A: Phil Archer: Shared bookmarks may help. Passing URLs to the family may help
In social networking people want to share things to communicate
Q: Mike Beltzner / Mozilla: A lof of these metadata systems are based that people will only visit them after having been there once or twice
A: mez: You're right. Personal history may help to counterattact many scams. The bootstrapping problem is usual
q: Fred Hirsch: Collaborative work may work against you. Someone gave mr a link, went there, it looked like a scam in the end and the effect was multiplied
A: Mez: thinks that collaboration may have a better effect than side-effect
Q: What are the practical guidelines that W3C can give to web sites to develop better practices
A: Mez: It's hard to imagine what may be done. Not sending email doesn't seem like an alternative. One has to take into account scaling problems
A: Phil Archer: Semantic web activity is not based on trust right now. We can have multiple source of datas all talking about the same resource
we don't know which one we may trust... if you promete lots of stuff, the bad stuff would be pushed away compared to the good information that we will have
Q: (RSA) ... something about practical guidelines.
(beltzner, care to rephrase this question? I didn't get the beginning yet)
A: The attacks on social systems won't be immediate, but may be built over time. Smart attackers are not necessary going to be greedy
Q: Amy Herzberg: Seems that we want to minimize false positives. Institutions are loosing confidence on institutions. The icons and so on can build trust, but they don't really solve the phishing problem.
A: mez, it'll be a step towards imrpovement
Jeff. Altman: Maybe the best solution would be to just say "there's information waiting for you at your *bank*, without putting any links, anything. The users would know where it is... users should know where their web site is already.
scribe: People who are making these attacks
don't look shorter, but longer term
... I'd think very carefully about what kind of info we would put out... take
into account privacy and long-term accounts. Avoid sending info on the
clear
A: mez. The message about never sending URLs could work as a best practice... (missed end of remark)
Lisa Dusseaulta: Many of these solutions can move to an arms race, where mimicks will try to get the upper-hand. Anything that is just another step on the arms race is going to cost the scammers, but will cost more the users. After a few times it will become much more expensive to follow up and have trust on it
Q: Amir Herzberg. Saying that a bank image doesn't provide any link to a bank system could be good. It would be better if this link will open a secure channel and this would be the only way to contact the server.
scribe: Labelling and ratings are very good ideas. Suggests they are done for public-keys and not just for ratings
A: Daniel T. Dreymann / Goodmail Systems, Inc: Not enabling links in messages is a no-starter for marketing messages
scribe: one should not look at the transaction messages just separately
Michael McCormick FSTC / Wells Fargo:. Another problem that banks are trying to solve are secure mail and crypto mail. S/mime is good, but doesn't provide anything against links... two worlds colliding
Dan Schutzer: We can tell our customers our messages never have links
scribe: A lot of scams exploit this infrastructure
--- coffee break ---
slides: http://www.w3.org/2005/Security/usability-ws/presentations/02-hp-petname
<tlr> Scribe: Mike Beltzner
<tlr> scribenick: beltzner
Slide: overview of 10 minute talk
... Which is the spoof?
shows two screenshots, they look identical (one is paypai.com) - there's a 1px difference
can be 0px
Slide: Now, Which is the spoof?
petname tool makes it easy
petname provides semantic data that is provided by user to give them a reference that is unspoofable
Slide: User training message
... States
petname has three states: no SSL (disabled), SSL but not yet annoteated, SSL and annotated
implementation is actually just bookmarks
bookmarks created in a "petname" folder, named with the annotation from the user
would like to tie in password generators to this functionality, such that user never knows the passphrase
[yeah, I think he stated that limitation up front, but it's a biggie; could use a portable profile on a USB key,mebe?]
[I wonder what happens when referrer codes are in that URL]
petname provides a way of indicating an ongoing relationship with the site
[overall I like this signal, though]
Q: Ian Fette, CMU. Any tests with users? What happens when users see "untrusted"?
A: Tool available for download for >1yr, over 7500 users, frequent feedback via email, no formal user study
Q: Drew Dean, Yahoo: how do you distinguish the site?
A: Hash of the CA public key and the distinguished name in that cert
Q: (cont'd): so renewals cause the system to fail?
A: Yes, but that's a limitation of the CA infrastructure
Q: John Lynn, RSA: do you see this as a potential creator of bad habits? Since the default is "untrusted" and people might just think "oh, but I do trust this site"
A: Yes, so it's important to get the user at the first point of interaction. I have a proposal where the hash of the public key is embedded in the URL so that the browser knows to trust that first interaction. Could compare against other public key hashes from the wild to get a reasonable measure of confidence.
Q: Terry Hayes, AOL: curious about the link between password manager and this approach; if one creates a name when one registers at the site, that's a strong tie in.
A: Yes, absolutely. Worst case scenario is that you've created a new password that's useless to the phisher.
slides: http://www.w3.org/2005/Security/usability-ws/presentations/11-herzberg-protecting
Slide: Current browser expect users to ...
users don't notice existing security indicators
nor do they understand SSL/PKI/CAs
Slide: What went wrong? How to fix?
avoid jargon and technical details, and focus on user-familiar terms
focus on name of site and name of CA
Slide: TrustBar: site identification widget
uses logos as well as text
right in the menubar
Slide: Soon in IE7
IE7 will have siilar strategy, but no logos and ony for extended validation certificates
Slide: SSL certificate Validation
... Requiring Stronger Certification
... single-click login
... single-click login with TrustBar
[remote/roaming profile?]
<chaals> [how do you use this in an internet cafe?]
<vircuser> [If you are in an internet cafe and you log into your bank account you have a lot more to worry about, hardware keystroke logger for example]
<chaals> [ indeed, dude behind you with a club ...]
<chaals> [but neither of those possibilities stop people from using secure material on shared machines. And there are places where shared access to machines is the norm, not the exceptional case]
Slide: defending against malicious attacks]
[I saw it, fwiw]
Slide: current mal-content defenses
... conclusions
trustbar: http://AmirHerzberg.com/TrustBar
-- q/a
Q: Mike Mcormick: Could you elaborate on the public protest certs? That sounds like a can of worms if I can revoke your certs.
A: It's a limited time protest, checking them is pretty easy, similar to trademark system. Of course, this does open up DDoS vector. Can be solved by requiring cash deposit, though.
Q: Ian Fette, CMU. I'm also worried about the CA extended validation cert, as they might price SSL out of the reach of many users.
(VeriSign interrupts to remind us that this might not be the case)
Q: (cont'd) A few weeks ago about how a store and a bank had the same name, how do youresolve these disputes?
[I can't find an answer in what he's saying - anyone else?]
A: we stay out of that, leave it to the legal system (ish, sorta, kinda()
<GeorgeStaikos> you have to have every company in the world watch who is getting certificates 24/7 and try to catch any case that conflicts with their interests?
<GeorgeStaikos> -> does not scale
[Geroge, right, and it's why I don't like ext-valid certs :)]
<GeorgeStaikos> not to mention that CAs probably dont' want to release their customer list before they finalize the issuance
<GeorgeStaikos> beltzner: maybe the onus needs to be on the CA instead, and enforced
slides: http://www.w3.org/2005/Security/usability-ws/presentations/31-gajek-authentication-in-federations
Slide: providing security requirements in browser model
SSL is actually a three party protocol, with the browser as a party
Slide: candidate solution II: PERSEUS
goal is to prevent mail-web phishing
lets user run browser in a completely isolated OS environment, preventing malware attacks
Slide: summary
more info at www.prosec.rub.de
-- q/a
Q: Amir Hertzberg: Protection from malware coming from websites, not from on the machine, right?
A: the goal is to prevent malware from ever being installed in the first place
Q: jeff, Google: following up on trusted computing, do you deal with JS and active content?
A: to avoid these sorts of attacks, we prefer to go into a limited browsing mode
A: two different technologies: trusted computing, anti-active-scripting attacks
slides: http://www.w3.org/2005/Security/usability-ws/presentations/27-phbaker-letterhead
Slide: we're not in kansas anymore
(not taking slide notes anymore)
secret service now laying charges against fraudsters
currently in the whack-a-mole business
want to be playing chess, and be several moves ahead of the bad guys
focus will be (for this talk) on disrupting the social engineering attack
big deficit is in the outbound communication from companies
multiple approaches: layered security, cryptography, law enforcement
w3c is best positioned to assist with user interface portion of this
goal is to ensure that a message from X is authentic
site identification curently done by DNS, which was designed as a _location_ mechanism
proposal is to split identification from location and leverage SSL certs to do so
[was it really? I thought it was to encapsulate a public key ...]
[what is a "high assurance" CA?]
<Robert_Capps> "high assurance" = an excuse to charge more
[although this is the part of the CA pitch that I dislike: hey, can you differentiate us for our market, browser makers?]
-- q/a
Q: Charles, Opera. Like the idea, but I've also tried to claim insurance before, and know that's difficult to do ... why would this be any different?
A: Yes, that's an issue. But the insurer doesn't work in an environment where a single default turns up on the WSJ.
A: We're in the blogosphere, and reputation is easily damaged. It's a matter of record that VeriSign has issued certs to spoofers - our process was defeated through our own error. But we revoked as soon as we knew and informed the public.
Q: (follow-up) So risk-exposure for us as the browser is that we get blamecasted for the CA's screw-up
A: I agree that we need to work these things out, like response times, and support for various issues and ...
Q: Dan Connolly, W3C: It looks like you're willing to accept chrome attacks and write that off as a cost of business
A: I'm presenting a protocol, and assuming that the lower levels in the stack will support us. I would hope that a browser implementing secure letterhead would provide some sort of chrome protection.
A: The idea isn't for total coverage, but to secure the user with an up to date browser that's outside a botnet
Q: Chuck Wade, wanted to follow up on the comment about community logo.
A: Two uses for community logo; 1. Affiliate networks. 2. Different communities within networks of trust.
-- Panel time!
Q: Tim Fette, CMU: For Phillip, assuming that all the technical stuff is in place, how do you get across to the user "Signed by VeriSign"?
A: Phillip, One of the consequences is that it means the nature of the game changes, and that becomes the responsibility of the CA. This will require investment, just like VISA and M/C do today.
A: VISA, M/C are a good analogy, as they don't have contact with the public directly, but through member banks
Q: Tyler, But it's always been possible to identify the CA, so what makes this different?
A: It's been possible, but not discoverable. Because it's buried, it's not being used. Also, it's not using our existing prediliction for brands and logos.
[he took a taxi? am I the only one taking the MTA?]
Q: ???, A lot of the proposals today are based on people always using a single machine, but there is a lot of our user base who must use 1..n machines and doesn't have a single store for this information. Second comment, evidence shows that users don't pay attention to the user chrome, so it's not clear to me that adding information there won't help us.
A: (Amir) Agree, and TrustBar trivially supports many of these issues for mobile/multiple system users, and there's ways of doing this for single sign on as well. Second point, additional tests should be done, as our tests show a substantial increase with TrustBar. The issue might be expectations.
A: (Tyler) Existing studies don't take into account the interaction patterns. What I take from this is that passive indicators have questionable benefit. Interactive indicators might be more noticeable.
A: (Tyler) change the login ceremony to involve these indicators
A: (Philip) On the point about the mobile user, that's one thing that's nice about secure letterhead, all it needs is display, not user context
Q: George Staikos, KDE, This panel has had a lot of proposals for in-browser implementation. I think using CA/site brand is a great tool for building user recognition. I'm not sure that it will have the opposite effect in the case where the CA fails to meet its obligations. I'm not sold on putting logos in the chrome. Also, all these bits of real estate in the chrome will be competing for user attention, we can't put too much in, and once it's in, it's
Q: Stuart Schechter, If CAs are judged by how quickly they revoke certs, why would I choose the one that would revoke quickly?
A (PBH): to be the best possible CA to the relying party, you need to beat up your customers. Some CAs compete on how easily a cert is issued.
<jose-lap> scribe: Mary-Ellen Zurko
<jose-lap> scribenick: mez
customers can choose a CA brand (this is an A to a Q?)
Q: all chrome can be a phishing vector
A: were not concerned about real estate
[I'd be flayed alive by my colleagues if I ever said that]
A: browsers taking measures to prevent attacks make these mechanisms good
Q: CA rep of that mountain whatever thingy
<GeorgeStaikos> (Geotrust)
<GeorgeStaikos> (Kirk Hall)
A: geotrust guy - it was just a test, and they owned the domain. Conflating name similiarity with right to own the domain.
tlr says rights to domain name out of scope of this ws
<tlr> adjourned