37

another post of limited interest to non-techies. although, it would be good if you could comment on whether or not you understand the concepts that directly effect you as a website user who doesn’t think about security.

i’ve been thinking about this for a while, but never really got around to writing anything about it. today i was reading this article about how the “change your password once a month” policy is bad and figured i’d throw some stuff down. it will most likely be ignored unless it happens to come up in search engines.

the first thing to remember in all of this is that the server is attempting to authenticate that the user is the user who created the account, not that they are a specific person in the real world.

i have 2 suggestions for ways to improve web application security that use existing technology. the first could be fairly easily implemented by browsers and requires no changes on the server side. the second requires server side changes and browser changes, but are fairly simple.

most (all?) browsers already support the ability to store passwords for people. this is a good thing. the 2 current downsides to the implementations are the fact that by default (except for i believe opera) they are not protected by a master password. the other problem is the inclusion, on requirement from the financial industry, to have a way to block passwords from being remembered. this is nonsense. what this has caused me to do is to store my passwords in clear text file on my computer. yeah security! i do know that there’s a firefox extension that allows this to be disabled per site, but i never get around to bothering to find it when i re-install.

my first suggestion involves fixing those 2 problems. easy enough for the browser developers. the master password functionaility already exists (take this opportunity to turn it on in your browser) and the other just requires turning off a stupid anti-feature. the main addition is implementing a password generator within the browser. there’s a program on linux/unix (surely other platforms) named apg (automated password generator) that does this for pronounceable passwords. it uses a n.i.s.t. algorithm described in fips-181. of course, sense you aren’t going to be remembering these passwords, they can just be completely random printable characters. this should then be integrated into the password input field in some way. for example, a small button next to the field with a tooltip of “generate password” (could be done by sites now using javascript and be browser independent. better to have it available on any site though) or maybe a context menu entry. possibly only showing this when a stored password is not available. now, when the user creates a new account at a website, they simply generate a password that is stored and they don’t even have to know it. the password is random so there’s no guessing the password. your only real weak link is if the website uses poor security in storing the password and then gets cracked. the browser master password is less important since it requires physical access to be worth anything. it should still be a good password, but it’s the only one you have to remember.

simple enough, right? it could probably be implemented as a firefox extension if one were so inclined.

an addition to this would be a move to using basic or digest authentication at the http level with https. this would remove the annoyance of using cookies for session authentication. this allows for cookies to be disabled and still use websites. additionally, the user would get a consistent authentication dialog unique from any possible site created dialogs to prevent spoofing. it’s also a real annoyance and usability issue to have to try and vulcan mind meld with the site creator to figure out how to logon and off on some sites. the browsers should also implement (i believe opera does) a way to clear basic and digest authentication information from the browser.

the second thing is a bit more complicated, but only a bit. it’s generally similar to how ssh public key authentication works. the first step is implementing support for self-signed client side certificates on the servers. this requires ssl for all authenticated connections. any server load complaints for this are nonsense. the next step for the server is to implement a way to store the public key for a certificate associated with a user (maybe even more than one). the easiest way to do this would be when the user first creates an account. the new account link would go to an https site that detects the client certificate supplied by the browser. the certificate information could be displayed to the user. the user would then continue with account creation including a userid for the site, etc. the server now knows that userid foo goes with the supplied client certificate. using a certificate signed by a c.a. is irrelevant, though not forbidden. if one feels the need, they could easily use a c.a. signed certificate for every site. however, the goal would be to use a different client certificate at every site. how a user can change their client certificate is left as an exercise to the reader. i always wanted to say that.

there are some browser modifications that could make this an easier process. currently, the browsers have everything required to use client certficates. the main enhancement involves adding a dialog when a server requires a client certificate. currently, this will show a dialog with the already installed client certificates. this should now include an option to generate a new self-signed certificate and associate it with the given website. easy enough. this allows the user to either use the same certificate for every site or generate a separate (preferred) for every site. i would think this could be explained to the user in a couple of paragraphs or less, but never under estimate stupidity.

