I’ll call this kind of window “Opie” for the rest of this article.  Occasionally, a program will prompt a user not for a file, but for a folder.  In such cases programs will typically bring up the Folder Selection dialog window, which I’ll call “Dopey“:

Had I never known Opie, I might not dislike Dopey.  Since I do, however, I find Dopey to be a vastly inferior and annoying UI element, for several reasons:

1. Dopey can’t get to a folder directly.  Most of my files are nested four or five levels down from My Documents.  When I’m working on a project, I’ll typically have one or more of these level-4 folders open in Windows Explorer.  When I need to open one of these folders’ files from a Windows program [1], I’ll typically copy the folder path from Windows Explorer,  paste it into Opie’s “File Name” field, and press Enter.  Voilà, I’m now looking at the folder I want, and can select the file I need.  Dopey doesn’t let me cut and paste a path like this.  (Some programs complement Dopey with a field where a path can be typed or pasted, which helps a bit.  Most programs, however, leave you alone with the klutz.)

2. Dopey can leave me disoriented.  Dopey provides very little context to let me get my bearings inside the file system.  I often find myself looking at a list of neighboring subfolders, without any idea of who their parent is:

If I want to determine a folder’s parent, I’ll have to scroll a bit, and scroll quite a bit further if I need to determine its complete ancestry.  Once I determine the full path, I’ll have to scroll back to my original location (if I can find it).  Opie, on the other hand, lets me determine the full path (without getting lost in the process) by clicking on a drop-down arrow: [2]

3. Dopey makes me stumble my way down into the file system.  Navigating the file system with Dopey is cumbersome.  I start out with a little window displaying just a few folders.  I have to switch between clicking, scrolling vertically, and scrolling horizontally as I dig down into the file system.  With Opie, on the other hand, I can often get where I want  just by double clicking, often without any scrolling.  [3]

I’ve run into a few programs that show me Opie instead of Dopey when prompting for a folder.  I wish more Windows programs did this (hear ye, hear ye, Windows application developers!)  Ultimately, I hope (in vain?) that Dopey will be deprecated by Microsoft, banished from our UIs, and sent to join Clippy in exile.

 Notes:

[1] Yes, most files can be opened by double-clicking them in Windows Explorer.  However, I still find myself using File -> Open pretty frequently.  Somehow it’s more convenient than Explorer at times.

[2] For some programs in Windows 7, you don’t even a need to click a drop-down, since Opie looks just like Windows Explorer, and includes an address bar.

[3] This is due to the fact that Opie displays only a single level of subfolders at a time, and can display them in a multi-column list, which reduces the need to scroll or enlarge the dialog window.

More than shocked, I am saddened to see such a large sum squandered like this.  These patents won’t spur on innovation.  They won’t make their new owners into better companies.  At best, they’ll serve as (unreliable) insurance against the artificial, legally-facilitated disasters known as patent-infringement lawsuits.  At worst, these patents will act as a weapon of mass destruction, one that can inflict the same kind of fear and damage it’s supposed to guard against.  They’re a weapon to be aimed at competitors… and ultimately at society itself.  (Likely cost to society: more monopolies, narrower concentration of economic power, damage to or destruction of innovative companies that provide great value and wealth, among other costs.)

Seriously, what a waste! Those $4.5 billion could be used instead to jump-start true innovation.  If that sum were used to pay $100,000-a-year software-developer salaries, it could fund 45,000 developers for a year, or 9,000 developers for five years.  What if those developers created software startup companies?  How many startups would that be?  How many new products and services would they give back to society?  To what degree would they doubtlessly stimulate the economy?  This is just one way in which such massive economic power could be used for good.  Surely there are other worthwhile possibilities…  But none of them will take place, in this case.

This $4.5-billion loss was enabled by the decrepit patent system currently in place in the U. S. (and possibly Canada.)  Lawmakers: Please consider abolishing software patents (and whatever is equivalent in practice to a software patent.)  Your society will be much better off.  Also, please take a hard look at other kinds of patents.  Ruthlessly question whether they truly foster innovation rather than litigation.  Do not give them the benefit of the doubt.

