Tom Mollerus' Weblog

Despite repeated explanations, many of my friends and family still aren't exactly sure just what it is that my company Ping Identity does. Somehow the catchphrases of "SAML authentication" and "single sign-on" don't make immediate sense to them. Go figure.

But last week we published a video that I think does the best I've ever seen at putting these difficult concepts in understandable, concise terms. Enjoy.

This morning there was a message in my inbox from TripAdvisor with the subject of "An important message from our CEO". I was expecting that perhaps they were announcing that they had been acquired, but instead the message explain in plain words that some portion of TripAdvisor's email list had been stolen. This message, delivered with honesty and contrition, is an example to all companies about how to share news that your members' data has been stolen: do it, because it's your obligation and because it's what you'd want someone else to do for you. This great missive follows.

To our travel community:

This past weekend we discovered that an unauthorized third party had stolen part of TripAdvisor's member email list. We've confirmed the source of the vulnerability and shut it down. We're taking this incident very seriously and are actively pursuing the matter with law enforcement.

How will this affect you? In many cases, it won't. Only a portion of all member email addresses were taken, and all member passwords remain secure. You may receive some unsolicited emails (spam) as a result of this incident.

The reason we are going directly to you with this news is that we think it's the right thing to do. As a TripAdvisor member, I would want to know. Unfortunately, this sort of data theft is becoming more common across many industries, and we take it extremely seriously. I'd also like to reassure you that TripAdvisor does not collect members' credit card or financial information, and we never sell or rent our member list.

We will continue to take all appropriate measures to keep your personal information secure at TripAdvisor. I sincerely apologize for this incident and appreciate your membership in our travel community.

Steve Kaufer
Co-founder and CEO

If you're concerned about online privacy, and don't like the thought of your ISP capturing the content of your browser traffic, then you should access your favorite websites via https whenever possible. Enter the EFF's HTTPS Everywhere Firefox Extension, which ensures that you are accessing sites like Google search, Wikipedia, and Facebook securely whenever possible.

Get it at https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension

From The Unofficial Apple Weblog:

Apple's iAds system actually uses lots of your information, including your iTunes purchasing history, location data, and any other download or library information it can suss out about you, to determine what ads you see. So say a few marketing firms working with the large companies now buying and selling iAds.

Is there anything wrong with that? Not really. Apple isn't running the only targeted advertising network, of course, and the whole problem with analytics firms like Flurry is that they were tracking and sharing this information anyway through third-party apps. Apple also isn't sharing your personal information; it's just connecting you with advertisers who want to speak with you, not actually telling those advertisers who you are. Apple knows what you've purchased in iTunes, but that information isn't necessarily communicated to Nissan or Best Buy.

But they make a good point that some people may not want to be tracked even if it's just by Apple. Go to https://oo.apple.com/ in your iOS 4 device's browser and register to opt out of iAds tracking.

In my last post, I wrote about whether password fields should be masked or revealed so that users can see the passwords as they type them. One method I mentioned in that post is adding a checkbox to turn password masking on and off depending on the user's preferences.

Since then, I've come across another technique that is worth looking in addition to the first. Let's examine.

Jakob Nielsen just called for password masking to die:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures. It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

He claims that miscreants can still steal your password just by watching the keyboard instead of the screen, and that mistyped passwords will reduce business because of user frustration. I don't agree that either of these are worthy arguments: first, it's a lot harder to watch someone's keystrokes than it is to read off letters accumulating in an on-screen field; and second, I would guess that the amount of lost business due to user frustration over password fields is very neglible. Plus I'm willing to bet you'd lose more users if you didn't obscure your passwords because they would think your site was lacking in good security.

I do agree with one of his suggestions later in the posting, which Jeff Atwood has proposed before: adding a checkbox to the form (or dialog box) so the user can control whether the password field is masked or revealed. This setting could even be applied globally in application preferences, applied by web site, or even applied by network connection. If you're on the home network, don't mask; if you're at work, mask; if you're on an unrecognized network, and therefore probably in public, mask.

Just a tip for those of you who, like me, have svn+ssh access to a Subversion server whose ssh port is not set to the usual value of 22: you can usually specify the port right after the server name, like so:

svn+ssh://svn.someserver.com:12345/path/to/repo

