Nova Spivack from Twine wrote an interesting post over at Read/WriteWeb about the future of the desktop which I'd like to comment on.  It really ties in nicely with what I've been thinking about recently around user interfaces, especially since any hardware innovations will necessarily involve an ACTUAL operating system.

I agree 100% with Nova when he says that everything is moving to the cloud.  SmugMug lets me store my high-res photos in my own Amazon S3 store, Jungle Disk lets me back up everything else to the cloud.  Storage is, for me, a monthly utility expense (and last month it only cost me $3.18, so for me this is much cheaper than hard drive space, backup, backup tapes, tracking everything, and worrying).

As I was going through my instant messenger archives this morning looking for a fax number, I realized that what I wanted more than anything else in the world at that particular moment was a Gmail-style searchable archive of my instant messenger conversations.  A full-text indexed search on the client would be a step in the right direction, but not as useful to me as an archive online like Gmail offers.  I realized that what I really wanted is an instant messaging client that uploads my conversations to a central server for indexing and searching from a Web interface.  Preferably, where I could search email and instant messages all in once place.  After all, a message is a message, an instant message is nothing more than a short email with less overhead.

But that got me thinking about privacy concerns and hosted data.  I realized that I use Google mail services exclusively, and they have quite a bit of  my personal data.  Although I don't think Google would give up the data without a court order (I hope!), it still makes me slightly uneasy that one entity has that much of my personal information.  This probably wouldn't even have bothered me five years ago (and would probably be a very nice feature for corporations to assist with regulatory compliance), but with the boundaries of legal privacy continually eroding lately I am starting to believe that there will eventually be no privacy except for that which you yourself physically and/or legally own, exclusively.  This "war on tearism" and those darn "tearists" may be killing a lot of progress in the cross-fire here.

The more I think about it, this is really one more HUGE reason for an eventual shift to personal servers, if they're not made illegal first (that was sarcasm, with a hint of nervousness there...).  If I legally own the computer or hard drive or database on which my personal data is stored, and particularly if I'm able to control the encryption of that data, I would feel much better about the safety and privacy of my data.

After I wrote my idea about protecting your biometric data, Larry Hollowood the CSO of Pay By Touch, the company that I used as an example, left this comment:

"Jewel-Osco does not keep a record of the fingerprint. As a matter of fact, no merchant that uses the Pay By Touch payment system has access to any biometric information. All biometric data is securely encrypted at the point of sale..."

Thanks for the comment Larry, it was helpful and insightful.  And while I hate to pick on your business idea further, let me elaborate on why I still think this is a bad idea, and explain the only way of doing biometric authentication that would be acceptable to me.

The question I posed back to Larry, and which I haven't gotten a response to yet, is whether that encryption at the point of sale is reversible or not.  If it's not a one-way hash that can't be turned back into my fingerprint by someone at the other end, I don't really care if it's encrypted or not because there's always a possibility that it could be compromised.  Since my fingerprint can't be reset, that's an unacceptable risk to me.

Even if it were using a one-way hash, the fact is that the biometric authentication device is a black box to me:  I have no idea what's going on behind the scenes.  If they were to change their policy and store fingerprints unencrypted at the point of sale, they could make the change without anyone knowing about it.  Even if they made an effort to publicize the change, I doubt I would notice in the sea of phone calls, emails, IM's, and junk mail that gets blasted at me every day.

There's only one scenario that I've been able to envision where biometric authentication would be completely secure to make a point of sale purchase.  It involves the use of the personal servers which I've been talking about lately.  Here's how I see it working:

1. After the checkout is complete, I tell the merchant my personal server address "My address is jasonkolb.com"
2. The merchant sends a request for payment to jasonkolb.com.
3. I receive a notification of the request for payment on my personal server which has integrated biometric authentication built-in.  "Jewel-Osco in Plainfield, IL has submitted a request to charge you $38.75.  Would you like to authorize the transaction?".
4. I can then choose to accept or reject the request.  If I choose to authorize it, I verify my identity with my own personal server using biometrics.  "Verify your fingerprint to authorize the transaction."
5. After verifying my identity and authorizing the transaction, I can choose which account to use to send the money.
6. After sending the money, the merchant system would receive a notification that the payment has been posted.  This would be forwarded to the point of sale where the receipt would print, the cashier would give it to me, and I'd go on my merry way.

