another thing that would work is adequately finely grained permissions. Can you deny an app network access in Android? That would seem sufficient to keep it in its box, presumably.

Have you read the code?
And I'm not familiar with this one in particular, but if its released on the Android marketplace, for example, what's to stop someone from having used a different version of the source to compile the distributed app than the open source code that was published? Is there a good way to compare a hash of such an apps binaries to a known good compile of the source?

Just because an app is open, doesn't make it safe. Of course, I'm just overly paranoid perhaps. But sometimes it feels nicer for there to be an entity behind a product that I can bring a lawsuit against if their software is doing illicit things without my permission.

but the question is, is how much do you even trust the KeePass developer? The application deals with your passwords in plaintext, and can talk to the network if it wants to. I find it hard to trust any 3rd party with my passwords in plaintext. Its hard enough to trust Microsoft and Google.

I haven't used Android. But WP7 is certainly better than the iPhone. It provides a single cohesive experience while everything on the iPhone is insular and poorly integrated. Its anecdotal, but, everyone I've shown the phone too has been seriously impressed, and might be converts. Even die hard android fans seem to love this thing when they play with it in person. I would suggest you check one out at a kiosk rather than relying only on jaded reviewers.

The problem with the kiosk demos, though, is that probably all the social features of the phone are disabled, which is one of the main selling points of the OS.

One thing I personally like a lot about the software is that it seems like there is always immediate feedback when you perform an action. Sometimes with android and iOS you can be left wondering if the click you performed was actually received. But everything seems to animate in some way as soon as you click it in WP7.

That, and working with Silverlight is a dream from a hobby development standpoint. You can put a semi complicated app together in an afternoon. This could turn out to be a bit of a detriment in the end though, as I'm sure a lot of junk will accumulate in the marketplace.

I would have to second that WPF is fantastic. It uses a lot of new paradigms so it can be tough to get into if all you've used is qt or winforms, but its totally worth it. Its also very easy to separate View logic from Presentation logic in WPF, so much so that new UI patterns are emerging all the time to take advantage of WPFs unique features and further decouple your view logic.

Also, vector graphics and animation were part of the core design of WPF (rather than tacked on later). So the whole thing works very naturally for creating very compelling UI with not a lot of work invested. Also, when you are learning WPF you are also learning Silverlight in the process, as Silverlight is merely a subset of WPF.

To those wondering why Mono doesn't seem too concerned about WPF, it may be because they intend to use MoonLight (Silverlight port) for a 2D UI framework on the Linux platform. This is just theory as I haven't kept up to date with their roadmap there. Also, you could probably add Silverlight to your list of 2D frameworks there. You can create out of browser apps with it, and its the 2D framework that Windows Phone 7 uses.

I'd like to point out the fact that they called the product "Kinect for Xbox 360" means its highly likely they are planning on releasing a "Kinect for Windows" at some point. Along with support for the kinect being used as a multitouch input driver for Windows (7/8). But its nice we are getting a head start.

If you are at all worried about changing your password, then a password is not enough. Changing doesn't help, as soon as your password is compromised it needs to be changed. Multiple factors is a much better solution than changing passwords, which only provides a false sense of security at best.

Don't know for sure, but I think the text editor in VS2010 might be using WPF, which has a much newer text rendering subsystem than GDI+. As to the specifics, someone else may need to chime in.

uh... I'm referring to a post further down :)

As I noted in my post, your suggestion still leaves you open to interception attacks. Which are, admittedly harder to perform than replay attacks, but are nonetheless problematic. My statement that all tokens sent in the clear were replayable was a bit inaccurate though, yes, as I contradicted with suggestions later in the same post! :)

Anything that you send in the clear to assert your identity can be replayed. IPs etc are easy to spoof so are not an adequate counter. You can include a timestamp in the hashed information so that the hashed info cannot be reused more than a certain amount of time after it is generated, but you have to allow for transmission delay and the server's clocks being out of sync, so if an attacker is quick enough they can replay your tokens even if you have made them time sensitive.

Using a request counter + timestamp or a one time password in the token would be much more preferable, but is more expensive to assert with each request, and is still suseptible to interception and spoof attacks, if not replay attacks.

There's really very little that is a valid substitution for encrypting all traffic here, IMO. The rampant use of unencrypted transmission of tokens on these sites today rely on the fact that it is harder to stage a man in the middle attack once requests leave your local network. But as tools for use on public wi-fi networks become easier to use and more prevalent this is only going to become a larger and larger problem.

my sarcasm detector needs more coffee, still, my comments may offer more elucidation to the original replier, so I'm not sorry I ducked under your humor.

How exactly would that help? You could md5 hash a password and a timestamp, and this would at least limit the amount of time that a hashed password could be replayed, but it would not prevent the replay of the password. The nature of a hash is that it isn't something that you decode. It obscures something from view, so that a party on the other end, if it knows the same secret, can verify that you know the secret, without divulging the secret publicly.

But if someone can snoop your hash, they can replay it and pretend they know the secret, without actually knowing it.

This is why a hash protects the secret, but doesn't protect the service from replay attacks, you need encryption also.

A hash is a good idea to be used in concert with encryption because then, even if the encryption is broken, the secret is not exposed. But a hash in itself is not a secure way to assert identity.

I don't use other people's wifi for the same reason I wouldn't share a junkie's needle.

furthermore the entire usefulness of md5 is that you can't un-md5 it ;-)