svn+ssh is a protocol that provides more security than using just svn over port 3690 or port 80, since all of your traffic will be encrypted like any other ssh communications.

For extra security, you may want to encrypt important information in your database so that someone who hacks in can't read it easily. For instance, you could be saving credit card information so that you can bill for services, or you could be saving the customer's sensitive business information. Here's the method I use to encrypt and decrypt important information.

I just checked off one of the requirements for one of my projects at work: protect from cross-site request forgeries, or CSRF. It was much easier to accomplish than I expected-- here are the details.

I noticed a survey on FreePress.org last week with very interesting results. They asked what people would choose as the priorities for the next FCC chair. I was curious, so I filled out the survey so as to see what the accumulated results were. I was suprised with what I found. Take the survey yourself and then read on for my reaction.

Why did Google go to the effort to create their own browser, named Chrome? If you read Google's own explanation of why they built a browser, here's the essential part of what you'll read:

"At Google, we spend much of our time working inside a browser. We search, chat, email and collaborate in a browser. And like all of you, in our spare time, we shop, bank, read news and keep in touch with friends - all using a browser. People are spending an increasing amount of time online, and they're doing things never imagined when the web first appeared about 15 years ago.

Since we spend so much time online, we began seriously thinking about what kind of browser could exist if you started from scratch and built on the best elements out there. We realized that the web had evolved from mainly simple text pages to rich, interactive applications and that we needed to completely rethink the browser. What we really needed was not just a browser, but also a modern platform for web pages and applications, and that's what we set out to build."

Certainly that's an admirable goal of helping end users. That's what puts Google in such an enviable position in the Internet space-- any time that the size or the use of the Internet increases, they stand to gain from the inevitable need we all have to get help in navigating the web. Google is the helpful, ubiquitous traffic sign on the information superhighway.

But is their intention with Chrome completely selfless? I don't think so. One part of Chrome's default homepage is labelled "Search your history".

This made me wonder: would Google capture a user's browsing history on their own servers to use for their own purposes? Reading Chrome's privacy policy, a few of the bullets are revealing:

"...Google Chrome features send limited additional information to Google:

• When you type URLs or queries in the address bar, the letters you type are sent to Google so the Suggest feature can automatically recommend terms or URLs you may be looking for. If you choose to share usage statistics with Google and you accept a suggested query or URL, Google Chrome will send that information to Google as well. You can disable this feature as explained here.
• If you navigate to a URL that does not exist, Google Chrome may send the URL to Google so we can help you find the URL you were looking for. You can disable this feature as explained here."

It seems clear to me that Google is collecting the browsing history of anyone who is using Chrome. Whether that's a good thing or a bad thing, I'll leave up to you. Personal browsing histories which used to be isolated to your own computer would now be stored on Google's own servers as well. What happens to that remote data when you want to delete your own history-- does it stay in Google's datacenters? What might someone malicious do with that information if they ever had access to it?

I know that Google has disclosed this information in their privacy statement, but to me it seems to come close to running afoul of their corporate motto, "Don't be evil".

I was tasked with providing a wiki application for the use of the sales team here at Ping Identity. For the sake of a mature solution, we chose to use MediaWiki, which is the open-source PHP application that runs Wikipedia.

MediaWiki is built to support the same editing system that Wikipedia is founded upon: namely, to let anyone create or edit content, and do so via a self-created account or anonymously (with the IP tracked). Now Ping Identity, as a single sign-on and identity management software, is all about easy identity management. Besides the fact that most of our users from sales would balk at having to create yet another user account, I would be breaking faith with the company if I didn't allow automatic provisioning (ie, the automatic creation of new accounts if they've been authorized by our AD server). So, after getting MediaWiki installed, I went off to search the blogosphere for single sign-on solutions to make our Apache web server authenticate against our Active Directory service, then have people automatically recognized and provisioned as necessary by our wiki.

I've just come back from an CommonSpot Advanced Developer's Training class, where some people expressed the thought that server-side validation wasn't required as long as you have sufficient client-side validation through JavaScript. Then this morning I read Mark Kruger's excellent (if rather unfortunate) example of why you should always implement server-side data validation in your applications. Always remember that users, whether friendly or malicious, can submit anything they please via form submissions, URL query strings, or even cookies.