As you can see, this doesn't involve me giving my biometric data to anyone.  It's only used on my personal server, which only uses it to ensure that I didn't drop the server somewhere and somebody else is trying to go on a shopping spree with my money.  All of the actual transacting takes place in the cloud, there's no need to exchange anything with the merchant besides the receipt.

Part of the 60 Ideas in 60 Days series.  Click here for the rest of the ideas.

This is the fifth post in my series about what I believe to be the future of the Internet.  After a nice laid-back labor day weekend off the comments and emails have piled up, thanks to everyone who took the time to read the posts and leave their feedback on the ideas, I highly value them all.  In fact there were so many good comments and so much insightful feedback that I think I'm going to save it for a follow-up post.  Since I already had this one mostly written, and it specifically addresses a few of the questions anyway, I'm just going to go ahead and post this and come back to the comments in a day or two.

Everything I’ve posted so far in this series has been leading up to this idea: everyone will eventually have their own personal server hosted at their own personal domain, and those servers will be able to talk to each other and collaborate with each other.

Everyone will have their own server and domain. That’s a pretty wild-sounding statement today, when only applications, companies, universities, governments, and uber-geeks run their own servers and domains.  My belief is that the Internet is becoming so pervasive in our lives and society that there’s no stopping this, we’re already headed down this road.  Just as the concept of “email” bubbled up from ARPANET to be part of the general population’s everyday lives and daily vocabulary, the same thing will happen to the concept of “server” and "domain" (although they might be called something entirely different at the end, who knows).  It’s just a slight change of mindset.  And in fact I don’t think it has to be a painful jump at all for users, or even a big jump from the current "MySpace page" mindset.  Once it’s in place I think it’s going to be much easier for the average person to start doing things online and become more productive on the Internet.  There will be a definitive starting point and a standard way to do things.

The second and third posts in this series talked about how this inter-person network should be built, and in the fourth post I talked about the private server architecture. That’s a lot of reorganization, but as I said in the first post, most of the parts are lying around the garage waiting to be put together, and I’m certain it will happen.

So aside from all the benefits and perks all this will bring, which I talked about in the previous posts, there’s one that I skimmed over in the last post, which is that all authentication is done by the user’s private server now, including authentication for applications. This is a pretty key idea, and one of the primary reasons I set out to figure out how to build this new network in the first place. Let me touch briefly on why first, and then I’ll talk about the how.

The Why

Currently, Web-based authentication is almost universally done by registering a new account with the site, which usually involves creating a username and a password.  There are whole bunch of reasons for why we’d want to redo the way this currently works:

• Strong, secure passwords are necessarily complex.  The majority of people cannot remember many of them, if any.
• Most public Web applications do not enforce secure passwords. Therefore, most public Web application user accounts are vulnerable.
• Even if strong passwords are enforced, there is no guarantee that the passwords are not stored in unencrypted form in the application provider’s database. That makes two potential points of failure.
• Even if the passwords are strong and encrypted, you have no knowledge of the physical and perimeter security at the application provider’s point of presence. That makes three potential points of failure, and I'm sure I could keep going.
• If each application has at least three potential points of failure, and those points of failure exist at each application we use online, that makes a lot of potential points of failure.
• The fact that users cannot remember complex passwords means that if they manage to remember a strong password, they generally use it everywhere.
• If our online identity is our online presence, and our online presence consists of those bits and pieces of us scattered about the Internet, with many combined points of failure between them, I would say our online identities at this point are very fragile and capable of being easily compromised.
• If the Internet is going to become any more integral to our day-to-day lives, and I think that train has already left the station, this situation has to be fixed.

My own personal experience tends to bear this out. In fact I started getting suspicious when I was looking at those Web 2.0 online desktops because none of the providers could tell me that my information was secure and what they were doing to protect it.  And I’m supposed to give these guys my email password? If someone gets into my Gmail account, they'd have the keys to the kingdom right there. No thanks, I’ll pass.

The How

The solution, as I talked about in the last post, is to make everyone’s private server the epicenter of their online identity. ONE place to store ONE password. Or fingerprint, or iris scan, or however you want to identify yourself to your server.  (I know I for one am not giving any biometric data out to ANYone else, it's pretty hard to reset that if it's compromised.  I fight tooth and nail against even giving out my social security number these days.)