the key principle to remember is that you’re only authenticating that it’s the person who owns the account. not that they’re a specific real world person. this system would also prevent social engineering (probably the biggest problem with security) since the user has no idea what their password even is so they can’t possibly give it away.

it would also be helpful if browser authors would make it easy to migrate authentication information between machines so that i can easily have my auth info on both a desktop and laptop. i don’t know if firefox is better now, but previously it was a pain in the ass close to impossible.

feel free to post complaints in the comments. my hide is thick and very durable. i will, of course, then be forced to point out why you are wrong. the first complaint would probably be, “but what about when i’m using a computer at an internet cafe”. the answer is simply don’t. if you are, you aren’t concerned about security. they are completely insecure. a key logger could easily be installed. if it’s really a problem, write down your password and put the piece of paper in your wallet. if your wallet is stolen, the least of your worries is losing your password(s).

i’ve been able to read a bit more about django. overall, my impression is definitely positive, but not perfect.

production installation is a bit confusing. definitely not as simple as ‘java -jar ‘. the recommended production setup is using apache with mod_python (embeds the python interpreter within apache). that’s probably not too bad once you get it setup. apache is used for serving any static media files like images, css and javascript. that means you have to copy your code in one place and your media in another. how to configure the urls in your app also isn’t straight forward. there is a python based webserver for development, but for whatever reason is not deemed worthy of production usage. i don’t know what, if any, roadblocks there may be to producting a production python webserver. i haven’t seen anything about using it with i.i.s. on windows, but why would you want to do something stupid like that? at some point do people want to stop beating their head against a wall?
as far as database table upgrades, they mention doing the alter table commands by hand. supposedly, a future version (maybe the 1.0) will support a way to automatically generate the alter statements to run. not really any different from what we (and by ‘we’ i mean other people than me) do now i suppose.

while the authentication and authorization seems ok (very similar in functionality and tables as are current framework), it’s not extensible. you have to do some hackery if you want to authenticate to somewhere else like ldap, kerberos or some other crap home-made authentication web service (you know who you are).

there’s not really a plugin/service style framework either. i think similar funcionality can be done by implementing different ‘apps’ that you can install within different sites/projects.

can the existing framework we’re using at doozer really still be that good after 5+ years? i’m not just saying that because i wrote large parts of it;^) the major downside of it, for me at least, is its dependency on the proprietary java.

so what are the other key differences? i think django could be easier to write something quickly, definitely good for prototyping. i like how the model objects are the single definition of the business objects and automatically handles all the sql for you. it’s hard to say if the droid/record style interface is better. it is possible to directly write sql in django and to reverse engineer an existing database to get an object interface. it has a templates for html generation instead of our widget/component style api. this could be a plus or minus depending on how you want to look at it. there’s nothing tying it to using templates though. a similar widget api could be written.

the documentation is still not quite fully there (not that our documentation even exists). a book is supposedly in the works. i think i may plow on with django and try it for the app i want to write. there’s not really another way to truly test something. i suppose i will want to try getting the tutorial app working behind apache as a next step. the key piece of documentation that i think is missing is a good explanation of how to write apps that are portable between projects. they have a start, but it’s still a work in progress.

i installed the dapper beta today. it’s been a bit of an ordeal. i had already done a bunch of partition resizing and moving yesterday. wisely, i decided to just make a separate installation to another partition and keep my existing breezy badger install. ubuntu is definitely the best desktop linux distribution at this point. they really have no one to fear at this point because fedora seems to be on the wrong track.

the good stuff for dapper so far is that it has firefox 1.5 which seems to run faster. the new version of ekiga (formerly gnomemeeting) which is supposed to support sip. that means it should be interoperable with ichat and other sip phones. i haven’t set it up yet. i think i’ll need to get a usb headset or something because i don’t have a mic. it also ships with mysql 5.0 which supports stored procs.

you can install from a livecd that lets you test everything out first. worked ok except for the manual partitioning. the livecd also comes with a set of apps (firefox, abiword, gimp, etc) that you can install and run on windows. if you must.