(Note: Some readers might protest my meddling, since I do not live in the United States nor Canada. However, U. S. laws in particular have a disproportionate influence on the rest of the world, for better or worse.  It is hard to remain respectfully silent, even for someone who is not directly a U. S. constituent.  In any case, I care about the whole world, and that includes caring about the U. S. and its well-being.)

I recently read “How to Safely Store a Password”, an article by Coda Hale. For years I’ve thought that salting and hashing passwords with MD5 or SHA-1 prior to storage was sufficient to thwart password-cracking efforts (in cases where the user-account database table is stolen or publicly divulged). Apparently, this approach is not much better than simply storing plaintext passwords (a practice widely scoffed at). It was fascinating to find out about a better approach, that of using bcrypt instead of ordinary hash functions. Unfortunately, it seems to me that bcrypt creates a new problem even as it solves an old one…

The New Problem

The use of bcrypt turns password-cracking into a computationally-prohibitive task for attackers. However, bcrypt also hurts defenders, for whom password-hash generation or verification is now much more expensive than with ordinary hash functions. A popular online service having thousands of users might need to acquire additional processing power simply to process user log-ins. Moreover, by using bcrypt a service would become more vulnerable to denial-of-service attacks. Attackers could tie up its servers’ CPUs through numerous, automated log-in attempts. (These would make the servers call bcrypt repeatedly, once for each of the many log-in requests.) Addressing this threat would seem to require problematic tradeoffs between security, cost and convenience.

Could there be a way of lowering a service’s computational bill while retaining bcrypt’s advantages? This article presents a system which might accomplish this. I haven’t heard of this approach and would like to know if I’m on to something (or if others have already devised equivalent systems). Be forewarned, I am not a computer-security expert. (Thank you for reading this article anyway.)

A Potential Solution

The following protocol attempts to reduce the frequency with which bcrypt is called by an online server. It ensures that clients also pay for the cost of using bcrypt. (The server still has to pay, but the client now has to “split” the computational bill with it. This could reduce the appeal and effectiveness of brute-force or dictionary attacks on live systems.) This protocol redesigns the account-creation, account-log-in, and password-reset processes for an online service.

Account Creation

1. Joe Turing, a user (or a bot, perhaps), visits the account-creation page for SecureR, a hypothetical (yet surprisingly-popular) online service.
2. Turing types in his desired username and password and submits them (securely) to SecureR.
3. The SecureR server creates a bcrypted hash from the password, using a random salt value and the cost parameter currently mandated by SecureR’s security policy.
4. The username, password, salt, cost, and bcrypted hash are stored in a record in SecureR’s user-account table. The record also includes at least two verification fields. One indicates whether the password hash has been verified (successfully computed by the client). The other indicates whether the account as a whole has been verified. Both fields are initially set to “false”.
5. SecureR sends the salt and cost parameters used to bcrypt Turing’s password back to Turing.
6. Turing (that is, his web browser) computes the bcrypt hash corresponding to his password and submits it to SecureR.
7. SecureR compares Turing’s hash with the hash previously computed by SecureR itself. If the two hashes match, the password-hash-verification field is set to “true”.
8. Once other essential checks (such as e-mail-address verification) have been successfully performed the account-verification field is to “true”. Turing’s account is now fully verified and active, and he can start using SecureR’s services. (For now I won’t suggest when and where additional verification steps should take place, since bcrypt is my focus here.)

Account Log-in

1. Turing types his username and password into the SecureR log-in page.
2. Turing’s browser sends his username to SecureR.
3. SecureR looks up the salt and cost parameters contained in Turing’s user-account record.
4. SecureR sends the salt and cost values to Turing’s browser.
5. The browser uses these parameters and Turing’s typed-in password to generate the bcrypt hash for Turing’s password.
6. The browser submits Turing’s username and bcrypted hash to SecureR.
7. SecureR directly compares the hash submitted by Turing with the one stored in his user record. If they match, account access is granted.