But if you just authenticate yourself to your own private server, then it's not a problem--the data's not going anywhere, you own it, and you control it.

The trick is authenticating yourself to other servers. How do you use another server and authenticate yourself to it without sharing any kind of identifying information about yourself?  It’s actually pretty easy when the server can actually go locate you on the Internet, which is what personal domain names enable.

Authenticating the user is actually pretty straightforward once you've made that leap:

1. You launch your private server Web interface in a browser.
2. You authenticate yourself to your server. Use a password. Use your fingerprint if you don’t like remembering passwords. Use voice recognition, an iris scan, whatever you like. It doesn’t matter because you don’t need a physical interface to the application server any longer. As long as you can identify yourself to your own server, you’re cool.
3. From your private server user interface, launch the application you want to use.
4. Behind the scenes, launching the application from the user interface spawns an exchange bewteen the user's private server and the application server before anything else happens.  The private server sends a message, which is a request for an application session, to the application server.  This is sort of like asking the application to toss you the key to get in.
5. The application server then, independently of the first request, opens a secure XMPP session directly with the requesting user's private server.  When you have a secure, direct line to the user himself it's pretty easy to spawn an application.  In fact all the application server has to do is create a session, assign it a random temporary password, and send that back to the user's private server.  The private server can then open a digest-authenticated browser session to the application server, transparently to the user.

It’s like asking the user’s private server, “Did you make a request to start this application? If so, here’s a key to use to get in, and there's the door.”  It's similar to the LID approach but a bit simpler for the user in my view.

Only authentication is handled by the user's private server, authorization is still handled by the application. The user’s private server is only responsible for telling the application definitively who the user is, but it doesn't have any say in what the user is allowed to do within the application itself--that's still up to the application just like it is today. The application is still responsible for maintaining internal access control lists, etc. It just doesn’t have to worry about identifying people any longer since it knows who they are when they walk in the door.

The alternative to this are identity metadata schemes like CardSpace.  These assume, however, that you will still have pieces of your online identity scattered amongst various providers, which is precisely what I want to get away from.  Consider this statement from the CardSpace information page:

"Different kinds of digital identities will always be necessary—no single identity will suffice...  No single organization can unilaterally impose a solution."

Basically what I'm saying in this series of posts is that I completely disagree with this statement.  The individual himself should be the single source of online identity.  There IS a single organization that can unilaterally impose a solution, and that's the individual.  Power to the people ;)

It’s not rocket science to authenticate someone when you know where to find them. That's the key, pivotal idea in this whole concept.  It's the difference between trying to find out who somebody is with your back turned to them versus just looking them in the face and recognizing them.

In the physical ("real"?) world, our bodies are both our presence and our communication vehicle.  Online, the Internet is the communication vehicle but most people have no presence.  A private server that can be definitively identified as "you" solves that problem by giving you a presence online, and there's no need to go through complex gymnastics to figure out who you are.

The reason I'm writing (and coding) all of this is pretty simple:  personal necessity.  As I wrote a while back in a post called Defragging my Online Identity, I'm sick of having a fragmented online identity.  I'm sick of having my bits scattered across countless Web sites, countless applications, countless networks.  The sheer number of bits and pieces of myself scattered about the Internet is getting out of hand.  This seems like the next logical progression of Internet technology given what we already have available to work with.

That's it for this post.  Here's a link to part six:  How to make money with Open-Source Social Networking.

Ajaxian has a post about some sessions at the Black Hat USA 2006 conference.  I'm quite honestly surprised that this is just gaining some press now, I've figured it would happen sooner than it has (but that's typical for me :)  I posted on this a while back, and I haven't seen much improvement in this area since.

There are so many ways to break an application it's not even funny.  I wouldn't consider a Web application secure unless it (and the company that provides it) have adequate answers to the type of security scrutiny that Sarbanes-Oxley typically requires.

On top of that, however, AJAX programming techniques do a few other things that make it easy to break applications and/or intercept sensitive data:

• LOTS of Web 2.0 applications use GET instead of POST to transmit data, and that means that any ID's or commands that are in the querystring are available in plaintext to anyone who wants them.  (POST's are vulnerable too, but not quite as easy to intercept).  If there's not a solid authentication mechanism underneath such as Digest authentication, man in the middle attacks become a piece of cake.  Somebody could easily sniff messages and pretend to be you.
• XmlHttpRequest calls (at the core of most AJAX apps) can easily be interecepted unless they're encrypted with SSL, which almost none are.  That means that pretty much anything you input into a Web 2.0 app is fair game for somebody sniffing HTTP on the network.

