Being a good programmer is actually all about discipline. Something that is likely much easier for you than the youngsters. No one likes a programmer with tons of bravado and not enough sense. Code needs to use good design patterns and be well tested, not thrown together as a rapid prototype then squirted into production. The best way to program is to continually educate yourself and adopt new best practices. Continually challenge yourself to work on new technology that would be useful if you were to need to change jobs. A lot of older programmers I've known fell into the trap of maintaining one component, working with one technology. They probably felt secure that it would be too difficult to replace them, especially if their code was unintelligible. But this, invariably, did not work out. And then they are left without current and marketable skills. I don't know if the passion for acquiring new skills weakens later as I'm still in my 30s but if you no linger have a built in drive, you must cultivate one to stay relevant. But, some programming skills remain relevant regardless of language or platform.
please, please read "Design Patterns" by the gang of four and "Clean Code" by uncle bob. They should be required reading in every CS curriculum. Sadly they are not. Those books? Recommended to me by an awesome white haired software architect.
In my mind, what they do is actually more important that what Scientists do in a lot of respects. Science has less worth if most of the population rejects its findings because they don't align with their world view.
What the Mythbusters do is help us see where our physical intuitions about the world, that evolution has built for us, are inaccurate in the face of our understanding of the physical sciences. You can read something 1 million times in a text book, and it might not sink in unless your (often incorrect) intuition of physics is challenged by a physical demonstration right in front of you.
The Mythbusters, through their style of presentation and their frequent failings on-air, have built up a mysterious credibility in our minds that let them easily dismantle some of our errors of intuition in a style that sticks with us. I think this is valuable beyond measure, and wish there were more shows like this, and less like GhostHunters, for example.
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.
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!:)
But this attack shows crackers just intercepting an replaying the creds. Discouraging that might involve IP or other checks. Defeating it might involve total encryption.
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.
md5 is a hash algorithm. How would that help? If someone can snoop your md5 hash they can replay it to gain access to the server, and then change your password (provided the server doesn't provide a challenge to perform this action). All md5 does is protect your actual password, which is small protection if your account can be illicitly accessed anyway. None of these services send a password in plaintext (hopefully). That isn't the issue. The issue is that they use replayable tokens and don't use encryption to send them on the wire.
I was calling programmers that enjoyed c++ masochistic and in excess of machismo, not unskilled, and as I've alluded to in other replies, mostly to illicit some kind of interesting defense of their like of this language. Because, honestly, I'm curious. C/C++ eroded my goodwill long ago.
You can wax lyrical about the warm feeling you get when you are careful and your C code works, against the odds, but usually getting C code to behave without error just seems to waste large amounts of time, which, IMO, makes it very hard to like.
but is that a reason to LIKE it, or a reason you NEED it. Even then, I would argue only the most performance critical pieces might need conversion to C. Why start with C?
Perhaps read my statement a bit more carefully. I'm not calling anyone that uses C++ wrong-headed. Now if you use it and enjoy it, thats a different story.
I am being the devil's advocate to a degree here. I'm genuinely interested in the reasons people have to LIKE C++. Not just the reasons why they NEED to use it.
Using C because its "more efficient" is like making tons of micro-optimizations before you even know where your performance problems are. It just wastes time and means you eschew the use of more appropriate tools for the task at hand.
I've never once been so dissatisfied with the performance of a higher-level language (that compiles to native code) that I've had to bust out the C compiler. Even then it would make sense to only code the performance critical section in C and leave the rest to a more productive language.
Starting with C is just asking to spend time making optimizations you may never ever need. YAGNI.
Wait till you need to optimize before you even consider C, is what I say, and if you are forced to use it, you don't have to like it!:)
You can argue that well written C code is easier to understand, but the reality is that certain languages (C, C++, JavaScript, vb6) feel like they are designed to encourage developers to be incredibly sloppy. So in practice when you try to read them you are presented with monolithic code written in alien dialects.
Yes, you can write indecipherable code in any language. But I think a sensible language should at least try to discourage it.
Slashdot Mirror
Being a good programmer is actually all about discipline. Something that is likely much easier for you than the youngsters. No one likes a programmer with tons of bravado and not enough sense. Code needs to use good design patterns and be well tested, not thrown together as a rapid prototype then squirted into production. The best way to program is to continually educate yourself and adopt new best practices. Continually challenge yourself to work on new technology that would be useful if you were to need to change jobs.
A lot of older programmers I've known fell into the trap of maintaining one component, working with one technology. They probably felt secure that it would be too difficult to replace them, especially if their code was unintelligible. But this, invariably, did not work out. And then they are left without current and marketable skills. I don't know if the passion for acquiring new skills weakens later as I'm still in my 30s but if you no linger have a built in drive, you must cultivate one to stay relevant. But, some programming skills remain relevant regardless of language or platform.
please, please read "Design Patterns" by the gang of four and "Clean Code" by uncle bob. They should be required reading in every CS curriculum. Sadly they are not. Those books? Recommended to me by an awesome white haired software architect.
In my mind, what they do is actually more important that what Scientists do in a lot of respects. Science has less worth if most of the population rejects its findings because they don't align with their world view.
What the Mythbusters do is help us see where our physical intuitions about the world, that evolution has built for us, are inaccurate in the face of our understanding of the physical sciences. You can read something 1 million times in a text book, and it might not sink in unless your (often incorrect) intuition of physics is challenged by a physical demonstration right in front of you.
The Mythbusters, through their style of presentation and their frequent failings on-air, have built up a mysterious credibility in our minds that let them easily dismantle some of our errors of intuition in a style that sticks with us. I think this is valuable beyond measure, and wish there were more shows like this, and less like GhostHunters, for example.
I'd go further than calling them laymen. I think the right word is "heroes".
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! :)
But this attack shows crackers just intercepting an replaying the creds. Discouraging that might involve IP or other checks. Defeating it might involve total encryption.
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 ;-)
md5 is a hash algorithm. How would that help? If someone can snoop your md5 hash they can replay it to gain access to the server, and then change your password (provided the server doesn't provide a challenge to perform this action). All md5 does is protect your actual password, which is small protection if your account can be illicitly accessed anyway. None of these services send a password in plaintext (hopefully). That isn't the issue. The issue is that they use replayable tokens and don't use encryption to send them on the wire.
I was calling programmers that enjoyed c++ masochistic and in excess of machismo, not unskilled, and as I've alluded to in other replies, mostly to illicit some kind of interesting defense of their like of this language. Because, honestly, I'm curious. C/C++ eroded my goodwill long ago.
You can wax lyrical about the warm feeling you get when you are careful and your C code works, against the odds, but usually getting C code to behave without error just seems to waste large amounts of time, which, IMO, makes it very hard to like.
but is that a reason to LIKE it, or a reason you NEED it. Even then, I would argue only the most performance critical pieces might need conversion to C. Why start with C?
Perhaps read my statement a bit more carefully. I'm not calling anyone that uses C++ wrong-headed. Now if you use it and enjoy it, thats a different story.
I am being the devil's advocate to a degree here. I'm genuinely interested in the reasons people have to LIKE C++. Not just the reasons why they NEED to use it.
There's that machismo again. Zip your pants back up, I don't have a ruler on me.
Using C because its "more efficient" is like making tons of micro-optimizations before you even know where your performance problems are. It just wastes time and means you eschew the use of more appropriate tools for the task at hand.
:)
I've never once been so dissatisfied with the performance of a higher-level language (that compiles to native code) that I've had to bust out the C compiler. Even then it would make sense to only code the performance critical section in C and leave the rest to a more productive language.
Starting with C is just asking to spend time making optimizations you may never ever need. YAGNI. Wait till you need to optimize before you even consider C, is what I say, and if you are forced to use it, you don't have to like it!
You can argue that well written C code is easier to understand, but the reality is that certain languages (C, C++, JavaScript, vb6) feel like they are designed to encourage developers to be incredibly sloppy. So in practice when you try to read them you are presented with monolithic code written in alien dialects.
Yes, you can write indecipherable code in any language. But I think a sensible language should at least try to discourage it.
I'm not sure, though, that would actually make you like it ;-)
You'd keep doing it if the money was good enough, but like it?