Password Reset

1. Turing types his username into SecureR’s password reset page and clicks the Submit button.
2. SecureR sends a verification link to Turing’s e-mail address. (This link is to verify that Turing himself initiated the reset process. This password-reset system never generates nor sends temporary passwords to the service’s users.)
3. Turing checks his e-mail, and opens up the link with his web browser.
4. The page brought up by the browser has a password field, into which Turing enters his new password and clicks on a Submit button.
5. The password is hashed and verified using a process analogous to steps 3 through 8 in the account-creation process.

Observations

According to this protocol, SecureR’s server only runs bcrypt when an account is created or when a password is reset. During log-in attempts, it is the client (Turing’s browser) and not the server which runs bcrypt. The server performs a computationally-inexpensive direct comparison between the client-submitted hash and the hash stored in its database. Thus the server avoids paying the bcrypt bill when processing a log-in request. (In theory, the client could also avoid calling bcrypt during log-ins. The bcrypt hash could be stored by the client after generating it during the account-creation phase. The client wouldn’t necessarily have to recompute the hash each time the user logs in. In practice, it’d be easier to design the client-side code so that it recomputes the bcrypt hash based on the user’s plaintext password, rather than dealing with hash storage and retrieval. The bcrypt-induced client-side log-in delay is tolerable to each individual user anyway.)

Relocating bcrypt invocations from a frequent process (account log-in) to other, less frequent processes (account-creation and password-resets) reduces the risk of a successful DoS attack. It doesn’t eliminate the risk completely, though. The account-creation and password-reset processes are the new weak spots, and must be hardened. This is why the password-reset process is more complex (and mildly annoying to legitimate users) under this protocol. Additional security methods (such as CAPTCHAs and rate-limiting) could also help harden the system against attack.

A Request for Feedback

My proposed protocol omits certain security-related details which would be important in a production system. I’ve also omitted some tweaks which could further improve the protocol’s security. However, I’d first like to make sure that this protocol is essentially sound. Please let me know if you find any logic errors or problematic side-effects I’ve failed to account for. As I said before, I am not a computer-security professional, and would appreciate assistance from others who are further along.

Sometime after watching this scene, I was struck by the realization that Facebook is like the island of the lotus-eaters to me.  I usually log in with a definite purpose in mind, such as looking up an old friend or confirming an invitation to an event.  However, immediately after logging in and before I know it, I find myself scanning through the News Feed, looking at random, yet interesting tidbits about friends and old-time acquaintances.  Many minutes will pass…  Once I finally realize what I’ve been doing and break out of the hypnotic effect, I’ll typically have forgotten why I initially logged in.  It takes me a couple of minutes to remember.

Facebook is not the only “island of the lotus-eaters”, but it is a very striking example.  The digital world is full of such islands.  It takes superhuman levels of self-discipline to stop landing on those islands or binging on lotuses.  Yet there are more important and substantial things, and I must resume my quest…

Person “So-and-So” chooses “CleverName” as their username on social-media service “Socialr” [2]. CleverName is So-and-So’s favorite pseudonym, a word or phrase with a personally-significant meaning. So-and-So starts using Socialr, and over a period of time builds up a digital identity on Socialr, an identity whose name, content, history, and reputation are associated with username CleverName. Some time later, a little-known company, “Company X”, comes along and wants to create an account on Socialr. That company happens to be named or have a product named “CleverName”. Company X asks Socialr to take username CleverName from So-and-So and give it to them. Socialr seizes CleverName from So-and-So and gives it to Company X as their username.

This kind of situation is likely to become more common as thousands of individuals and companies (and their respective pseudonyms and brand names) start joining the same, popular, social-media platforms. Here’s one idea for ethical primary responses to username disputes. Maybe it’ll help social-media services get these things right. [3]