Part of the reason I've been so quiet on my blog lately is because I've been wrestling with this very problem.  I absolutely love everything AJAX has to offer, however sending naked data back and forth from the server is a pretty huge problem.  I also don't like the idea of securing the entire site with SSL as that's a huge burden on the server.  What I'm currently working on (as part of a much larger probject) is a comet implementation that streams messages over SSL in an unsecured page so that only messages going back and forth from the server are encrypted.  I believe it will work, but it requires a backend server to receive and queue messages which has to be built first (similar to cometd).  I'll post more about it when there's something to show.

With the looming rise of the clipboard to transport XML, disguised as a text and using Microformats, the use of the clipboard to transfer data from one place to another is just going to explode.  And by data, I mean full records including contacts, events, reviews, and eventually I'm sure, orders, invoices, quotes, and products.

The Live Clipboard vision gives users the ability to transfer data without having to rely on software.  It'll be the end of exporting and importing files from one program to another, or copying and pasting fragments of a record from one program to another.

The onus of keeping information secure will be almost entirely on the user, because he'll be able to share whatever information he has access to simply by copying say, an invoice, and pasting it into an email or instant message as microformatted HTML.

Here's how I see the market unfolding:

1. Social software sites will begin (and already have, see AimPages amd Yahoo Tech) adopting Microformats
2. Web commerce sites will begin accepting Microformats.  Amazon and eBay will probably be the first large sites that accept them, followed by PayPal at some point.
3. Microformatted content will be so readily available and easy to use that commercial enterprise software will begin to support it.
4. Since microformatted content is now so prevalent and easy to use that it's everywhere else, CxO's of smaller companies will start folding it into their internal development projects.
5. Once these all happen, users will be able to easily transfer data between the Web sites they use, the software they use, their personal records, and their job.

And something very cool will eventually happen where companies will be able to transfer data between each other using RSS (or ATOM) feeds filled with Microformatted content.  Synchronizing two databases on two different networks will no longer be a chore, but a 30 minute exercise.  Users will be able to email orders to their partners by copying and pasting them into an email (their partners would then hopefully be able to copy the order from the email and paste into their sales system).

Security will become an issue I'm sure, because this really places the onus of filtering what data is shared on the user himself.  A whole slew of new issues will spring up around that, simply because data will be so much more accessible than it ever has been, and software will no longer be a roadblock in the process.  Right now the only way to share data is via email, but the emails will also become much richer and more meaningful.

It will be an interesting time to be involved in Enterprise software, I'm sure.

I'm watching SalesForce's AppExchange platform with interest.  What I'm really curious to know is how many of their large (publicly-traded) customers are using these apps for their sensitive data.  And by "sensitive data", I mean something that they could get dinged for in a Sarbanes-Oxley audit.

I'm mostly keeping an eye on AppExchange for this due to the fact that SalesForce.com is by far the most successful ASP with the biggest percentage of publicly traded customers.  From my knowledge of SOX, just holding sales information isn't much of a risk.  If someone manages to hack into your SalesForce account somehow and get a lead's contact information you're not exposed to much liability.  However, these AppExchange applications branch out into dozens of different areas, and at first blush here's a list of information they contain that could potentially violate a SOX audit if they're not secured properly:

• Customer service data can (and often does) contain customer financial information.  The Patriot Act also requires a certain way of handling transaction data and record retention.
• Customer payment information is definitely covered under SOX
• Human resources data is certainly always sensitive
• Patient health records are covered under both SOX and HIPAA
• Parner marketing is even covered, as it can contain competitive information such as marketing launch plans and product roadmaps.

For that matter, are these services (or SalesForce itself) logging security events in a way that can be monitored by a company's Security Officer?  That's usually a SOX requirement as well, and I haven't been able to find anything that addresses it yet.