Yesterday an issue came up at the office that I wanted to ask the rest of the community about: we had a person call in, identifying themselves as being from a large law firm, asking for the names of those people from her firm who were signed up for our services. My company offers web-based financial services by subscription, so it's not at all uncommon for us to have customers from financial and legal firms, and to get calls from them asking about their accounts. Sometimes we even have a relationship with one person at a company who doles out bulk-rate subscriptions for our services to their colleagues.

What was notable about this caller, however, was that we didn't have a prior relationship established with this person or company, and we really had no way of verifying that they were who they said they were. My colleague who was taking the call put this person on hold and asked me whether he should grant this person's request; my answer was to have him say that while he could tell the caller how many people from her company were signed up with us, we were not allowed to give her their names. We did offer to contact them on her behalf to ask them to get in touch with her.

These kinds of calls, while not frequent, are somewhat common. For instance, we get secretaries calling on behalf of busy lawyers, or the folks from the finance department who've noticed our company's name as a charge on the company credit card and want to know who placed it. I'm sure this happens to other web-based businesses as well. So my question to the rest of you is this: how do you handle requests for customer account information? Do you take any measures to verify that the caller's stated identity is authentic? If a third party calls and asks for information about other people, how do you handle it?

1. Ensure that all text and all files sent by the user—all—are safe for your system
   1. SQL-safe data: If user-defined text, such as that in URL variables, FORM variables, and even cookies, is used in SQL statements, make absolutely sure that it is either numeric or that it is wrapped in quotes so that it is treated as a string. Otherwise, users can effectively send SQL commands straight to your database.
   2. Uploading executables: If you let users upload files to a directory inside of the webroot, make sure that they can’t upload executables which might run on the server. You can enforce this by either refusing to upload executables, or by changing the web server settings so that it won’t run them. Better yet, keep user uploads outside of the webroot and retrieve them with a "proxy" page.
   3. If for any reason you are allowing the user to submit directory paths or filenames in a URL or FORM, make sure that the information they submit doesn’t give them access to any part of your filesystem outside of the web root. For instance, you need to remove all instances of ‘../’ from such user data. I've seen other sites do this when they want to distribute whitepapers, for instance-- they specify the full path of the whitepaper as a hidden field in the form you're submitting. If you modify the field, you could perhaps download any file you liked from their server.
2. Ensure that all personalized SQL queries depend on variables the user can’t manipulate.
   If you are querying the database to send personalized data back to a user, you might not think that the user can or will take advantage of the query. Yet if you are passing a user-defined variable (e.g. a URL or FORM variable) into the query, the user could very easily change that variable in an attempt to query the database for someone else’s information. Make sure that ID numbers in queries are passed from the application server so that they can’t be manipulated by users—or that the query depends on at least one user-uncontrolled variable.
3. Ensure that application error messages don’t give information about the filesystem or web server configuration
   Many application servers give information about the server software and filesystem when an error is produced. This is meant for debugging during development, and it should not be displayed to users when the site is live.
4. Try to hide administrative backends with unusual URLs, and make sure passwords are very difficult to guess
   Often times web sites are built with administrative backends, where the site managers can control the site’s content or business logic. These backends are a great convenience, but they need to be protected. First of all, make the URL to the backend hard to guess. Second, make absolutely sure that a username and difficult-to-guess password is required to access it. Third, encrypt the access to the backend with SSL.

1. Ensure that databases and sensitive assets are stored outside of the web root
   Any file, including your database, which sits inside the web root can be downloaded by a user if they figure out the correct URL. Keep your database outside of the web root, and keep sensitive files outside as well. Most application servers provide methods for sensitive files outside of the web root to be served to authenticated users when appropriate.
2. Ensure that directory browsing is turned off and that default index pages are specified
   If directory browsing is turned on and the web server doesn’t recognize any of the files in a given directory as a default index page, the server will show a list of all of the files to any user. The server may even let the user navigate between directories.
3. Ensure that all of the latest patches have been applied to all software
   Make sure to constantly check for and apply patches and upgrades for the operating system, web server, database, and application server software. Some programs can do this automatically, such as Windows Update or the Red Hat Network for Linux; if that isn't available, set up a schedule with reminders as a part of your business processes.