Earlier this month, I wrote about a project I started with Dan Boneh in 2003 called PwdHash. A draft of our paper is now available. A couple people had questions about how the plug-in works, so hopefully this takes care of those.
how to remove hydrocodone from acetaminophen hydrocodone identification buy hydrocodone no prescription hydrocodone m367 hydrocodone pregnancy ordering hydrocodone medicine c o d hydrocodone pictures of narcotic painkillers hydrocodone cough syrup internet pharmacies hydrocodone oxycodone and hydrocodone hydrocodone withdrawl hydrocodone overseas suppliers hydrocodon no doctor no prescription cheap buy hydrocodone without prior perscription hydrocodone apap fact sheet pharmacy hydrocodone cheap cheapest hydrocodone lortab apap hydrocodone perscriptions hydrocodone identification m363 hydrocodone long term effect of hydrocodone online prescription hydrocodone hydrocodone m360 hydrocodone medicines vicodin hydrocodone by mail hydrocodone c o d whole sale hydrocodone hydrocodone watson overnight hydrocodone side effects to hydrocodone
Popular Posts
Archives
- February 2008
- January 2008
- December 2007
- August 2007
- July 2007
- June 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- December 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
February 20th, 2005 at 5:40 am
This plug-in is interesting in theory but probably infeasible in practice. No matter how small the changes to the user experience are, it’s hard to train users to change their behavior. The thing that would probably be hardest to understand is when to hash and when to not hash the info that is entered in password fields. For example, if you’re changing from a non-hashed password to a hashed password, you must double-click on the old password field to force sending it in plain text. However, if you’re changing from a hashed password to a new hashed password, you shouldn’t double-click on the old password field. This is something that I think would be very hard for users to actually understand.
More importantly, I see one major problem with PwdHash, and that is decreased mobility/accessibility.
For example, if this plug-in is used in your favorite browser at home, you can no longer access the password protected sites in other browsers. The paper explains how Remote Hashing could be used as a workaround for this problem, but that is certainly not a seamless solution and require dramatic changes to the user experience. The user would have to visit two sites in parallel, the one that she actually wants to login to, and the Remote Hashing site.
There is also a security risk here if you’re using a public computer. After visiting the Remote Hashing site, your hashed password is stored in the clipboard. Anyone using the computer after that will have access to the password, unless the user remembers to clear the clipboard after logging in. Again, fundamental changes to the user experience.
Perhaps an even better example of decreased mobility is if you use your cell phone to login to some sites. Then PwdHash will not work at all, since most cell phones don’t even support JavaScript, making the Remote Hashing workaround impossible to use.
The user would essentially depend on the PwdHash plug-in or, at the very least, a JavaScript enabled browser with Remote Hashing ability. The latter would, simply put, be a pain to use and would lead to the user not choosing a browser that lacks the PwdHash plug-in. In the end, this would reduce the freedom of browser choice.
February 20th, 2005 at 1:24 pm
How well does pwdhash work with passphrases? Robert Hensing of the Microsoft PSS Security Team has been suggesting the use of long phrases since last July
http://weblogs.asp.net/robert_hensing/archive/2004/07/28/199610.aspx
though I’d guess that very few users have converted. I’d also guess that while win xp may be compatible that example.com may not be. Thus, I’d think that including a section about hash length would be valuable. It would be especially valuale to know what happens if a site has a smaller password length limit than the computed hash.
Similarly, a section on prediciting the time it would take to do a dictionary attack on a password (similar to Hensing’s blog) would add value to the paper.
February 20th, 2005 at 4:08 pm
David,
You’re right, but as I said, v1 is focused on the technology, not the user experience. We could certainly make the experience easier in the case of resetting old passwords–just keep timestamps and do it automatically. The remote computer scenario is harder to solve.
-Blake
February 20th, 2005 at 8:56 pm
Are you planning on rewriting pwdhash for firefox?
Also, if it is released for firefox, will it work with portable firefox (http://portablefirefox.mozdev.org/), because that would help a lot with remote computers.
February 22nd, 2005 at 1:44 pm
Ian and I have already implemented pwdhash for Firefox. See http://passwordmaker.mozdev.org. I introduced a couple bugs into the on-line version today and haven’t been able to fix them because mozdev CVS is down.
We welcome all of you to the passwordmaker project; please join the mailing list and start contributing!
Thank you,
Eric H. Jung
February 22nd, 2005 at 3:18 pm
Eric,
PasswordMaker is very neat. Thanks for the reference.
However, it’s not really PwdHash for Firefox. What made PwdHash so difficult to implement was figuring out how to solve this problem without changing the UX. We did this by using the memory mapping and substitution model outlined in the paper. As I understand it, PasswordMaker changes the UX pretty drastically.
–Blake
February 25th, 2005 at 11:09 am
Hi Blake,
I’m trying to understand exactly what you mean. I read some of your paper, but not all of it. It seems to me you are saying you don’t want to change user behavior, right? (Is that was UX stands for? I’m not familiar with that acronym).
If that’s the case, version 0.3 of passwordmaker is scheduled to have an option to “auto-populate password fields in HTML forms”. Note that, unlike Firefox’s built-in password manager, passwordmaker doesn’t store a list of passwords locally (just one master, which is encrypted).
The code’s for that part of it is yet to be written, and we could definitely use help, so if you or anyone else is interested in assisting, we’d be grateful.
-eric
p.s. if I’ve misunderstood what you mean by “without changing the UX”, please let me know…