Now, this probably isn't an issue for smaller companies that aren't subject to SOX (although it's certainly something they should be thinking about, especially if they ever hope to partner with any publicly traded companies).  However, proper handling of this data, and adherance to best practices and SOX-compliant processes should be of a lot of interest to bigger companies.  If one of these AppExchange products isn't written properly and leaks out sensitive data, it could mean jail time for a CFO.  Is there anything to prevent an AppExchange app from publishing an RSS feed of people's Social Security Numbers?

Just a thought.  But what I'm curious to see is how much data large companies are going to allow to live outside their firewall.  They don't control what happens at SalesForce, and their butts are on the line, not SalesForce's.  I can't say I'd be comfortable with that idea, especially when SalesForce is allowing these third party apps to access its data.  Even if the companies making these apps don't have access to the data, the apps themselves do, and it's pretty darn easy to sign up for them once you're a customer of SalesForce--they practically push them on you.

How far can the ASP model go inside the enterprise?  I have to imagine at some point the CIO has to insist that the data reside in the company's data center so that they can actually control security.  Not to mention that with ASP's smaller than SalesForce there's a lot of due diligence that has to be done to ensure that the company has adequate perimeter security, physical security, etc, in place.  In fact I did an entire post on security requirements a while back (from my days as an IT Director), and there are a lot of them that need to be considered before using an ASP.

I've personally seen and worked with several small companies that violate these principles left and right, but yet partner with publicly traded companies and handle their sensitive data every day.  In my opinion it's just a matter of time before one of these companies is compromised and the credit card transactions for a publicly traded company are obtained, and the whole thing comes crashing down.

You know, writing about SOA vs. Web 2.0 earlier got me thinking.  I think the real missing piece that needs to be addressed is a way to consume SOAP Web services, cross-domain, from the browser.  That'll make it possible to use SOAP services in a pure AJAX environment for things like mashups.  Right now the only way to consume SOAP services from the browser is to use a "behavior", which only works in Internet Explorer and doesn't work cross-domain (it can only call SOAP services that exist on the same server as the client code).  So in order for applications to use SOAP services on the client, the server must act as an intermediary, and introduces another layer on top of the original service itself.  Right now the only way for the browser to use a Web service on another domain is using JSON, which doesn't support all the security and transaction goodness that SOAP does.  The client needs to be able to use SOAP directly, on other domains, before this will quiet down.

By the way, I really believe this is doable with a little elbow grease; Dave Johnson has already figured out how to send XML cross-domain using dynamic script tags, a technique that I'm pretty excited about.  I think all it's going to take is for somebody to translate Microsoft's web service behavior to pure javascript using a similar technique and we'll be rockin'

Update:

I've been catching some heat for this post, as I kind of figured I would.  A couple points of clarification before you read on:

1. Directly authenticating with your  email server would only be used for sites that you trust and want to integrate into your online "identity".  You wouldn't want to use it to buy a digital camera from a fly by night Internet store, but I would question the wisdom of giving them your credit card info in the first place.  However, I would let Amazon authenticate me like this, provided they agree NOT to store my password (which isn't needed and would be a huge liability for them anyway).
2. If somebody does use this method to authenticate with a questionable party, all he needs to do to re-secure his identity is change his email password.
3. Client side javascript hashing is already available

I've never seen this method presented before in any forum so I wanted to get this out there as an option, however worthless an option it may turn out to be.  Never leave any stone unturned, that's my motto ;)

************************************************************************

In a previous post, I wrote about WHY single sign-on for the Web is needed--badly.  In this post, I'm going to look at an idea I had about how to make it happen with the infrastructure that's already in place today.  Whether it flies or not remains to be seen, please shoot holes in it :)

Microsoft wants us all to install InfoCards on all of the devices we use (including public terminals and kiosks), and OpenID wants us to establish our identity by setting up trusts with different Web sites, and there are a handful of other similar ideas.

However, I think it might actually be simpler than all that. I could (quite possibly) be nuts, but I had an intriguing thought the other day:

1. To authenticate, you need some type of authority.
2. The only real authorities on the Internet at this point are the domain registrars
3. The only user accounts associated with domains are email accounts

