Passwords, passwords, passwords. They're all around us, and they're a pain to remember. How do we cope? There are hundreds, possibly thousands of places where I use passwords. I have trouble remembering one password, those numbers would be ludicrous to even try. How do you cope? You make up a strategy, or you get tooled up.
Traditionally we say there’s three main ways of asserting an identity. Something you are, something you know and something you have. Identification consists of proving one or more of these to a given level of confidence. A low level of security could include simply asking someone who they are. If you want a higher degree of certainty you could ask for more than one element of identification.
The most common way of doing this is by asking for two of the three elements above, who you are and something you know (username and password). When you want higher degrees of security you can add the third element (something you have, like a key) or you can go deeper into each of the elements. Going deeper into who you are is the direction of biometrics. Delving into something you know would include asking questions you’d know but none others would, and not asking the same question every time. Gaining security on the “have” element would include making very sure the item really does belong to the person who’s trying to identify himself and making equally sure that thing really is that thing. One-time pads and secure transfers are key here.
This all seems nice, and it is. You know what else it is? It’s a hassle. So far most services contend themselves with a two-pronged check (username/password), so you need to give that to get access. This is fine for one or two services, but we’re all consumers of hundreds or thousands of services. To add to this you really should keep different passwords for each service, to ensure your security. If you use the same password for every service and one of your providers are hacked (or *gasp* are bad-guys and sell or use your password) all your information is compromised. So we make up passwords.
To protect ourselves from brute-force hacks we make up complicated passwords with at least 8 characters and combinations of upper-case (A-Z), lower-case (a-z) and numbers (0-9). The really paranoid among us throw in a couple of non-obvious ones too (β, æ, °, etc). And you have to remember all of this. It’s all a bit hairy.
We need some way to solve this problem. Luckily there are solutions. What you need is a strategy to keep track of your passwords. There are three obvious strategies (well, more, but this isn’t a book, it’s just a post).
1. Make up a (hopefully strong) password and stick with it for every service.
This is a bad idea in general, but it’ll do if you don’t care about the information you put into the services. This means your information is wide-open to any hacker after they’ve somehow gotten hold of your password.
2. Make up a few (hopefully strong) passwords and use different ones for different services.
This is what most people do. You have one password for your work-things, one for throwaway-accounts you don’t care about, one for your personal stuff, etc. Although this is a step up from number 1 it’s still not what I’d call security. Two things to think of here are:
a. Are you sure your other passwords aren’t stored somewhere you can get to from one of the identities? If you store a list of passwords on one account any hacker who’s gotten into that has access to all your other information.
b. Are you sure you won’t try all possibilities if you can’t gain access on one service? If a hacker has control over some service you use and changes the password he could probably get a few good passwords out of you when you try all the possibilities. I know I would try every option before giving up.
3. Make up some personal rule for your passwords. This is a good way of coping with the problem as long as you keep this rule secret. Say your rule is “The first three letters are from the beginning of my pet’s name, after that every even character spells out my post-code backwards, every odd character spells out the name of the service. Every other letter is upper-case.” This would make my youtube –account’s password “eRo1E6b1U5tUoY”. Kind of cool, and quite hard to break as long as you don’t tell anyone what your rule is.
So we have some inkling on how we could do this, but it’s still a hassle (well, number one isn’t really). So we’d like some tools to help us. Number one doesn’t really need a tool, perhaps a paper-note if you’re a goldfish. Number two could also be covered by a piece of paper, but with tools we can improve on this. This is where personal password-keepers live. You make up a set of passwords and keep them somewhere safe (like in a database). Safe as in – won’t disappear, and hopefully safe as in won’t get to others. However if your password-database is compromised you’ll effectively have shot your guard in the rear. You’re wide open. And, let’s be fair here, you won’t use all those random passwords anyway. It’ll be too much of a pain and you’ll go back to your old scheme of one or a few passwords.
The third option though is still fascinating. If it’s an easy rule you can use quickly you won’t need a tool. However, with a tool you can make a really complex rule that nobody would ever guess! The world would be your oyster! A one-way-function would be ideal for just this purpose! Hashing-functions are popular for this purpose.
Hashing for dummies:
For our purposes hashing-functions are a black box you put some number into, and some other number comes out. Every time you put the same number in the result is the same, and crucially, there’s no easy way to go the other way! If someone had your result (the hash) and the hashing-function (the black box) they still have no easier way of finding the number you put into the black-box than trying every possible number. (This is all slightly false, but it’ll do for now).
So, what you do is get yourself a hash-function and enter the name of the service into that function. This way the hasher can make you a service-password that’s unique for that service, has no apparent connection to you and will be generated every time you put the name of the service into the function. Oh, you say, but everybody else using the same hashing-function would get the same password! And, you’re right, I’m proud of you. You’ve obviously been paying attention. What you do is you “salt” the hash. Salting the hash means you don’t just enter the name of the service but also enter something else. This “something else” would be your master-password.
Let’s assume you’re able to remember one password and what you called the service – this will always give you the password for the service. As long as nobody else has the same password and name for the service they’d not have the same service-password. Even if they did any hacker with control of the service wouldn’t know what the password-name-combination was, he’d only see the service-password.
This is great, the problem is solved. Well, the problem was already solved with strategy 3 back up there, but people are too lazy to think of strategies. Now, how can lazy people get to use this marvelous technology? We have to give people hash-functions! Luckily these are available. Popular ones are MD4, MD5 and SHA-1 (I know, they’re broken but they’ll do for our purposes). You can try them out at http://pajhome.org.uk/crypt/md5/
If you use Firefox (and I think you should) you can install a bookmarklet called SuperGenPass This makes the entire operation automated, and it fills in the generated password based on the name of the server you’re trying to connect to and your master-password. It’s so easy you’d never think it was safe, but it really is!
This has been a short essay about how the client can get some security from hacked or malicious services. As a developer I see the problem from the other side as well. I’ll delve into that next…
Sunday, March 11, 2007
Been Sick
I've been out sick for a while, sorry. That's why there's been no new posts for a few days. Just thought I'd tell all my millions of readers.
The good news is that I'm well again, and I've got a few posts coming out soon.
For now, take a look at the interesting things I've put on the sidebar. Not my content, but all of that is stuff I found interesting and worth a little time.
The good news is that I'm well again, and I've got a few posts coming out soon.
For now, take a look at the interesting things I've put on the sidebar. Not my content, but all of that is stuff I found interesting and worth a little time.
Monday, March 5, 2007
Tell Me When Something Happens
Events are a staple of object-oriented design. They are a way decoupling objects and that is almost always a good thing. A short synopsis of the idea:
You have some object (Foo) and you want to be able to know when something happens to Foo. Say Foo is a button and you want to know when it's been pressed in order to do something. You could just code Foo to do the thing you wanted, but then you'd have to code every button for everything you want to do. You could tell Foo to execute some method (possibly in some other Object) when it was pressed, but then you'd lock Foo and the method together. You'd have problems if someone later changed that method also, as they may not know that Foo calls it. The solution to this is to let Foo have events, and code the actual behavior in some other Object or method which handles that event.
In Java this is done through a pattern called the event-listener. I call it that, anyway. What you do is you let Foo implement a method that takes the listener (addListener(FooListener l)).
FooListener is an interface that includes one method to handle the event when the listener gets it. You can put whatever you want into the FooEvent, depending on what kind of event your particular implementation raises. Often you only need to send an event, that's enough information in itself.
In Foo you decide when you want to send an event to the listeners, and you do it something like this:
This works, but it's a bit verbose, and worse - it's up to the developers to decide how to do this and if they will.
In .Net classes have events themselves. The engineers over at MS have taken this pattern and hardcoded it into their platform. So, what you do here is slightly different:
Events and listeners are what I know from Java, but in VB.NET they're called Events and Handlers. I can live with that, it parses. What's really cool though is that like properties (which I really like) the events are language-features. So, you've got some kind of standard to follow, it's not something you have to explore on your own or make up on the spot.
When you add a button in VB.NET your app already knows about the events that can generate (they are part of the specification of the Button class). This makes it easy for the code-generator to give you the boilerplate for a handler. In fact, that's what it does when you double-click a button in the form-designer. Coding has never been so easy, and I like that.
The problem with this easy code-generation (for me, and this may be a problem with me) is that it doesn't teach you how to do this yourself. My case was that I wanted to add a handler to a control that only exists after a certain set of actions have been taken in my program.
When I add a handler to a button which exists the code is easy. Let's say I have a button called btnFoo on my form. To handle a click from this I just type in (VB.Net):
It gets a little more hairy when you're handling dynamically created Objects, though. This took me some time to find, and it led me to a foray into delegates. I'll get back to them some other time though.
What you have to do is create a method with the same signature as the event. Say I'm looking to handle a LostFocus event on a Control. That has the signature: Public Event LostFocus(ByVal sender As Object, ByVal e As System.EventArgs). So what I need is a method that matches that signature. Behold!
This is not the whole story though. You may have noticed that the handleButtonFoo method had the keyword handles after it with a reference to the event it wanted. My little lost-focus method has no such thing, as no object exists yet that I want to handle. When one exists though, I can pipe the events to my method with the following code:
This will delegate the LostFocus events to my method. Yay!
As you may have noticed this is a better way to handle this than in Java. You get a set pattern on how to do it, defined at the language level (AddHandler is a reserved word). It's also less verbose than the Java-way, as that one included code in two classes and one interface. It may do the same, but I like it better.
Now I've got to get home, I have a sick child. Till next time!
You have some object (Foo) and you want to be able to know when something happens to Foo. Say Foo is a button and you want to know when it's been pressed in order to do something. You could just code Foo to do the thing you wanted, but then you'd have to code every button for everything you want to do. You could tell Foo to execute some method (possibly in some other Object) when it was pressed, but then you'd lock Foo and the method together. You'd have problems if someone later changed that method also, as they may not know that Foo calls it. The solution to this is to let Foo have events, and code the actual behavior in some other Object or method which handles that event.
In Java this is done through a pattern called the event-listener. I call it that, anyway. What you do is you let Foo implement a method that takes the listener (addListener(FooListener l)).
public class Foo {
private List(FooListener) listeners = new LinkedList(FooListener);
public void addListener(FooListener l) {
listeners.add(l);
}
}
FooListener is an interface that includes one method to handle the event when the listener gets it. You can put whatever you want into the FooEvent, depending on what kind of event your particular implementation raises. Often you only need to send an event, that's enough information in itself.
public interface FooListener {
public void handleEvent(FooEvent e);
}
In Foo you decide when you want to send an event to the listeners, and you do it something like this:
private void doSomething() {
for(FooListener l : listeners) {
l.handleEvent(new FooEvent("Something"));
}
}
This works, but it's a bit verbose, and worse - it's up to the developers to decide how to do this and if they will.
In .Net classes have events themselves. The engineers over at MS have taken this pattern and hardcoded it into their platform. So, what you do here is slightly different:
Events and listeners are what I know from Java, but in VB.NET they're called Events and Handlers. I can live with that, it parses. What's really cool though is that like properties (which I really like) the events are language-features. So, you've got some kind of standard to follow, it's not something you have to explore on your own or make up on the spot.
When you add a button in VB.NET your app already knows about the events that can generate (they are part of the specification of the Button class). This makes it easy for the code-generator to give you the boilerplate for a handler. In fact, that's what it does when you double-click a button in the form-designer. Coding has never been so easy, and I like that.
The problem with this easy code-generation (for me, and this may be a problem with me) is that it doesn't teach you how to do this yourself. My case was that I wanted to add a handler to a control that only exists after a certain set of actions have been taken in my program.
When I add a handler to a button which exists the code is easy. Let's say I have a button called btnFoo on my form. To handle a click from this I just type in (VB.Net):
Public Sub handleButtonFoo(ByVal sender as System.Object, ByVal e as System.EventArgs) Handles btnFoo.Click
Console.Out.WriteLine("Click")
End Sub
It gets a little more hairy when you're handling dynamically created Objects, though. This took me some time to find, and it led me to a foray into delegates. I'll get back to them some other time though.
What you have to do is create a method with the same signature as the event. Say I'm looking to handle a LostFocus event on a Control. That has the signature: Public Event LostFocus(ByVal sender As Object, ByVal e As System.EventArgs). So what I need is a method that matches that signature. Behold!
Private Sub HandleSomethingLostFocus(ByVal sender As System.Object, ByVal a As EventArgs)
Console.Out.WriteLine("Give me back my focus!")
End Sub
This is not the whole story though. You may have noticed that the handleButtonFoo method had the keyword handles after it with a reference to the event it wanted. My little lost-focus method has no such thing, as no object exists yet that I want to handle. When one exists though, I can pipe the events to my method with the following code:
Private Sub createWidget()
'Make something that can lose focus
Dim widget As New TextBox
'Add the widget to the main form (which we're in)
Me.Controls.Add(widget)
'pipe the LostFocus events to the handler we wrote
AddHandler widget.LostFocus, AddressOf Me.HandleSomethingLostFocus
End Sub
This will delegate the LostFocus events to my method. Yay!
As you may have noticed this is a better way to handle this than in Java. You get a set pattern on how to do it, defined at the language level (AddHandler is a reserved word). It's also less verbose than the Java-way, as that one included code in two classes and one interface. It may do the same, but I like it better.
Now I've got to get home, I have a sick child. Till next time!
Thursday, March 1, 2007
I'm Thinking of Something Round
I was having this little problem with the app I'm developing. It's the same program that I've been talking about the last two posts, the unnamed application I'm calling Pluto. The problem I'm addressing this time is not domain-specific however, but rather a result of my lack of experience with the platform and language I'm using.
I was looking to present parameters in a GUI for the user to manipulate. I'd solved the tasks of getting the parameters from the web service and presenting them in controls based on their type. Getting the parameters into the user's face is only half the work, though. I also had to get the user's input back into Pluto's guts somehow. Now, this gave me a few sorts of problems.
The first problem is that I know the user is interacting with a control, and I know which kind of control it is. Thus, one might think I could easily map the control-type to the parameter-type. It works, for dates, strings and booleans. It's not so easy for integers and floats though, as they're both most easily displayed with what .net calls a NumericUpDown (lovely little things). As you may know you can set the number of decimals such a control allows.
I briefly toyed with the idea of setting integer-type controls to have 0 decimals and floats to have some other number and parsing based on that. All this was starting to smell of a hack. I was taking some arbitrary subset of the data contained in a datatype (the original ReportParameter), using it to construct some other object (the Control) and then trying to make a new object of the original type with that small subset of data and some implicit knowledge (what kind of control each parameter type mapped to). Badness.
How do I get out of this bad situation I've gotten myself into? It's obvious that I want to keep the original object, and just get the changes (if any) from the control into it. That would be much better, safer, cheaper (well, not in memory but we're talking about on the order of 0-10 objects here) and much, much less buggy. Just imagine trying to maintain such a mapping if you've really no idea what I did and why...
How do I keep the original objects? One solution would be a global list of the original objects with the same numbering as the controls I added (or some other arbitrary scheme to keep the control-parameter mapping). This is not an ideal solution - it's not very object-oriented, the mapping is non-obvious and globals tend to be a bad idea for these kinds of problems. So, I kept thinking.
When I keep thinking I can come up with some really convoluted and complex solutions to problems like this. My though was this: If I make an object that includes both the original parameter and the control I can just ask it to return the parameter. The immediate problem with this is that I would loose the elegance of adding controls directly to the GUI. Could I somehow solve this by making the object an extension of the Control? If I were a .net -guru I could possibly do this in some way and easily make such an object. I am not, however, I am brand new at this platform and totally new at VB.NET. So, I looked around, read a bit, tried to understand how this plot could be hatched, but I really got nowhere.
This got me thinking about patterns, though. I like patterns, so I tried to identify what I was trying to do. Was my problem solved by a proxy? Well, no, I didn't really need an object to stand-in for another. I had access to the control, I wanted to add functionality. Could it be a composite? Not really that either, as composites are good at unifying the way you use some number (usually a substantial number) of components. It had to be a decorator, the pattern that lets you add some functionality to some existing object (by "painting" that functionality onto it). It may seem obvious now, but it's never that easy when you're thinking through it. At least it isn't for me, caveat emptor.
I had it licked. I just had to implement the pattern that "painted" the original object onto the controller. Why was I not happy? This was a tiny, but important part of Pluto, and going straight on to implementation of a decorator-pattern with interfaces and implementations et cetera wasn't what I wanted to do. I still had a hope, maybe just a wish, that I wouldn't have to go through that for this simple need.
I'd skimmed the definition of the Control to see if there was anything I could use in there at the beginning of this problem, but nothing particularly stood out. I was probably just putting off starting on the pattern, but I found myself reading through it again. I was scanning for any kind of Object-reference the Control could keep - maybe I could just put it in there? I found a few, but they all sounded like they changed the behaviour of the control in some significant manner (AccesibilityObject? No, I don't like the sound of that). Then I found it: the control has a property called a Tag, and it's an Object.
You know that combination of elation and shame you get when you see that a problem you've spent good time on has already been solved? Not only has it been solved, but it's right there in front of you ready to be used. Let me quote the description of the Tag from the API: Gets or sets the object that contains data about the control. Could it be better?
So, slightly shamed but mostly happy about the way the problem had been solved elegantly and without any implementation whatsoever I simply tagged the controls with the parameters. This means that I can get the original object directly when I parse the input from the user, get the content that's been changed and send the whole shebang back to the server.
Right now I really love that.
My professor once told me: "A few hours in a library can frequently save you months of research."
I was looking to present parameters in a GUI for the user to manipulate. I'd solved the tasks of getting the parameters from the web service and presenting them in controls based on their type. Getting the parameters into the user's face is only half the work, though. I also had to get the user's input back into Pluto's guts somehow. Now, this gave me a few sorts of problems.
The first problem is that I know the user is interacting with a control, and I know which kind of control it is. Thus, one might think I could easily map the control-type to the parameter-type. It works, for dates, strings and booleans. It's not so easy for integers and floats though, as they're both most easily displayed with what .net calls a NumericUpDown (lovely little things). As you may know you can set the number of decimals such a control allows.
I briefly toyed with the idea of setting integer-type controls to have 0 decimals and floats to have some other number and parsing based on that. All this was starting to smell of a hack. I was taking some arbitrary subset of the data contained in a datatype (the original ReportParameter), using it to construct some other object (the Control) and then trying to make a new object of the original type with that small subset of data and some implicit knowledge (what kind of control each parameter type mapped to). Badness.
How do I get out of this bad situation I've gotten myself into? It's obvious that I want to keep the original object, and just get the changes (if any) from the control into it. That would be much better, safer, cheaper (well, not in memory but we're talking about on the order of 0-10 objects here) and much, much less buggy. Just imagine trying to maintain such a mapping if you've really no idea what I did and why...
How do I keep the original objects? One solution would be a global list of the original objects with the same numbering as the controls I added (or some other arbitrary scheme to keep the control-parameter mapping). This is not an ideal solution - it's not very object-oriented, the mapping is non-obvious and globals tend to be a bad idea for these kinds of problems. So, I kept thinking.
When I keep thinking I can come up with some really convoluted and complex solutions to problems like this. My though was this: If I make an object that includes both the original parameter and the control I can just ask it to return the parameter. The immediate problem with this is that I would loose the elegance of adding controls directly to the GUI. Could I somehow solve this by making the object an extension of the Control? If I were a .net -guru I could possibly do this in some way and easily make such an object. I am not, however, I am brand new at this platform and totally new at VB.NET. So, I looked around, read a bit, tried to understand how this plot could be hatched, but I really got nowhere.
This got me thinking about patterns, though. I like patterns, so I tried to identify what I was trying to do. Was my problem solved by a proxy? Well, no, I didn't really need an object to stand-in for another. I had access to the control, I wanted to add functionality. Could it be a composite? Not really that either, as composites are good at unifying the way you use some number (usually a substantial number) of components. It had to be a decorator, the pattern that lets you add some functionality to some existing object (by "painting" that functionality onto it). It may seem obvious now, but it's never that easy when you're thinking through it. At least it isn't for me, caveat emptor.
I had it licked. I just had to implement the pattern that "painted" the original object onto the controller. Why was I not happy? This was a tiny, but important part of Pluto, and going straight on to implementation of a decorator-pattern with interfaces and implementations et cetera wasn't what I wanted to do. I still had a hope, maybe just a wish, that I wouldn't have to go through that for this simple need.
I'd skimmed the definition of the Control to see if there was anything I could use in there at the beginning of this problem, but nothing particularly stood out. I was probably just putting off starting on the pattern, but I found myself reading through it again. I was scanning for any kind of Object-reference the Control could keep - maybe I could just put it in there? I found a few, but they all sounded like they changed the behaviour of the control in some significant manner (AccesibilityObject? No, I don't like the sound of that). Then I found it: the control has a property called a Tag, and it's an Object.
You know that combination of elation and shame you get when you see that a problem you've spent good time on has already been solved? Not only has it been solved, but it's right there in front of you ready to be used. Let me quote the description of the Tag from the API: Gets or sets the object that contains data about the control. Could it be better?
So, slightly shamed but mostly happy about the way the problem had been solved elegantly and without any implementation whatsoever I simply tagged the controls with the parameters. This means that I can get the original object directly when I parse the input from the user, get the content that's been changed and send the whole shebang back to the server.
Right now I really love that.
My professor once told me: "A few hours in a library can frequently save you months of research."
Subscribe to:
Posts (Atom)