Let’s start by giving both So-and-So and Company X the benefit of the doubt. I’ll assume that none of them knew of the others existence until they clashed at Socialr. Neither one intended to leech off the other’s preexisting reputation or name recognition. They were each independently creative when they chose their pseudonym or company name (though obviously their creative processes ran along similar lines). With that in mind, I’d say the default response for Socialr should be to let So-and-So keep CleverName as their username. Social-media service users should be able to choose a username without the fear that someday it could be unpredictably seized from them through no fault of their own. A person shouldn’t have to perform a preemptive, exhaustive search for any little company out there that might one day want to use the same username on the same service. Once a person has a username, they should be able to start building a digital identity around it without worry. If the preservation of one’s digital identity can’t be guaranteed by a social-media service, why should anyone invest in creating a digital identity there in the first place?

Unfortunately, not every individual or company always acts innocently in these matters. Motives can be hard to determine (though I’d sooner question companies’ selflessness and interest in the common good than individuals’). Also, social-media services are subject to regrettable legal climates and the threats and fears they spread around. A social-media service may feel like its hands are tied and it’s limited to a particular kind of resolution (usually one in favor of the company—the entity with typically greater financial and legal resources than the individual). That’s where a Solomonic response could come in handy, one that would require a modicum of courage on the social-media service’s part. Socialr could tell Company X: “You claim that So-and-So is abusing your trademarks by using username CleverName, a username you also want. It doesn’t look like So-and-So is using CleverName that way, but to be on the safe side we’ll remove username CleverName from our system.  Neither you, nor So-and-So, nor anyone else will get to use CleverName as their username. Now each of you, go find new usernames.” [4]

Such a policy would be far from satisfying, yet its sole existence could help reduce incidences of username disputes. Companies would know that no matter what happens, they can never expropriate a username on a social-media service. At best they could keep a person from using that username, but they’d never get to use it themselves. Given the little gain and the risk of negative publicity from username-elmination requests, companies would likely resort to them only in very clear cases of trademark abuse. In other instances, companies would have to behave more like everyday, individual users. Most of us, when we go choose a username on any service, find that our first choice is already taken, oftentimes even our very own, legal names. We have to come up with different usernames.  It could end up being the same for companies.

Notes

1. The two incidents I read about involve girlgeeks on Twitter and zephoria on Tumblr.  [go back]
2. “Socialr” is a placeholder name for the quintessential social-media service.  A quick, non-exhaustive Google search did not turn up an actual service with that name at the time of this writing. [go back]
3. Not every conceivable kind of dispute is addressed by this proposal. Some kinds of disputes call for very different responses that those covered in this essay. [go back]
4. This proposal doesn’t perfectly parallel the original, Solomonic decision. However, it does attempt to cleverly elicit a fair outcome from a thorny, contentious situation. [go back]

As happened with my inaugural article, strong sentiments drew out an article from me, this very night.  I’ll post it very soon.  Perhaps others will follow it…

As a nascent, independent, software entrepreneur, I’d like to share various ideas pertaining to software development.  My primary audience will be fellow coders.  However, laymen may be interested in my other articles, which will cover topics in software usability, IT, and digital culture in general.

I expect to post an article at least once a month, for starters.

If you’d like to receive an e-mail whenever I post an article, please e-mail me at andres@HashCollisions.com .  You can also subscribe to the RSS feed.

I’ll allow comments on this blog., but will review them prior to publication.  Here’s the RSS feed for the comments.

Before signing off, I’d like to thank several strangers.  They are talented software coder/writers whose respective blogs were a serendipitous find for me.  I’ve picked up other influences since then, but my first Fab Four will always be (in the order I met them) Joel, Eric, Paul, and Jeff.  Let’s see if I can make the most of not only your writing but also your coding advice.  Thank you.

Here we go…

P.S.  I know there’s not much on this blog for now, but how about if we get the comments rolling?  Fellow developers: who are your favorite coder/writers?  Who are your own Fab Four (or Fantastic Five, or Stupendous Six, or Superb Seven, etc.)?