This tells me that the only way to achieve universal user authentication on the Internet right now is to use email accounts. The only definitive identification we have on the Internet right now is our email address.  What that doesn't mean, however, is that every application should use the email address as the username (although I do like this better than another, different, user ID) and create a new password for the account.

What I'm getting at is this: I don't see any reason why users shouldn't be authenticated with their email servers. Why can't sign-on work like this?

1. The user goes to the site's URL (www.buystuff.com )
2. Before they can buy something, the user has to enter their email username and password (Jason@jasonkolb.com and test123)
3. www.buystuff.com looks up the email server for jasonkolb.com from the domain registrar (using the domain's MX record).  We now have a server that can authoritatively identify the user.
4. www.buystuff.com sends the email server the email address and password that it was given. If it's able to authenticate, the user can be positively identified as Jason@jasonkolb.com without the need for any further logins and passwords (and without even needing to STORE a password, of any kind!).

The problem I see with this is that you have to provide www.buystuff.com with your email password. This could be dangerous if somebody gave their email password to a site they shouldn't really be trusting.  However, this really isn't much different than what people are doing every day right now with their credit cards, so I don't think it's really that big of a leap.  The sign-on page should be signed with a trusted certificate from a certificate authority anyway, so it's essentially the same level of trust we have today.

The other alternative is to build hashed password support into the email server. I actually prefer this method, because it would allow the user to authenticate using email without having to tell the site what his password actually is.  If browsers could do the hashing that would be one step better since the user wouldn't have to send his real password to the site at all.  Today, the only browser-side caching that exists is using Digest Authentication, which is on the browser side, so the only missing piece to making this solution secure end-to-end is email servers that support digest authentication.  Alternatively, I think it's realistic to set up an authentication authority for each domain. In much the same way that an email server is found by looking up the MX record for a domain, we should be able to look up the authentication authority for a domain. The authentication authority for a domain should return the IP address of a server that supports digest authentication, so that applications could just forward the user's email address and hashed password to it and receive a response indicating whether the user is authenticated or not.  Or, possibly even a token that identifies the user.

One of the big advantages I see to this approach is that for say, publicly traded companies that need to be Sarbanes-Oxley compliant, their email server generally authenticates against an LDAP repository of some sort such as OpenLDAP or Active Directory. This means that their security policy is enforced for that email account, such as password complexity and expiration. All of the heavy lifting for compliance is done by the LDAP server, so there's never a risk of any of the user accounts on that server being out of compliance.

The only roadblock I see to this approach is people's reluctance to share their email account info with another party.  However, people don't seem very shy about giving their email account away right now anyway, just about every Web desktop such as Netvibes or Goowy requires you to enter your email account information to read your mail.  And the passwords are actually STORED on their servers, this approach doesn't require that.  Whatever happens, I hope it happens soon, because once we're able to track our activity against a single ID, the next leap in Web functionality is really going to take off.

FYI I'm planning to build a proof of concept on this very soon, unless somebody wants to volunteer :)

I've been thinking a lot lately about different ways to authenticate
users on the Web without requiring them to maintain another username and
password set for each site.  Before the Internet can really become a
cohesive social network (and especially before we can start integrating it with the enterprise), some kind of authentication authority will need
to be developed--right now everything is way too fragmented.

All the new Web 2.0 apps are great, but most of them only done one thing.  Sell something.  Blog something.  Read something.  Tag something.  Write something.  They're all great, but how many logins can one person reasonably be expected to keep track of?

If you think about the real innovation happening with Web 2.0, most of
it revolves around the ability to connect people and let them
collaborate--easily. This works great when you're dealing with a closed system
where people need to log in and create an account.  You make them pick
a username and password, or use their email address as their username
and then choose a password. However, the account you're making
them create isn't the same account they use to post blog entries, buy
things, or comment about your pictures on Flickr. Because of this, all
the data that the user generates is fragmented and it's pretty near
impossible to aggregate it and look at the person as a person instead of just a collection of logins.  The closest we can get right now to viewing somebody as a "person" is to run a Google search on their name
and see what pops up.

Eventually, this will HAVE to change for the next evolutionary leap of the Internet--technology in general, even--to occur.  It's pretty evident that the "identity repository" can't be controlled by any one company or organization, or Microsoft probably would have been more successful with Passport.  It's going to have to be a decentralized way to find out who somebody is, that THEY have control over, not a corporation that they don't fully trust.  There are a couple of new technologies that seem to be going in this direction, most notably OpenID and Infocards.
OpenID basically tries to authenticate people using their blog account,
which is a good start. However, I don't think a Blog account is the
definitive identity that people want to use to authenticate themselves
around the Web.  Infocards use the WS-Trust Web service extension and
signed client certificates.  Maybe I'm just lazy, but I don't really
want to have to keep track of a certificate on every device that I need
to access the Web on.  I don't even know if my Blackberry knows how to
read a certificate (I would assume so, but the point is that it's not
common knowledge and installing a certificate is one more step that
people don't want to deal with).

In my next post I'll follow up on this with an idea I have that may be a nice simple yet elegant solution to this problem.

MIchael Arrington just wrote that Microsoft's Live Drive online storage service might launch before Google's.  I can't say that I think it matters who launches first, there's room for everyone in online storage.  As long as they provide an API.  What I think will happen is that hosted applications such as Salesforce, Writely (well maybe not Writely since they're owned by Google now, but you get the point) will allow people to choose where they want to store their data.  Take your pick of Amazon S3, GDrive, Live Drive, or Omnidrive.  It'll become part of the signup process for applications.

It makes complete sense for the consumer and the application.  The app doesn't need to worry about storage capacity, it just sends data to the drive.  The experience doesn't change for the user, his data just gets sent to his repository of choice, where he can then integrate it with other applications.  In fact, I wouldn't be surprised if apps let users set up multiple repositories and then let them choose which one they want individual files to be saved to.

What Microsoft and Google will have going for them is a huge user base and slick front ends.  I assume Microsoft will also build Live Drive integration into Vista given the Tech Crunch post.  Consumers probably won't pay for it since Microsoft and Google will be free, but what Amazon S3 will have going for it is the enterprise market.  Probably not for sensitive data, but for general file storage it's a no-brainer.  You pay (not a lot) for 100% uptime secure storage that you "own", and you can easily integrate it into your own applications.

Web-based applications and the technology that enables them are fantastic, but they’re bringing a new set of security considerations and challenges along with. This is destined to become a bigger and bigger issue as Web 2.0 applications gain traction, and particularly as they move into the enterprise.

This list represents an attempt to compile those considerations and the proper way to handle them. This is by no means a comprehensive list, but rather is meant to be a starting point for entrepreneurs or individuals curious about the security of a specific application.

I realize that not all companies will be able to comply with all of the requirements, especially in the back-end section. However, keep in mind that these requirements all need to be addressed to comply with the Sarbanes-Oxley Act (SoX). If a company chooses not to take them into consideration they’re most likely going to be cutting all publicly traded companies (and the companies that do business with them) out of their potential customer base.  On a side note, I hope this checklist will eat a chunk out of the SoX auditing extortion racket.  Back when I had to go through making a company SoX-compliant, I was never able to find anything like this.  Because there's nothing in the Act itself about IT, a small cottage industry has sprung up around telling companies what they need to do to become compliant and then auditing them so that their partners know that they're "SoX Cerified".  Well, if you meet the bullets on this checklist you're most likely going to pass.  I had to figure these out the hard way, that is, by paying consultants boku bucks to tell me what they were ;)

Sensitive User Information

The crux of this list and SoX is protecting "sensitive user information".  Here’s a basic list of what constitutes that vague term (I probably left some out so please leave feedback if you think of something I missed):

• Account number and identifiers
• Customer numbers
• User names
• Credit card or bank information of any kind
• Passwords
• Private messages and blog posts
• Wage information
• Social security and driver’s license numbers
• Birthdates

Front-End Security

The first list applies to the application front end, with special consideration given to AJAX and Web services calls:

• The application should use Digest authentication or SSL when accepting a user’s password for authentication.
• User passwords should be stored as an MD5 hash of the password in the database rather than as plain text.
• No sensitive account stored by the application should ever be rendered to the client. This includes database logins, email logins, third-party site logins, etc.
• User sessions should not be identified using cookies or IP addresses, both of which can be easily compromised.
• No sensitive information should be stored in cookies.
• Strong passwords (more than 8 characters, mixed alphanumeric and special characters, mixed upper- and lower-case) should be enforced if users select their own passwords.
• HTTP POST requests should be used instead of GET requests whenever possible. This isn’t more secure per se, but it raises the bar for potential hackers and makes it more difficult to crack your system.
• GET and POST requests should not be vulnerable to SQL injection attacks.  All forms should check for special characters such as single or double quotes before sending the information to the database.  Preferably, stored procedures should be used for all database access since they are not vulnerable to SQL injection attacks.
• All input validation should be done on the server, even if it was already done on the client.  Doing this will avoid the possibility of using Javascript injection attacks.
• If sensitive user information is sent or received from Web services: The WS-Security SOAP header or SSL should be used.
• If sensitive user information is sent or received using XmlHttpRequest (AJAX calls): The entire page utilizing XmlHttpRequest needs to be secured using SSL (which will secure the XmlHttpRequest calls from that page using SSL as well).  SSL is currently the only 100% secure way of making XmlHttpRequest calls, all other methods are vulnerable to man in the middle attacks.

Back-End Security

This list applies primarily to the internal database and network:

• The database administrator password should not be used for application access.  If possible it should be renamed from the default name (sa, for example), and only known by somebody outside of the IT department.
• If the database contains sensitive customer information, the number of people who know the application database login or have unrestricted access to the database should be strictly limited.  Backups should be encrypted and stored off-site in a secured location.
• Anyone who has access to the production database should be required to change their password at least every 90 days.
• If you must store credit card information, it should be encrypted and preferably wiped out after processing is completed.
• Change your network Administrator account name (so that it's not "Administrator").
• Domain administrator accounts should rarely if ever be given out, and the list of people with that access should be documented and readily available.
• Security violations (such as a user entering the wrong password three times in a row) should be logged to a secure location and reviewed by the company Security Officer on a regular basis.
• The physical servers that hold sensitive customer information need to be secured and protected as well. Typically this is taken care of in a hosted environment, but if you’re hosting your application from your basement then you’d better make sure that you have the basement locked and you make the water heater repair man sign in and out.

Perimeter (Network) Security

Here are some requirements that are just good practices for building secure Web-based applications, particularly when they’re hosted on the Internet:

• The firewall should only allow ports 80 and 443 (HTTP and SSL) except when other applications such as BitTorrent or FTP need to be used.
• The Web servers should be on a separate network, separated from the database and other internal servers by a firewall which only allows the database application port to be used.
• The default database application port should be changed if possible.

Hope this helps everyone out there, please help me flesh this out if I missed something.

I think one of the topics that's really going to be hot in the 2nd half of 2006 is Web 2.0 security. Before these apps can ever live in the enterprise, there are going to be a lot of hard questions asked about how hardened these apps are and if they're really secure.

For example, are they using anything besides SSL to encrypt user passwords and senstive information? Do the AJAX calls back to the server permit people to sniff and decrypt tokens that can be used to glean private customer information? Are the AJAX and HTTP calls subject to SQL injection attacks? Are the passwords stored in the database or are they using salted password derivatives? Are they using WSE for their Web services calls?

Big companies will and do ask these questions. Before the Web 2.0 apps can graduate from use only in mom & pop shops, they'll need to answer them.

The problem is, it's too easy to build cool applications now without a knowledge of proper software architecture. I know. I've been burned by these very questions in the past, and they're not easy to answer if you've never answered them before. The very fact that the ASP-model applications *don't* provide answers to these questions tells me they're not prepared to answer them, and are probably hoping that they don't ever get asked. Ostrich Syndrome - head in the sand.

I think there's a really big opportunity here for somebody to start a company that certifies software companies for best security practices. It should be pretty easy to compile an audit checklist that somebody can use to check their software against. In fact I might very well start one.

If this doesn't happen, once hackers catch on to AJAX techniques this industry is going to shoot itself in the foot (or maybe more relevant, the womb?) It'll never gain traction because CEO, CTO's and CIO's of big companies will be so scared by stories of Web 2.0 applications being compromised that they won't touch them with a 10-foot pole. Remember, these guys could do hard jail time if their customer's information is compromised as a result of Sarbanes-Oxley. Something to keep in mind, all you Basecamps out there.