Honestly, I'd rather have cash on me. Someone robbing me is acting antisocially and violently, and that makes them inherently unpredictable. What do they want? Not a bit of plastic that I can cancel the minute they walk away. Are they sophisticated enough to want my ID to use for identity theft? Nope. Identity thieves pull that crap all the time without having to carry the risk of getting violent with a stranger in public. They steal it electronically.
So... they might want cash. I'm not sure, but it's a real chance. And if there isn't any cash, how are they gonna react? Are they gonna stab me?
Unless they have X-ray vision, by the time they know whether I'm carrying a bunch of cash or not, we're already way outside my comfort zone - and you know what? I'd rather be able to give them some cash - pull out a good handful of bills and toss them in the wind. Even if they weren't after cash at first, hopefully they'll be more interested in picking up the cash than in chasing me.
Of course, if you're unaware enough to be flashing around all the cash you're carrying for everyone to see - if you just can't stop yourself pulling out your wad of 50s and fanning it around every time you pay for something - then, maybe stop carrying cash around.
Finding good engineers is hard. Growing teams is hard. Growing a company in order to support old software comes with all sorts of extra costs: more admin/HR staff, more office space. It's not just a case of "hey we have an extra hundred million bucks, look, we can support an old version for longer now!"
Companies make a call about balancing supporting old versions with what else they can do - and at some point, older versions are gonna get dumped no matter what.
I've seen so many security disasters caused by "IT professionals" who are just focused on enforcing security policies. My favourite example was a major client who spent months trying to get their IT security division to play ball on a project, but every effort proved fruitless - the firewalls and network security policies were there for a good reason, dammit, and they weren't prepared to compromise on security.
Faced with pressure to get the project completed, the project team ended up plugging in heaps of 3g modems all over the site, to allow network connectivity to the systems they needed external access to. This access went in with no network-level access controls or firewall, and to the best of my knowledge they're still there, years later.
Would I have done that? No. I would have resigned first. But these people had jobs and liked keeping them, and faced with the certainty of a failed project, or the possibility of someone (probably not them) taking a fall over breaching security policy, they went with whatever got the job done. The project manager met his KPI, the team got to move on to other projects, and security got to feel smug because they kept their network security policies intact.
I saw the whole debacle happen (and I've seen plenty of similar situations over the years), and in my opinion it's been a failure of the security team just about every time. Facing a choice between: a) Enabling engineers to solve business requirements while ensuring there are effective and well-managed security controls, or b) Enforcing security as a top priority, with little regard for the requirements of other business divisions, security teams often just go with option b. They pretend the inevitable workarounds aren't their fault.
Every time they say "yes" to something which increases security risk, the security team risks something going wrong - but every time they say "no" they risk people coming up with their own work-around instead. Security teams should be enablers - finding ways to secure what needs to be done. Once they become known as deniers, they'll just end up fighting an adversarial battle with their own colleagues. That doesn't result in effective security.
I once started at a company which was in the middle of a tabs-vs-spaces pissing match. Their staff turn-over was huge - they had the entrenched long-termers (who got involved in things like pissing matches over white-space) who hung around, and it was a revolving door for everyone else: nobody wanted to hang around that environment. I lasted eight months, and should have left much sooner - lesson learned. I promised myself that if I ever walk into a company which is genuinely having these sorts of in-fights again, I'll turn around and leave on the spot. There are too many good opportunities to stay at companies that hire middle-aged teenagers.
The flip-side is that I've been doing team-lead roles for quite a while now, so I guess it's my job to fix that kind of thing. We're not being paid to have fights over rubbish like that - we're being paid to develop high-quality, well-tested, maintainable software. Anyone who wants to waste time and harm morale in drawn-out fights over white-space can get out.
> Am I just going there to network, or am I learning new cutting-edge techniques and getting enlightened by awesome training sessions? Or is it just a fun way to get a free trip to Las Vegas?
Yes. You're going there to network - not just with companies who might hire you away, but with potential future colleagues you might help to recruit. You're going to talk to other attendees about what they're doing, compare notes on what works and what doesn't, and meet subject-matter experts who you can tweet if you get stuck. You're going to get invited to the local tech community Slack, where you can do all of the above (and more) even after the conference is over.
You might well be enlightened by the sessions - you'll probably run into at least a few things you didn't know about before. You're unlikely to learn all the details, but you'll at least find out that the thing exists, and probably enough information to decide whether it's worth investigating further at work (or away from work). Speaking of away from work, it's likely to pique your interest about things which aren't relevant at work (yet), possibly enough that you'll investigate them on your own time.
The free trip to Vegas (/ wherever) shouldn't be ignored. Having a good time, and associating that good time with work having paid for it, shouldn't be under-valued - it's likely to be reflected in your productivity and loyalty.
Many of these things are great for your employer as well as for you. What manager doesn't want a team filled with well-connected, loyal, enthusiastic developers who are interested in the latest developments in tech and may well do some learning on their own time as well?
Could a major research-focused company like Samsung have state-of-the-art innovations which they're keeping secret and hoping even the best research teams in competing companies don't know about, much less college professors, until they can get a product out? Absolutely.
Are they significant enough to actually produce a contact-lens-based display?
Well, patents only last 20 years, and there's no point having a patent for only the last year or two of an invention going main-stream - you want it for as long as possible. The more premature the patent, the less time you'll have to exploit it when products finally come to market.
So either this is a pure marketing stunt (possible) or, as seems much more likely, the current state-of-the-art at high-tech research institutes is making them worried that they need to get this patent in now, before someone else does, because this is happening in the next 10 years or so.
And I'd also like them to replace the Windows DOS prompt with bash running inside a proper terminal window. Installed by default.
I can't give you installed-by-default, but download MobaXterm. It's about a trillion times quicker than installing Cygwin on every Windows machine you use, especially because you can just put it in Dropbox or similar and have it follow you around.
The bulk of programming jobs have nothing at all to do with math beyond the high school level. Its mostly counting beans and keeping records. Really, it is.
You're right. So, if you want a bulk job counting beans and keeping records, don't learn math. If you want a cool career with lots of interesting stuff, get good at math.
In my field, good math skills mean the difference between running a million iterations at the cost of many hours of computing time, or doing some stochastic calculus and producing a (better) result in seconds. In a past job, it meant the difference between designing a naive algorithm to spot simple patterns in usage data, or doing some fancy math and coming up with actually useful metrics. In another job, it meant the difference between not understanding what the accountant client was trying to explain and having numerous testing iterations before coming up with something that (hopefully) met requirements, and actually following the math and ensuring my algorithms matched the scenarios we were modelling.
In my experience, good math skills have been the difference between being a relatively unproductive base-wage coder and being an innovator with a reputation for really great work - and it also means that someone else gets stuck with shuffling data while I get to work on interesting problems and learn lots about different subject domains. I've gotten to work on anti-money-laundering systems and on weather and pollution modelling - gotten company time to do my own research, and been sent to training programs and conferences (often at swanky hotels!)
We don't really deal with smaller enterprise, so I'm not sure how well my experience will relate. We tend to find that our clients treat "our software won't work with your PC" types of problems as OUR problem, not theirs, and something we should address, not them. I'm yet to see a client bring it up - we have to be pretty pro-active, and we've been caught in situations once or twice where we've had to scramble to support older browsers at very short notice, because they were running very old versions and gave us the choice between making it work on their systems or them considering us in breach.
The specific situation that seems to cause it is that site managers are responsible for budget for purchasing IT infrastructure, but central IT manages the infrastructure. You get a few site officers refusing to retire PCs that are well past their expected lifetimes, and central IT says "sure you can keep using it, but forget updates: the latest OS we've tested on that hardware is XP without SPs, and the latest browser we've tested on XP without SPs is IE6, so that's what you stay with." I think central IT are trying to force the site managers to spend budget on IT gear, but IT is often not involved in our proposals (they just manage the infrastructure,) so all that happens is whichever higher-up decided to go with our solution tells us, basically, "I don't care if there's a fight between a site officer and our IT dep't over budget, or if MS have deprecated that technology, or whatever other excuses you have - we've bought your solution for our EXISTING infrastructure, and you need to make it work on that."
We've found entirely the reverse re: enterprise users, albeit with a different plugin. Enterprise users are the ones who force OUR hands. They generally tell us what browser versions and plugins are available in their SOE, and we have to support that or lose the sale. Our clients are exclusively larger enterprises, and our success rate at saying "you just need to install [x] on the machines you're going to use this from" has been zero so far. As a rule of thumb, if it doesn't run on IE7 with Flash installed and nothing else, you're gonna miss some enterprise clients. We've just spent 18 months fighting to get our last client to accept us dropping IE6 support: even though they didn't have any deployed IE6 machines left, they wanted it in the contracts anyway.
Agree completely with you about end users. Most people don't see "you can just install this plugin, restart your browser, and this will work". They see "this doesn't work".
I know I'm just jumping on the band-wagon here, but I'm a.Net developer who's worked for a couple of shops over the last few years and has seen plenty of new web products started. I've been on at least three projects where we wrote off Silverlight as an option, citing reasons like unwillingness to use the plugin, lack of available developers, and general opinions that the platform was on a fast-track to being canned.
Then again, most products I've worked on with a focus on having a great user experience tend to undergo pretty massive UI overhauls every 18 months to three years, and it's pretty common to use different technologies at each iteration. Being forced into changing UI platforms shouldn't come as any sort of surprise to you.
In the programming world, I always got the impression that, collectively, we respected the self-taught coder more than one who spent four years in school being spoon fed how to code.
You've created a false dichotomy. Spending four years doing a degree, for most of the people I hung out with, was nothing about being spoon-fed how to code - most of the people who needed that failed out and went elsewhere. Some of them struggled through. Lots of us were good coders long before we went to uni, and we breezed through and spent most of our time messing about with stuff that interested us: we often got worse grades than the ones struggling through, because they were focusing on meeting the criteria while we were off messing with something fun.
Most of the (good) coders I've ever worked with have been a mix of the two. They taught themselves to code, then went to uni and learned all sorts of new and interesting stuff about coding, as often from their fellow students as from the courses. I've met good coders without training, but I often (not always!) find that a lack of 'four years in school being spoon fed how to code' leads to all sorts of bad habits, poor practices, and general amateurishness. NOT, by any stretch, always! There are great coders who are entirely self-taught - but I'm gun-shy of them, because I've seen some of the bird-nests these people put together.
Agree, but I have an insight into the 'appearance' of anti-intellectualism. We have no respect for the traditional signs of an intellectual: research papers, degrees, citations, accreditations are meaningless: we just care about how GOOD you are. No degree can tell us that: all it tells us is that you satisfied some panel or series of lecturers who were interested, not in your ability, but in whether you satisfied some set of criteria that probably aren't really all that relevant.
It can easily LOOK like anti-intellectualism, but it's just that we'd prefer to judge for ourselves, thank you very much, and not defer to the opinions of a bunch of people we don't know.
I spent a big part of my life as a Catholic. Fairly early on, I realised that there needed to be "the real me" and "the me I pretended to be to the church".
Wow. Just wow. I NEVER learn anything from/. comment threads, especially about security (I would argue that nobody does, because most of what's said is wrong), and I think I just did!
It's worth noting that this benefit relies on your application server not being compromised, as if an attacker owns that, they can change code to move the client-based hash step to the server (changing the client AND server code), and still see passwords. So you're really only protecting against network-sniffing attacks, which are USUALLY prevented by SSL anyway. This actually gives me an idea, but I'll have to think about it. Something along the lines of using an MD5 of the sign-in page itself as a part of the process, so changing the page will break things. That's obviously vulnerable to exactly the same attack, but perhaps there's an extension to this which might work.
You have also prevented plain-text reveal in the situation where someone somehow intercepts the post-SSL stream but can't alter the application, which is certainly a possible scenario.
There's a major benefit, with this scheme, if you're using a dedicated ssl server and relying on a secure network behind that (which is not uncommon in higher-load applications) - compromise of the ssl server doesn't lead to compromise of plain-text passwords. The attacker would need to take the next step and own the application servers behind that, and given that this scenario only crops up in high-volume load-balanced systems, there are likely lots of identical systems to deal with, and (hopefully) switched-on administrators and security experts, so adding another step like that could vastly decrease the chance of a complete compromise. The attacker would already own login details to the attacked site (they could replay hashes from the owned SSL appliance), so there's every chance they'll take that and never even try to compromise the application code itself, thus never leading to the plain-text reveal.
You've basically described how it usually works, except that instead of having the client perform a hash, we have the client encrypt the communication over SSL. The advantage, that the password can't end up accidentally in a log file, means now that instead of the password, the hash that the client sends would end up in the log file. I'm worried that you're adding to the complexity of your code in order to prevent an avoidable bug - it seems like you'd be better to just ensure that sensitive information isn't showing up in your logs (which is a crucial step in avoiding security holes; it's specifically addressed in, for example, the PCI security standard).
There should be one salt per user, not one per application. This means that the whole effort to generate a rainbow table is only applicable to the one user you're trying to recover the password for; the rainbow table for the next user will be totally different, because there's a new salt. This means that all of your work to hack one account can't be re-used for the next. Salting isn't about preventing this sort of attack; it's about multiplying the effort to compromise n accounts by n. If it takes the attacker 5 days to compute a nice big look-up table, they now have to repeat that per account, instead of having now compromised every account.
It doesn't even require a replay attack. We're talking about what happens if the database of stored hashes is compromised, and if the client does the hashing instead of the server, you don't even need the password. You can just submit the hash from your stolen database to sign in as the user.
Uh, what? The browser hashes the password? Now you don't even NEED the password; you have the hash, and that's all the client needs to submit to gain access! You just pretend that you hashed the password and transmit the hash. No password needed! Unless, of course, you submit the password AND the hash, but that doesn't gain anything over just submitting the password (except perhaps proving that the client has a working hash function).
Remember, we're talking about what happens when the database of stored hashes is compromised, and having the browser do the hashing makes this scenario MUCH worse.
A correctly-implemented salted-password scheme uses a different salt per user - it doesn't even matter if it's trivial to predict. The point is that it multiplies the computational load to compromise n users by n. You can't generate a single look-up table any more.
Further, the salt is combined with the key, not the user's password. If it was just combined with the password before the encryption, when you used your look-up table to find out the (password+salt) used to generate a particular hash, you would then de-combine the known salt and have the password! Simple.
Finally, because the salt is combined with the encryption key, using one salt for your whole system would be no different to just using a different key.
With the correct scheme, adding a per-user salt means (even if the salt is trivial to discover) you are using a DIFFERENT key to compute the hash for each user. Now you may still be able to generate a large look-up table of hashes to compromise an individual hash, but it will only work for ONE user account (barring salt collisions), and so a 24-hour run (your number) will be required PER USER ACCOUNT. This means that a few dozen, or even a few hundred, accounts may be compromised, but this will be a much smaller fraction than if you weren't using salts (or were using them incorrectly, as is so common).
Slashdot Mirror
Honestly, I'd rather have cash on me. Someone robbing me is acting antisocially and violently, and that makes them inherently unpredictable. What do they want? Not a bit of plastic that I can cancel the minute they walk away. Are they sophisticated enough to want my ID to use for identity theft? Nope. Identity thieves pull that crap all the time without having to carry the risk of getting violent with a stranger in public. They steal it electronically.
So ... they might want cash. I'm not sure, but it's a real chance. And if there isn't any cash, how are they gonna react? Are they gonna stab me?
Unless they have X-ray vision, by the time they know whether I'm carrying a bunch of cash or not, we're already way outside my comfort zone - and you know what? I'd rather be able to give them some cash - pull out a good handful of bills and toss them in the wind. Even if they weren't after cash at first, hopefully they'll be more interested in picking up the cash than in chasing me.
Of course, if you're unaware enough to be flashing around all the cash you're carrying for everyone to see - if you just can't stop yourself pulling out your wad of 50s and fanning it around every time you pay for something - then, maybe stop carrying cash around.
Finding good engineers is hard. Growing teams is hard. Growing a company in order to support old software comes with all sorts of extra costs: more admin/HR staff, more office space. It's not just a case of "hey we have an extra hundred million bucks, look, we can support an old version for longer now!"
Companies make a call about balancing supporting old versions with what else they can do - and at some point, older versions are gonna get dumped no matter what.
I've seen so many security disasters caused by "IT professionals" who are just focused on enforcing security policies. My favourite example was a major client who spent months trying to get their IT security division to play ball on a project, but every effort proved fruitless - the firewalls and network security policies were there for a good reason, dammit, and they weren't prepared to compromise on security.
Faced with pressure to get the project completed, the project team ended up plugging in heaps of 3g modems all over the site, to allow network connectivity to the systems they needed external access to. This access went in with no network-level access controls or firewall, and to the best of my knowledge they're still there, years later.
Would I have done that? No. I would have resigned first. But these people had jobs and liked keeping them, and faced with the certainty of a failed project, or the possibility of someone (probably not them) taking a fall over breaching security policy, they went with whatever got the job done. The project manager met his KPI, the team got to move on to other projects, and security got to feel smug because they kept their network security policies intact.
I saw the whole debacle happen (and I've seen plenty of similar situations over the years), and in my opinion it's been a failure of the security team just about every time. Facing a choice between:
a) Enabling engineers to solve business requirements while ensuring there are effective and well-managed security controls, or
b) Enforcing security as a top priority, with little regard for the requirements of other business divisions,
security teams often just go with option b. They pretend the inevitable workarounds aren't their fault.
Every time they say "yes" to something which increases security risk, the security team risks something going wrong - but every time they say "no" they risk people coming up with their own work-around instead. Security teams should be enablers - finding ways to secure what needs to be done. Once they become known as deniers, they'll just end up fighting an adversarial battle with their own colleagues. That doesn't result in effective security.
If you have Absolutely Critical code that's sitting on a developer's machine with no other copies or backups, you kinda deserve to lose it.
I once started at a company which was in the middle of a tabs-vs-spaces pissing match. Their staff turn-over was huge - they had the entrenched long-termers (who got involved in things like pissing matches over white-space) who hung around, and it was a revolving door for everyone else: nobody wanted to hang around that environment. I lasted eight months, and should have left much sooner - lesson learned. I promised myself that if I ever walk into a company which is genuinely having these sorts of in-fights again, I'll turn around and leave on the spot. There are too many good opportunities to stay at companies that hire middle-aged teenagers.
The flip-side is that I've been doing team-lead roles for quite a while now, so I guess it's my job to fix that kind of thing. We're not being paid to have fights over rubbish like that - we're being paid to develop high-quality, well-tested, maintainable software. Anyone who wants to waste time and harm morale in drawn-out fights over white-space can get out.
> Am I just going there to network, or am I learning new cutting-edge techniques and getting enlightened by awesome training sessions? Or is it just a fun way to get a free trip to Las Vegas?
Yes. You're going there to network - not just with companies who might hire you away, but with potential future colleagues you might help to recruit. You're going to talk to other attendees about what they're doing, compare notes on what works and what doesn't, and meet subject-matter experts who you can tweet if you get stuck. You're going to get invited to the local tech community Slack, where you can do all of the above (and more) even after the conference is over.
You might well be enlightened by the sessions - you'll probably run into at least a few things you didn't know about before. You're unlikely to learn all the details, but you'll at least find out that the thing exists, and probably enough information to decide whether it's worth investigating further at work (or away from work). Speaking of away from work, it's likely to pique your interest about things which aren't relevant at work (yet), possibly enough that you'll investigate them on your own time.
The free trip to Vegas (/ wherever) shouldn't be ignored. Having a good time, and associating that good time with work having paid for it, shouldn't be under-valued - it's likely to be reflected in your productivity and loyalty.
Many of these things are great for your employer as well as for you. What manager doesn't want a team filled with well-connected, loyal, enthusiastic developers who are interested in the latest developments in tech and may well do some learning on their own time as well?
Could a major research-focused company like Samsung have state-of-the-art innovations which they're keeping secret and hoping even the best research teams in competing companies don't know about, much less college professors, until they can get a product out? Absolutely.
Are they significant enough to actually produce a contact-lens-based display?
Well, patents only last 20 years, and there's no point having a patent for only the last year or two of an invention going main-stream - you want it for as long as possible. The more premature the patent, the less time you'll have to exploit it when products finally come to market.
So either this is a pure marketing stunt (possible) or, as seems much more likely, the current state-of-the-art at high-tech research institutes is making them worried that they need to get this patent in now, before someone else does, because this is happening in the next 10 years or so.
And I'd also like them to replace the Windows DOS prompt with bash running inside a proper terminal window. Installed by default.
I can't give you installed-by-default, but download MobaXterm. It's about a trillion times quicker than installing Cygwin on every Windows machine you use, especially because you can just put it in Dropbox or similar and have it follow you around.
I wasn't aware that smart people weren't allowed to engage in non-productive recreation. When was this rule brought in?
Oh, to actually address the parent:
The bulk of programming jobs have nothing at all to do with math beyond the high school level.
Its mostly counting beans and keeping records. Really, it is.
You're right. So, if you want a bulk job counting beans and keeping records, don't learn math. If you want a cool career with lots of interesting stuff, get good at math.
In my field, good math skills mean the difference between running a million iterations at the cost of many hours of computing time, or doing some stochastic calculus and producing a (better) result in seconds. In a past job, it meant the difference between designing a naive algorithm to spot simple patterns in usage data, or doing some fancy math and coming up with actually useful metrics. In another job, it meant the difference between not understanding what the accountant client was trying to explain and having numerous testing iterations before coming up with something that (hopefully) met requirements, and actually following the math and ensuring my algorithms matched the scenarios we were modelling.
In my experience, good math skills have been the difference between being a relatively unproductive base-wage coder and being an innovator with a reputation for really great work - and it also means that someone else gets stuck with shuffling data while I get to work on interesting problems and learn lots about different subject domains. I've gotten to work on anti-money-laundering systems and on weather and pollution modelling - gotten company time to do my own research, and been sent to training programs and conferences (often at swanky hotels!)
In summary, learn math.
We don't really deal with smaller enterprise, so I'm not sure how well my experience will relate. We tend to find that our clients treat "our software won't work with your PC" types of problems as OUR problem, not theirs, and something we should address, not them. I'm yet to see a client bring it up - we have to be pretty pro-active, and we've been caught in situations once or twice where we've had to scramble to support older browsers at very short notice, because they were running very old versions and gave us the choice between making it work on their systems or them considering us in breach.
The specific situation that seems to cause it is that site managers are responsible for budget for purchasing IT infrastructure, but central IT manages the infrastructure. You get a few site officers refusing to retire PCs that are well past their expected lifetimes, and central IT says "sure you can keep using it, but forget updates: the latest OS we've tested on that hardware is XP without SPs, and the latest browser we've tested on XP without SPs is IE6, so that's what you stay with." I think central IT are trying to force the site managers to spend budget on IT gear, but IT is often not involved in our proposals (they just manage the infrastructure,) so all that happens is whichever higher-up decided to go with our solution tells us, basically, "I don't care if there's a fight between a site officer and our IT dep't over budget, or if MS have deprecated that technology, or whatever other excuses you have - we've bought your solution for our EXISTING infrastructure, and you need to make it work on that."
Anyone who gets that UI overhauls/rewrites happen frequently, but DOESN'T use a layered architecture to keep the UI layer really thin, is an idiot.
We've found entirely the reverse re: enterprise users, albeit with a different plugin. Enterprise users are the ones who force OUR hands. They generally tell us what browser versions and plugins are available in their SOE, and we have to support that or lose the sale. Our clients are exclusively larger enterprises, and our success rate at saying "you just need to install [x] on the machines you're going to use this from" has been zero so far. As a rule of thumb, if it doesn't run on IE7 with Flash installed and nothing else, you're gonna miss some enterprise clients. We've just spent 18 months fighting to get our last client to accept us dropping IE6 support: even though they didn't have any deployed IE6 machines left, they wanted it in the contracts anyway.
Agree completely with you about end users. Most people don't see "you can just install this plugin, restart your browser, and this will work". They see "this doesn't work".
I know I'm just jumping on the band-wagon here, but I'm a .Net developer who's worked for a couple of shops over the last few years and has seen plenty of new web products started. I've been on at least three projects where we wrote off Silverlight as an option, citing reasons like unwillingness to use the plugin, lack of available developers, and general opinions that the platform was on a fast-track to being canned.
Then again, most products I've worked on with a focus on having a great user experience tend to undergo pretty massive UI overhauls every 18 months to three years, and it's pretty common to use different technologies at each iteration. Being forced into changing UI platforms shouldn't come as any sort of surprise to you.
In the programming world, I always got the impression that, collectively, we respected the self-taught coder more than one who spent four years in school being spoon fed how to code.
You've created a false dichotomy. Spending four years doing a degree, for most of the people I hung out with, was nothing about being spoon-fed how to code - most of the people who needed that failed out and went elsewhere. Some of them struggled through. Lots of us were good coders long before we went to uni, and we breezed through and spent most of our time messing about with stuff that interested us: we often got worse grades than the ones struggling through, because they were focusing on meeting the criteria while we were off messing with something fun.
Most of the (good) coders I've ever worked with have been a mix of the two. They taught themselves to code, then went to uni and learned all sorts of new and interesting stuff about coding, as often from their fellow students as from the courses. I've met good coders without training, but I often (not always!) find that a lack of 'four years in school being spoon fed how to code' leads to all sorts of bad habits, poor practices, and general amateurishness. NOT, by any stretch, always! There are great coders who are entirely self-taught - but I'm gun-shy of them, because I've seen some of the bird-nests these people put together.
Agree, but I have an insight into the 'appearance' of anti-intellectualism. We have no respect for the traditional signs of an intellectual: research papers, degrees, citations, accreditations are meaningless: we just care about how GOOD you are. No degree can tell us that: all it tells us is that you satisfied some panel or series of lecturers who were interested, not in your ability, but in whether you satisfied some set of criteria that probably aren't really all that relevant.
It can easily LOOK like anti-intellectualism, but it's just that we'd prefer to judge for ourselves, thank you very much, and not defer to the opinions of a bunch of people we don't know.
I spent a big part of my life as a Catholic. Fairly early on, I realised that there needed to be "the real me" and "the me I pretended to be to the church".
Wow. Just wow. I NEVER learn anything from /. comment threads, especially about security (I would argue that nobody does, because most of what's said is wrong), and I think I just did!
It's worth noting that this benefit relies on your application server not being compromised, as if an attacker owns that, they can change code to move the client-based hash step to the server (changing the client AND server code), and still see passwords. So you're really only protecting against network-sniffing attacks, which are USUALLY prevented by SSL anyway. This actually gives me an idea, but I'll have to think about it. Something along the lines of using an MD5 of the sign-in page itself as a part of the process, so changing the page will break things. That's obviously vulnerable to exactly the same attack, but perhaps there's an extension to this which might work.
You have also prevented plain-text reveal in the situation where someone somehow intercepts the post-SSL stream but can't alter the application, which is certainly a possible scenario.
There's a major benefit, with this scheme, if you're using a dedicated ssl server and relying on a secure network behind that (which is not uncommon in higher-load applications) - compromise of the ssl server doesn't lead to compromise of plain-text passwords. The attacker would need to take the next step and own the application servers behind that, and given that this scenario only crops up in high-volume load-balanced systems, there are likely lots of identical systems to deal with, and (hopefully) switched-on administrators and security experts, so adding another step like that could vastly decrease the chance of a complete compromise. The attacker would already own login details to the attacked site (they could replay hashes from the owned SSL appliance), so there's every chance they'll take that and never even try to compromise the application code itself, thus never leading to the plain-text reveal.
You've basically described how it usually works, except that instead of having the client perform a hash, we have the client encrypt the communication over SSL. The advantage, that the password can't end up accidentally in a log file, means now that instead of the password, the hash that the client sends would end up in the log file. I'm worried that you're adding to the complexity of your code in order to prevent an avoidable bug - it seems like you'd be better to just ensure that sensitive information isn't showing up in your logs (which is a crucial step in avoiding security holes; it's specifically addressed in, for example, the PCI security standard).
There should be one salt per user, not one per application. This means that the whole effort to generate a rainbow table is only applicable to the one user you're trying to recover the password for; the rainbow table for the next user will be totally different, because there's a new salt. This means that all of your work to hack one account can't be re-used for the next. Salting isn't about preventing this sort of attack; it's about multiplying the effort to compromise n accounts by n. If it takes the attacker 5 days to compute a nice big look-up table, they now have to repeat that per account, instead of having now compromised every account.
Everyone knows not to store passwords in a database. You store hashes in a database instead, which is what your link (and TFA) are talking about.
It doesn't even require a replay attack. We're talking about what happens if the database of stored hashes is compromised, and if the client does the hashing instead of the server, you don't even need the password. You can just submit the hash from your stolen database to sign in as the user.
Uh, what? The browser hashes the password? Now you don't even NEED the password; you have the hash, and that's all the client needs to submit to gain access! You just pretend that you hashed the password and transmit the hash. No password needed! Unless, of course, you submit the password AND the hash, but that doesn't gain anything over just submitting the password (except perhaps proving that the client has a working hash function).
Remember, we're talking about what happens when the database of stored hashes is compromised, and having the browser do the hashing makes this scenario MUCH worse.
A correctly-implemented salted-password scheme uses a different salt per user - it doesn't even matter if it's trivial to predict. The point is that it multiplies the computational load to compromise n users by n. You can't generate a single look-up table any more.
Further, the salt is combined with the key, not the user's password. If it was just combined with the password before the encryption, when you used your look-up table to find out the (password+salt) used to generate a particular hash, you would then de-combine the known salt and have the password! Simple.
Finally, because the salt is combined with the encryption key, using one salt for your whole system would be no different to just using a different key.
With the correct scheme, adding a per-user salt means (even if the salt is trivial to discover) you are using a DIFFERENT key to compute the hash for each user. Now you may still be able to generate a large look-up table of hashes to compromise an individual hash, but it will only work for ONE user account (barring salt collisions), and so a 24-hour run (your number) will be required PER USER ACCOUNT. This means that a few dozen, or even a few hundred, accounts may be compromised, but this will be a much smaller fraction than if you weren't using salts (or were using them incorrectly, as is so common).