Tech Interview Handbook - <AUTHOR> https://yangshun.github.io/tech-interview-handbook/ <comment><USER2> I realize everybody's going to jump in and rant about algorithms in interviews, but I wish you'd all add something constructive as well.

I just had to conduct a round of interviews in a non-SF large US city, and it was a hellish crapshoot. Resumes are meaningless, and often re-written by recruiters to match the job anyway. Everyone has the same canned answers to the stupid behavioral questions. And as for the code, we included what we thought was a trivial nested for-loop problem and virtually nobody could even get started on it.

Is this kind of code problem too complicated in your opinion? For all I join in when complaining about irrelevant algorithmic questions, I have to admit that they at least test _something_ , even if it's just willingness to study for the interview.

Instead of reading everybody's complaints about interviewing, I'd love to hear how you think it should be done. Because I have to admit I'm pretty much lost right now.

<comment><USER3> I can tell you how I do it and would certainly recommend it as the way it should be done. For some context, I've been interviewing software engineers for about 25 years in companies ranging from established multi-nationals to tiny startups in very fast headcount-growth mode. I'm in silicon valley. I can say that I've never regretted a hire I said yes to, so the method works to my satisfaction.

It'd be nice to think I have some special skill here but I really don't. This is just how interviewing was done in the 90s. To some of the younger generations, I've been told it sounds crazy.

If you send me your resume I'll actually read it, carefully. If the person described in this resume fits the background experience the role needs, you get an interview.

During the interview we'll talk about all those projects you worked on that are relevant to this role. Which parts you enjoyed the best and why? Which parts were boring and why? Which parts were the most challenging and why? What you find too easy and why? What would you have done differently? Could you have? If you were to do the same project all over how would you approach it? Other open ended conversations along these lines.

I don't ask anyone to whiteboard code, that's not part of the job so it's not part of the interview. No puzzles, no trivia-pursuit style questions.

It works great. You can't BS your way through such a conversation with a senior technical peer if you didn't actually do the work described in the resume. You just can't.

It is, however, vital that the interviewer must be a expert in the field.

<comment><USER4> These questions should definitely be part of the interview process, but not all of it. I've done a lot of these kinds of interviews and I've definitely seen candidates that speak impressively but fail basic technical tests.

If you don't actually verify the technical problem-solving ability of the candidate in _some_ way you're forgoing signal that can massively increase the confidence you can have in your decision.

<comment><USER5> Anecdotal but we've hired an engineer who was pretty decent in the interview but couldn't figure out how an if statement worked in a legacy codebase.

Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.

<comment><USER6> So I had the same problem for a while, it was quite absurd, because I got through my uni courses, could decently code in Haskell and some other things, but never figured out the appropriate position to put an if clause.

I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages.

Point of this comment is that people might be good at a lot of things, while just having some weird brainfuse related to a very specific thing. That said, not using if statements makes programming rather difficult.

<comment><USER5> No see I wish they had any redeeming skill, he always asked an engineer to assist him with anything. They couldn't figure out anything on their own. It was shocking someone could complete the interview (small problem with a solution that is essentially explained, make x do y) and completely fail at building their own solutions without guidance

</comment></comment></comment></comment></comment></comment><comment><USER7> Given the current state of tech interviews, they have more or less become like standardized tests, such as SAT, ACT, GMAT, GRE... with guides, cheat sheets and perhaps neighborhood coaching institutes on the horizon with instructors who have cleared tech interviews in FAANGs.

Are we going to see tech recruitment become more and more like college admissions where a top score in the interview is just one of the criteria and no longer sufficient to get a job?

Perhaps next is asking people to write essays regarding career, goals, why they want to work their, extra curricular etc..

<comment><USER8> Y'know, as someone who went to a very competitive public school, there were a particular brand of driven, studious kids who knew exactly how to paint along the lines, play the game, and get into the college of their choice. They understood the precise combo of grades, extracurriculars and essays to get into a "good" school.

I definitely see some of those kids doing the same tactics to get into a "good" company. The steps are slightly different but the philosophy is the same: grind Leetcode, participate in tech clubs and take bullshit jobs juuust long enough to get an internship, get said internship and parlay it into a return offer. Put your head down, play the game and reap the rewards.

<comment><USER9> I mean it's all a game as much as it sucks. One of my best friends in high school was a salutatorian because the school didn't wait grade. She took zero AP classes and very few honors classes. She knew what she was doing.

Friends in college took less challenging majors to boost GPA for med school (business admin, environmental policy, etc) to boost grades and there core classes were easy so it gave them more time to focus on med school pre-reqs.

It has been and always will be a game. Few things in this world come down to meritocracy because the way we socialize and the way we interview does not beget that in absolute terms.

Tech did a better-than-most job as a meritocracy for while, but I believe those days are done. Most areas f tech are too mainstream with too much obvious money at stake.

<comment><USER10> I don't understand why you are discrediting people who are taking the better path to med school. Work smarter, not harder.

There is also short game vs long game. For example, if you cheat on a test without learning the material. You might win the short game, but if that material was important and you need it later you're losing the long game. That said, if the material was just fluff and no one really cares. It's actually smart just to cheat and get by.

<comment><USER11> People who take the easy way or cheats to get around bureaucracy will do the same thing after you hire them at the job. They will do things like avoid password salting for your database unless you explicitly tell them to do it etc.

In other words, I don't want to hire "smart" people, I want to hire intelligent people who take pride in what they do and don't try to take shortcuts to make their lives easier at the expense of others.

</comment></comment></comment></comment></comment><comment><USER12> Having hired dozens of devs, I can confidently say there is absolutely 0% chance to consistently successfully identify good developers in any reasonable amount of interviewing / assessment time period.

The best way is someone brings in an existing code portfolio and discusses it.

The second best way is someone completes multiple design and development exercises of varying complexity, constraints, and use cases.

The third best way is they complete a single exercise and provide commentary on alternative designs.

There is no fourth best way; all other approaches are essenrially stochastic and select for interviewing traits not development traits.

The actual best method I think is a 3 month probationary period which is more or less an extended interview. They're asked to contribute to existing codebases, participate in code review, go through some architecture design sessions, conduct stakeholder interviews - things that again are mostly impossible to accurately gauge in a typical candidate assessment window.

By the way a tremendous book for interviewers and hiring managers is How Judges Think by Richard Posner. A lot of it applies to hiring, and he's a great writer.

<comment><USER13> > The actual best method I think is a 3 month probationary period which is > more or less an extended interview

Most states in the US have at-will employment terms. Probationary periods are common in other countries. And yet no one seems to want to do what you're suggesting.

<comment><USER14> The problem is, most companies in the US want to hire you on as a Contractor and not a full time employee for those three months. I can't speak for everyone (but most folks, I assume), but I need medical and dental. I can't go three months for the chance of maybe getting it. I can't do it personally and i can't do that sort of thing to my family. there are other options in other countries (depending on the country). I'm a centrist by nature, but this makes a "three month interview" untenable, IMO.

<comment><USER13> Sorry what I meant was US companies could treat the first 3 months of any full-time/W-2 employee as probationary because they can fire anyone for any reason other than protected characteristics. It doesn't even need to be an official company policy documented anywhere.`

<comment><USER2> They could in theory, but nobody wants to. I used to see probationary periods, but I haven't seen a company use that for salaried staff for a long time. HR and Legal have put an end to that kind of thing.

So Jim is right, in practice the only way HR is going to let you have a probationary period is to use contractors, and that limits your hiring pool significantly.

<comment><USER15> Every decent sized contracting firm I've ever worked with offered benefits. It's more expensive, but you just price that into your rate. So I don't understand what the concern is. Is it the risk that after 3 months you won't be brought on full time?

<comment><USER2> Upheaval is the issue. First, most contracting firms have pretty crappy medical plans. Secondly, there's generally a wait period before full benefits kick in. Thirdly, you wind up switching your medical plan multiple times in a short period.

That's fine if you're single, but if you've got kids that might mean switching doctors multiple times, which is a gigantic huge deal. Also, you have multiple periods of time where you don't really know your benefits which is terrifying. And if the company _does_ drop you after three months for whatever reason, now you're doing it again.

And keep in mind it's definitely a seller's market if you're a good dev. It's incredibly unlikely that the 3-month contract is the only offer on the table. So all things being equal, who would take it?

<comment><USER15> Your description sounds like this should only be a problem for families with serious medical issues, which would be the minority. I do have a kid. If your kid is relatively healthy then pediatricians are basically replaceable widgets. If it's important to you, just pay the cash rate for your favorite pediatrician during that 3 month period. If you're really hung up on it, you can just choose the COBRA option and keep your old insurance during your trial period. It's very expensive, but again, you just calculate that into your contracting rate.

>And keep in mind it's definitely a seller's market if you're a good dev. It's incredibly unlikely that the 3-month contract is the only offer on the table. So all things being equal, who would take it?

I don't feel any additional security whatsoever being a least tenured employee vs contractor. Maybe there's some statistical benefit, but it seems pretty small. So for me, it's practically zero cost to do the contract-to-hire thing. Any financial costs are just built into my rate. I'd rather spend my hiring currency on other stuff like working remote full time and extra vacation days.

It probably makes a difference that I spent a big chunk of my career as a self employed consultant. I do remember feeling some anxiety when I first transitioned from a regular employee to consulting. But I quickly learned my anxiety was unfounded.

<comment><USER2> I do a lot of consulting as well and am comfortable with it. But most people with families want more stability. I don't know why you're pretending to be surprised by this.

Your personal preferences aren't really the topic at hand.

<comment><USER15> It's not about my personal preferences. If you're concerned about an instability period on your healthcare you can literally keep you old healthcare for up to 18 months with COBRA. Adding the contract-to-hire period doesn't really impact instability, at least as far as healthcare is concerned.

<comment><USER2> I fear we've gone down a wrong turn. You may be 100% correct that fears about instability are irrational and not well-grounded, which is the point you've argued for several posts.

But nobody is arguing with you. Nobody is making the contrasting argument. That simply isn't the conversation anybody is having. It's an interesting conversation, it just doesn't happen to be _this_ conversation.

<comment><USER15> I asked what the concern was and you responded primarily in the area of health care/insurance. So that's what I addressed. What else is the conversation about if not that?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Two outcomes for the technical industry:

1.) Everyone is studying these problems all of the time and they finally disappear.

2.) Other outcome is a dystopian field fueled by a race to the bottom where everyone is practicing algorithms problems all of the time. If you read the blind forums, some people are completing 500-1000 leetcode problems before heading into interviews.

I'm putting my money on number 2, which is where we already are. Can only imagine what this is doing to code quality...

<comment><USER13> > Can only imagine what this is doing to code quality...

Why would studying algorithms and data structures affect code quality? They would similarly be able to learn to write quality code once they're inside the company, no?

<comment><USER17> Because these problems encourages you to write unreadable code. It makes sense when you write it, because you can fit it in your head, but you never have to revisit it after having passed the problem. It encourages one letter variable names and other quick hacks in the name of speed.

They work against creating readable, understandable and debuggable code which is much more important in general than being able to solve algorithimical problems you'll almost never see in real life.

I've seen this first hand where some were brilliant at these problems but wrote the worst code imaginable. I would rather hire someone who can write clean and simple code and teach them how to solve these problems than the reverse.

<comment><USER11> > I would rather hire someone who can write clean and simple code and teach > them how to solve these problems than the reverse.

Why? Teaching people to write readable code happens automatically during code reviews, teaching people how to think is a lot harder.

<comment><USER17> Because producing simple and good code is much more important.

It's quite condescending and narrow-minded to say that solving algorithmic problems is thinking, but writing clean and simple code isn't.

Writing readable code is much more than just formatting code and using decent variable names. It's about simplifying your design just enough. Code reviews is not enough to teach someone this.

</comment></comment></comment></comment></comment><comment><USER18> There is something I cannot understand and this has already become a cliche: > Technology industry is an extremely fast-moving one. Many technologies used today didn't even exist/were popular a decade ago; in 2009, mobile app development and blockchain were pretty much unheard of. Engineers constantly need to upgrade their skills to stay relevant to the demands of the job market. Engineering is a great career for passionate individuals who like to learn.

Why would anyone give this advice? Can we stop handing out this advice and encourage everyone to stand up for their rights instead? If you think about it, by proxy this gives you the following advice: as a programmer you will have no life outside of work and you are supposed to be an idiot who spends his time working and studying outside office hours even when you could spend time with your family. So yeah, go for it and suck it up you idiot.

At least that's how most employers handle this problem. And interestingly by comparison no-one tells a MBA diploma holder that it's a great career for passionate individuals who like to spend their whole life studying.

And before you think that I am against studying, that's not the case at all. If my company pays for it and I can kick back on a sofa during working hours to study I am fine with it. But I cannot see any value studying something on my own expense on my own time which will be outdated in 3 years anyway and so by definition it only benefits my employer.

<comment><USER19> _Why would anyone give this advice?_

It seems relevant to getting a tech job. If one is looking for a job, chances are that things have changed since the last time they looked for a job, which on an average for most people these days is every 2-5 years.

This is not limited to engineering or tech, and extends to most specialized jobs in most industries.

 _Can we stop handing out this advice and encourage everyone to stand up for their rights instead?_

In the right context absolutely. In general, its possibly a bad idea. You could always balance it out and educate the folks about the rights of an employer

If you were on my team, I would not expect you to sacrifice any of your rights. But if you kept falling behind your peers, to the determent of the team's performance, at some point you would be put on a performance plan. The unfortunate thing about performance plans is that by the time its enforced things are close to unrecoverable.

And if you did find yourself failing, I hope someone tells you that:

 _The technology industry is an extremely fast-moving one. Many technologies used today didn 't even exist/were popular a decade ago; in 2009, mobile app development and blockchain were pretty much unheard of. Engineers constantly need to upgrade their skills to stay relevant to the demands of the job market._

Because, I will not.

<comment><USER18> I don't know what is a performance plan. Can you elaborate? I have never worked in a company where there was such a plan.

Is this public to employees or you just simply whip everyone until they work themselves to death without telling them the reasoning?

Also I assume you are in the US. In most European countries you can absolutely do nothing about someone who works full time on your team unless they let's say causes you financial losses or punch you in the face, so you can basically shove up your plan to your bottom part in other cases.

<comment><USER19> Performance plans, or performance improvement plans, are extremely verbose formal documents that are used as a last step to tie up all legal requirements before terminating an employee. These are most commonly used in countries outside US.

Most of the US follows At-will employment[0], so generally no performance plans are necessary.

This is not public. We've only used it twice, one person was suspected of misappropriation of funds (and later proven), and one that's currently in motion is an employee that misrepresented their technical knowledge i.e. cannot write code, convinced other employees to do 90% of their contributions.

I get that there is this impression of the US whipping everyone until they work themselves to death. Anecdotal, but I've never really experienced that. If anything, the folk in the US like being busy, and workplaces (at least in tech) are overly happy, in something that reminds me of a cult.

I have lived an worked in 5 countries in 3 continents and worked with people living in many more countries. In my own observations, the US colleagues have usually exhibited the highest level of happiness/satisfaction. They also tend to find their next jobs the quickest. And are paid the highest.

[0] [https://en.wikipedia.org/wiki/At- will_employment](https://en.wikipedia.org/wiki/At-will_employment)

<comment><USER18> Thanks for the info. Interesting. But I assume this (i.e. the plan) is something that the employee can choose not to sign if it was not in the original contract and the law doesn't require him to do so. At least I wouldn't sign anything like that. And if he doesn't sign it then you can try firing him. Which might or might not be legal (which usually a court decides). At least that's how it works in those countries I worked in.

It's also not rare and it's actually on the news all the time all around in Europe and Japan that a company fires someone whom later the company is forced to hire back by court ruling.

</comment></comment></comment></comment></comment><comment><USER20> Some of these "questions for the interviewer" are very good. In particular I like some of the "tell me the negatives" ones:

> What is the most costly technical decision made early on that the company is > living with now?

> What is something you wish were different about your job?

> What has been the worst technical blunder that has happened in the recent > past?

<comment><USER21> These are good questions, I like how they are phrased so concretely instead just asking "do you have a lot of tech debt?" They're interesting for getting to know the team and getting a piece of insight you usually wouldn't have until a few weeks into the job.

But I would be careful how you interpret these. In fact I would almost factor in these answers in the opposite way of what I think you intended. The company that admits to the worst technical issues is at least honest and self reflective. The company that doesn't admit to any serious issues might be just as bad or worse, but their strategy is to tell employees to lie about it rather than be open to addressing it.

</comment></comment><comment><USER22> For all the negativity for these type of tech interviews, they are, from what i've seen, one of the most merit based systems out there. It is either this or we need to create some sort of national developer exam. The other alternate is to get jobs at good companies, they will only look at what school you went, whether you graduated with a CS degree, what companies you worked etc... All things which do not guarantee merit.

<comment><USER23> Merit at high pressure performance, not being a good developer.

<comment><USER22> it is not a perfect system but nobody can really predict a good developer till someone is already on the job. A good developer is more than algo skills, he/she also has good communication, works well with others etc... These are not things we can test yet. The problem with our profession is since it is lucrative and has no real licensing, it is a perfect breeding ground for fakers.

</comment></comment></comment><comment><USER24> While this is very good to study before a technical interview, over time however I can see that this alone is going to make it 40x harder to differentiate say 100 candidates that are all perfect at interviews in general, that we are going to start asking ridiculous Oxbridge-style interview questions and expect perfect scores to advance 'good' candidates.

Perhaps companies will start asking candidates to construct mathematical proofs of data structures, algorithms, formulas and common equations from university-level entrance examinations just to do a mobile app or a web dev job.

As soon as that happens, the 'ideal candidate' companies will be expecting to interview would be a very prodigious candidate, former math Olympiad champion and decorated with titles and research papers in their name.

You guessed it: 𝔜𝔢 𝔬𝔩𝔡𝔢 𝔩𝔢𝔤𝔢𝔫𝔡 𝔬𝔣 𝔶𝔢 10𝔵 𝔡𝔢𝔳𝔢𝔩𝔬𝔭𝔢𝔯.

<comment><USER25> > Perhaps companies will start asking candidates to construct mathematical > proofs of data structures, algorithms

Perhaps we'd produce better software if people prioritised correctness like this in practice!

<comment><USER24> Perhaps so. Those sort of questions would benefit a company working at the scale of FAANG or Microsoft and actually tackling or researching real computer science problems.

Now would this make sense for a graduate entry level role for a web / mobile app developer position? Interviewers looking for such candidates need to lower their expectations a bit in for positions like that.

</comment></comment></comment><comment><USER26> I once interviewed at a startup for a senior engineer position and was asked "if aliens came to Earth and asked you to go into their UFO with them, would you?"...

As much shit as we give white-boarding, I would have chosen it instead if it were an option.

<comment><USER27> At one time i was asked "why do frogs croak? I gave a series of answers like: to attract the opposite sex, gave some biological explanation of how they achieve that. But the stupid interviewer kept asking me why?

Needless to say after the interview ended i ran away from that deal.

</comment></comment><comment><USER28> > Get a proper email account with ideally your first name and last name, eg. > "firstname.lastname@example.com" instead of "email@example.com"... Avoid emails > like "email@example.com" or "admin@[mycooldomain].com" \-- because it is very > prone to typo errors.

I don't think I've ever seen anyone explicitly recommend against using a custom domain for email.

<comment><USER29> That's what I was thinking as well. If I gave you the following emails: firstname.lastname@example.com firstname.lastname@example.com email@example.com email@example.com

Which would look most professional?

</comment></comment><comment><USER30> Well organized, but a lot of noise. This is honestly the best guide I saw (got a job at a FAANG company following it):

[https://haseebq.com/how-to-break-into-tech-job-hunting- and-i...](https://haseebq.com/how-to-break-into-tech-job-hunting-and- interviews/)

</comment><comment><USER31> When I talk to other Android Developers I notice that they aren't really using much of data structure and algorithms in their day to day programming except 1-2 very basic one's like ArrayList, List, and HashMap.

1\. If I am not using a lot of data structure and algorithms in my day to day work how am I supposed to be good at it?

I am very good at finding solutions to problems but I am very bad at remembering a lot of things.

2\. How does one even prepare for a subject as big as Android? The thing is vast. And asking trivial things about it won't be very useful.

</comment><comment><USER32> In my experience, dynamic programming is overrepresented in interview questions (vs. like other algorithm techniques). Everyone loves to ask dynamic programming questions, make sure you've done a lot of them and you'll look really impressive.

</comment><comment><USER33> How is this much different than a paid smaller version of LeetCode?

When I was prepping I got the most value out of LeetCode for solo prep, followed by mock interviews with sites like Pramp.com, Gianlo.co, and PracticeCodingInterview.com.

I don't know why tech companies don't just admit that this is all pretty much standardized at this point. Just build a standardized test, or certification, and get it over with.

<comment><USER34> That's a great idea. Tech interviews are a poorly implemented version of something like actuarial exams. Let's formalise it and give people a certificate for it - Certified Software Engineer.

I'm only half joking. At least we'd only have to go through the process once.

</comment></comment><comment><USER35> So, as someone who's been out of school for a million years, after my name and contact info, my education info is the second most important thing?

I don't think so

Maybe this should be titled "Just Graduated? Some Useful Tips"

</comment><comment><USER36> I stumbled across another amazing resource a while back - recorded mock interviews:

[https://interviewing.io/recordings/Python- Google-6/](https://interviewing.io/recordings/Python-Google-6/)

I'm not affiliated with this site, I just thought this was a great idea and well executed.

I used to lean toward the "studying algorithms, data structures, whiteboarding, etc. is useless since I'll never actually need them" ideology until later in my career when I realized that worst case (for me) I can take a break from building CRUD apps and refresh my CS fundamentals. I enjoy speeding up code and then asking myself, "can I do better?" each step of the way, trying to make further improvements.

</comment><comment><USER37> What if people not being able to answer simple programming questions is a problem with the interviewers, and not the interviewees?

<comment><USER38> This is one of those ideas that sounds really sophisticated, but is just wrong.

The fact is that there a tons of people out there representing themselves as programmers who actually can't perform basic tasks.

The HN population massively selects for competence, so people here have a hard time imagining what things are like from the interviewer side.

<comment><USER23> Notwithstanding, interviewers could also be asking misguided questions. Which I find often.

</comment></comment></comment><comment><USER39> This thread has been a great discussion. We are a startup and did hiring ourselves. We gave 1) algorithms, system designs type on questions 2) a mini project like build a profile in React Native. With 10 sample size, we found people who finished the project quickly and reasonably performed well at work while candidates who passed algorithms didn't grow as fast.

The main thing is the problem solving oriented skills in a project that really makes a difference.

Thus, we pivoted to do a mini project screening automation for companies to do hirings. This site has backend to frontend tasks that come with a CLI to code the project locally. The website is called [https://real.dev](https://real.dev). We want to solve this interview problems for companies.

</comment><comment><USER40> I'm going a different route with interviews and wonder if anyone has input... I'm a senior backend dev with 10+ years of experience. Breadth of projects, masters in CS, open source work, team lead, top contributor, great references, etc. But I cant pass a coding interview, because I kinda freeze up during algorithm whiteboarding questions. I get requests for interviews daily and have been considering starting with a cover letter that basically says I'm not good at coding interviews, but love to talk tech (and see other positives above). Could I do a homework assignment or anything else to show my worth?

Has anyone had any luck with an approach like this?

<comment><USER23> Put "I don't do pop quiz interviews" on top of your documents and see what happens. I do this but haven't been so blatant about it. Networking is the only other avenue.

</comment></comment><comment><USER41> > ... nobody needs to know: > Anything less recent than 3-4 years

Really? I did the most interesting and challenging projects earliest in my career (late 80's to early 2000's) -- just due to the nature of the industry, I'd think that more recent project descriptions have undergone a certain homogenization that would make them less and less an indicator of talent and varied experience.

I can chat excitedly about early projects, but now people must all be saying "cloud blah JS blah containers blah blah bit-pipes and storage blah - oh yeah, and modands!"

</comment><comment><USER42> Jezus, the amount of hoops people are willing to jump to work at a certain company. And it baffles me that I might want to jump these hoops as well ..

</comment><comment><USER43> This looks pretty reasonable [https://www.blog.google/technology/area-120/byteboard- interv...](https://www.blog.google/technology/area-120/byteboard-interview- measures-for-essential-engineering-skills/)

</comment><comment><USER44> One of the goals of technical interview (or any interview) is to find your real charterer (are you lazy? do you break when you do not find a solution? are you creative?)

The quickest way to do that in a 45 min, is to put the candidate under pressure.

The best way to put a developer under pressure is to ask coding questions and expect some solution in a very short time.

Note that the goal is NOT to find out if you know the ins and out of a specific algorithm. It is to discover how you think under pressure.

</comment><comment><USER45> Curious as to why the geographical locations provided are only for US and Singapore.

<comment><USER46> The author is from Singapore and writing from the perspective of a graduate with fang jobs to his juniors. Also, looks like it showcases some software(Docusaurus) he made at facebook.

</comment></comment><comment><USER47> Just wanted to say thank you for this!

</comment><comment><USER48> Thanks. This is gold.</comment>


A practical security guide for web developers - <AUTHOR> https://github.com/FallibleInc/security-guide-for-developers <comment><USER2> Had this SO link saved since probably soon after it was asked 7 years ago. Still relevant and still being updated.

[http://stackoverflow.com/questions/549/the-definitive- guide-...](http://stackoverflow.com/questions/549/the-definitive-guide-to- form-based-website-authentication)

Includes:

\- How to log in

\- How to remain logged in

\- Managing cookies (including recommended settings)

\- SSL/HTTPS encryption

\- How to store passwords

\- Using secret questions

\- Forgotten username/password functionality

\- Use of nonces to prevent cross-site request forgeries

..........

And much much more.

<comment><USER3> The quote at the beginning of the SO question you linked to, one of the top-25 questions of all time, is so ironic given the current state of SO:

> We believe that Stack Overflow should not just be a resource for very > specific technical questions, but also for general guidelines on how to > solve variations on common problems.

SO is a great website, but I wonder how much more it could've been if this sort of a page was allowed now.

<comment><USER4> I know what you're saying but they're coming out with Stackoverflow documentation : [http://stackoverflow.com/tour/documentation](http://stackoverflow.com/tour/documentation).

Not sure whether this will be the solution that you're looking for. But if you give feedback, maybe, it will happen sometime.

</comment></comment></comment><comment><USER5> Efforts like this are very good.

But one of the most serious problems with web development is how few frameworks ship with most of these sane answers out-of-the-box ( _edit_ : or don't ship concepts at the right level of abstraction)

When we all need to copy-paste some best-practice way of how to Argon2 a password and how to constant-time equality check a hash, we've already lost, in that we're reimplemeting these sane answers every time from the weeds.

I want to see more things like Django's automatic password hash upgrading [1].

Specifically, checklists like this effort's should be for people who develop frameworks, and not people who develop custom apps with them. With some things like CSRF protection, we're already there, but with so many other things, we're not.

[1] [https://docs.djangoproject.com/en/1.9/topics/auth/passwords/...](https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#password- upgrading)

<comment><USER6> While I appreciate the kind words for Django, there are plenty of libraries and frameworks out there which are doing the basics of web app security out of the box these days, and my recommendation is to find one you like and use it.

The big obstacle there is people who insist on writing their own versions of everything rather than using off-the-shelf components. I know it's a point of pride for some folks not to "rely" on third-party code, or to post long rants from someone's experience with a late-90's-era framework as evidence that they're all awful, but getting a bunch of best practices done for you for free is the advantage they offer, and given how hard it is to cover even the basic security bases, that's an advantage I think people increasingly can't afford to give up.

</comment></comment><comment><USER7> Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson is available online for reading -- [http://www.cl.cam.ac.uk/~rja14/book.html](http://www.cl.cam.ac.uk/~rja14/book.html)

A couple of other resources:

\- 7 Security Measures to Protect Your Servers [0]

\- SSH best practices [1]

In case one doesn't prefer to be overwhelmed with documentation, one could refer to: My First 5 Minutes On A Server; Or, Essential Security for Linux Servers [2].

[0] [https://www.digitalocean.com/community/tutorials/7-security-...](https://www.digitalocean.com/community/tutorials/7-security- measures-to-protect-your-servers)

[1] [http://www.cl.cam.ac.uk/~rja14/book.html](http://www.cl.cam.ac.uk/~rja14/book.html)

[2] [https://plusbryan.com/my-first-5-minutes-on-a-server-or- esse...](https://plusbryan.com/my-first-5-minutes-on-a-server-or-essential- security-for-linux-servers)

</comment><comment><USER8> Rather than just "JWT is awesome..." wouldn't it be more sensible and responsible to caveat this with some of the drawbacks?

I read this article recently ([http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt- fo...](http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for- sessions/)) that proposes not to use it for sessions but instead for the use cases listed at the end of the article. Follow-up article here [http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt- fo...](http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions- part-2-why-your-solution-doesnt-work/)

Also this [https://auth0.com/blog/2015/03/31/critical- vulnerabilities-i...](https://auth0.com/blog/2015/03/31/critical- vulnerabilities-in-json-web-token-libraries/)

<comment><USER9> Why not using one key per user? Then I would just have to invalidate this one user and not all of them.

<comment><USER10> You don't know who the user is until you verified the integrity of the JWT. Verifiying the integrity requires the secret. Your solution adds the dependency: the secret requires the user. It is cyclic, unsolvable without breaking a constraint.

You could assume the username is correct, then get the secret, validate. But that sounds like something breakable.

</comment></comment></comment><comment><USER11> A great book is The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition [0] - by learning how hackers search for and exploit various web issues - you'll be naturally aware of them to defend against. i.e. start thinking like a hacker and you'll be amazed at the issues you discover in your applications.

[0] [http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118026470...](http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118026470.html)

<comment><USER12> Agreed, still the best text out there for web application security.

</comment></comment><comment><USER13> There's a whole section on input sanitization but nothing on escaping output.

If you're on the hook to sanitize all inputs, doesn't that mean you're not escaping output?

The biggest security mistake I've made so far in production was that one time I used an HTML templating library that didn't escape output by default.

<comment><USER14> Can you clarify? What exactly do you mean by escaping output, and how can forgetting that cause a security issue?

<comment> nommm-nommm Example HTML output in a user's profile:

Would you like to contact ${NAME}?

Where ${NAME} is a user supplied parameter (you ask them what their name is)

Let's say I entered my name as: <script>/ __evil code __/ </script>

Now, if the output isn't escaped the page reads:

Would you like to contact <script>/ __evil code __/ </script>?

You've just injected evil code into the website that will be executed every time my user profile page is visited by another user.

EDIT: Hacker news doesn't properly render javascript comments.

<comment><USER15> But that script tag would be taken care of in the input sanitation step. You normally remove all hints of HTML tags on input sanitation, which renders output sanitation a moot point.

<comment> nommm-nommm >>You normally remove all hints of HTML tags on input sanitation

Then what happens when you want to use that input in an excel export? PDF export? CSV file? Text file? How about if you want to use it in an HTML attribute? In a URL? Export the database elsewhere? (Such as a credit card company reporting to the CSAs). You can't assume that your data is going to be inside an HTML page between tags always because that mucks up your data. Data should be able to be used in many different ways because it will be and should not be tied to HTML.

<comment><USER14> Ok, this is the comment that best explained it to me -- you want to sanitize (escaped, etc, whatever) output because, even if you sanitize all HTML/CSS/JS on input, they might have inserted malicious Excel scripts or PDF exploits, etc, that eventually do get executed in an output context.

</comment></comment></comment></comment></comment></comment><comment><USER16> Use static source code analysis and dynamic web app scanners.

They are easy to integrate into your SDLC, they are not going to replace manual testing or secure development practices but they'll help a lot. They'll pick up tons of stuff for free, they'll remind you best practices.

I have a startup (at least it still feels like a startup!) and we are developing a web application security scanner called Netsparker [0]. It found over 100 zero days in open source applications while testing it [1], including very popular vulnerabilities in applications such as Wordpress and Joomla. I guess that by itself proves how good scanning can be.

If you want to try it on your websites and see it for yourself drop an email / message to firstname.lastname@example.com with a mention of HN and I'll get you a fully functional trial that you can use on your own websites.

[0] Netsparker Cloud [https://www.netsparker.com/online-web-application- security-s...](https://www.netsparker.com/online-web-application-security- scanner/) \- Netsparker Desktop [https://www.netsparker.com/web-vulnerability- scanner/](https://www.netsparker.com/web-vulnerability-scanner/)

[1] [https://www.netsparker.com/web-applications- advisories/](https://www.netsparker.com/web-applications-advisories/)

<comment><USER17> How does this compare with Trend Micro Deep Security for Web Apps? We're using it now but it does not seem effective - not catching much in its scans. So we're looking at alternatives...

<comment><USER16> I never used them or seen them in a benchmark so cannot comment much of the capability or quality. I think it's best if you compare it for yourself. Running a scan very easy and won't take much of your time, drop me an email and will get you a license or account to our cloud solution, so you can test it and see how it compares. Email: firstname.lastname@example.com

</comment></comment></comment><comment><USER18> The problem with checklists, including this one, is that we tend to limit ourselves to what's in the list. Furthermore the list doesn't explain 'why' you should do things. They help, but nothing is a replacement for education. And when it comes to education, there's a decent write up I did and is still accessed in a daily basis [0]. I also recommend you to check OWASP [1] and read their "Testing Guide" to know many attacks and defenses.

[0] Security for building modern web apps [https://dadario.com.br/security- for-building-modern-web-apps...](https://dadario.com.br/security-for-building- modern-web-apps/) [1] [https://www.owasp.org](https://www.owasp.org)

<comment><USER9> Well, at least it's a good starting point.

</comment></comment><comment><USER19> Where is the actual guide? Is this the TOC for a book? It looks good but I don't see the actual content, just a check list and a table of contents.

<comment><USER20> Exactly! Where are the doc to all the sections? This seems terribly important stuff, but it looks like a 'teaser' to a book? If not where do we get the information for each section?

<comment><USER7> It's mostly a security checklist (as of now): [https://github.com/FallibleInc/security-guide-for- developers...](https://github.com/FallibleInc/security-guide-for- developers/blob/master/security-checklist.md)

</comment></comment></comment><comment><USER21> This is one of the best examples of how Github nails collaborative document development I've seen.

It is striking how valuable much information is retained in negotiating the material here, vs email arguments with word documents and embedded content, where the app-seperation of submissions makes it too difficult to consume.

</comment><comment><USER22> > Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for > you).

In PHP, I would rather recommend to use password_hash() with its own defaults since it's built-in and designed specifically for this purpose - and quite future-proof. But this is PHP specific.

> [] Destroy all active sessions on reset password (or offer to).

> ...

> [] Destroy the logged in user's session everywhere after successful reset of > password.

I believe these are the same. The second one is clearer though.

Edit: clarified

<comment> nommm-nommm I think the first one is saying "destroy active sessions when a user _attempts_ to change their password" and the second one is saying "destroy active sessions when the user succeeds in changing their password."

<comment><USER23> My interpretation is: "when a user changes their password, _offer_ to destroy all active sessions"

</comment></comment></comment><comment><USER24> * Don't let HTTP GET requests modify state, ever. It's very difficult to prevent CSRF via HTTP GET.

* Session keys are password-equivalents. Hash them with bcrypt or something before you store them.

* httponly is not incredibly useful. If the attacker can run JavaScript on your page, you're in trouble.

<comment><USER25> > Don't let HTTP GET requests modify state, ever. It's very difficult to > prevent CSRF via HTTP GET.

Isn't it exactly as difficult as any other method?

> Session keys are password-equivalents. Hash them with bcrypt or something > before you store them.

bcrypt is overkill, especially for something that has to be checked every request; just use any SHA-2 (non-iterated). A session key should be long enough _by far_ to resist brute force.

</comment></comment><comment><USER26> This reminds me of:

"The Basics of Web Application Security" (Cade Cairns, Daniel Somerfield)

[http://martinfowler.com/articles/web-security- basics.html](http://martinfowler.com/articles/web-security-basics.html)

It's an ongoing evolving publication at Fowler's website.

</comment><comment><USER27> "Check for no/default passwords for databases especially MongoDB & Redis. BTW MongoDB sucks, avoid it."

Come on, you're better than this. What the fuck.

</comment><comment><USER28> The following PDF focuses on just one specific aspect of security: cryptography, but deserves a mention nonetheless. Configuring various services such that insecure mechanisms are not used is not exactly a trivial task.

[https://bettercrypto.org/static/applied-crypto- hardening.pdf](https://bettercrypto.org/static/applied-crypto-hardening.pdf)

Edit: GitHub repo at [https://github.com/BetterCrypto/Applied-Crypto- Hardening](https://github.com/BetterCrypto/Applied-Crypto-Hardening)

</comment><comment><USER29> The guide seems to have reasonable technical measures. I would like to see more discussion of risk, both in terms of what is being protected, and of who might be trying to attack. For example, you might wish to be more careful when developing a bitcoin wallet than when tracking baseball scores.

Shameless plug: I've been working on a somewhat less practical guide to software development security practices [1]. Even more shameless plug: I'm currently running a survey of security practice use in software development [2], and would welcome participants who work on open source projects.

[1] [http://pjmorris.github.io/Security-Practices-Evaluation- Fram...](http://pjmorris.github.io/Security-Practices-Evaluation-Framework)

[2] [https://ncsu.qualtrics.com//SE/?SID=SV_1HdQOa2lfX57vkF](https://ncsu.qualtrics.com//SE/?SID=SV_1HdQOa2lfX57vkF)

</comment><comment><USER30> Please excuse me if this comes across as anything other than constructive criticism, but I don't believe _checklists_ should be used to guide web developers to build secure software.

My reason for this belief is that, in my experience, it engenders tunnel vision and what I appropriately refer to as a "checklist mentality". There are developers who believe, "We're immune to the items on the OWASP Top 10, so we're secure," when there are entire classes of vulnerabilities that applications can be vulnerable to (say: using a weak and predictable PRNG for their password reset tokens) that isn't adequately described by the OWASP Top 10.

An alternative approach that I feel is more helpful is to organize insecurity into a taxonomy.

      * Code/data confusion
        * SQL Injection
        * Local/Remote File Inclusion
        * Cross-Site Scripting (XSS)
        * LDAP Injection
        * XPath Injection
        * Several memory corruption vulnerabilities
      * Logic Errors
        * Confused deputies
        * CSRF
        * Failure to enforce access controls
      * Operating Environment
        * Using software with known vulnerabilities
        * Using HTTP instead of HTTPS
      * Cryptography flaws
        * Yes, this deserves a category of its own
        * Chosen-plaintext attacks
        * Chosen-ciphertext attacks
        * Side-channel cryptanalysis
        * Hash collision vulnerabilities (e.g. length-extension)
        * Weak/predictable random values

You can further break down into more specific instances.

There are three types of XSS (stored, reflective, DOM-based). There are blind SQL injection techniques worth studying too. But the underlying problem that makes these vulnerabilities possible is simple: User-provided data is being treated as code. Any technology that prevents this confusion will greatly improve security.

For example: SQL injection is neutered by using prepared statements. You might one day forget to manually escape a single input (and it only takes one to be game over), but if user data is always passed separately from the query string (i.e. you never concatenate), there's no opportunity to make this mistake. There were also corner-case escaping bypass attacks (usually involving Unicode) that you might not be vulnerable to. With prepared statements, these clever multibyte character tricks accomplish nothing. The query string is already in the database server before your user's parameters are sent.

I believe teaching developers to think in terms of taxonomy (very general to very specific) will result in a greater understanding of software security and reduce the incidence of vulnerable code.

I've written about this before, in case anyone wants to link to something besides an HN comment: [https://paragonie.com/blog/2015/08/gentle- introduction-appli...](https://paragonie.com/blog/2015/08/gentle-introduction- application-security)

\---

EDIT: Opened an issue: [https://github.com/FallibleInc/security-guide-for- developers...](https://github.com/FallibleInc/security-guide-for- developers/issues/14)

<comment><USER31> What you're referring to is the difference between "quality checking", which is the act of checking a product meets acceptance criteria after you've finished building it, and "quality assurance", which is act of putting in processes to guarantee a product is of sufficient quality that you use throughout the build process. A lot of people believe they're doing QA when really they're only doing QC. Both are important.

<comment><USER32> Interesting point. We make the same in high-security INFOSEC where one must differentiate between adding security "features" and "assurance." The features are things like trusted boot, kernel/user separation, crypto protocols, and so on. The assurance... often missing... are activities that ensure those features are built securely & provide evidence of that to 3rd parties.

Common Criteria's EAL's provide an interesting set of assurance activities with descriptions of the increments:

[https://web.archive.org/web/20130718103347/http://cygnacom.c...](https://web.archive.org/web/20130718103347/http://cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM)

</comment></comment></comment><comment><USER33> The first thing jumped out is:

 _Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for you)_

A better approach would be recommending storing password with password-based key derivation functions (recommendation: scrypt or bcrypt).

I don't want to start the whole debate of scrypt vs bcrypt, GPU vs FPGA here (not qualified and we keep repeating the conversation every time the vs is on the table).

-

 _When parsing Signup /Login input, sanitize for javascript://, data://, CRLF characters._

Not familiar with why only "signup / login" input.

-

 _Serially iterable resource id should be avoided. Use /me/orders instead of /user/37153/orders. This acts as a sanity check in case you forgot to check for authorization token._

Had to re-think twice. A stronger argument in favor of /me/orders over /user/37153/orders is to avoid enumeration attack.

-

 _Any upload feature should sanitize the filename provided by the user._

I like this tip very much, but if the requirement is to keep the filename (think DropBox), you should sanitize filename before storing in the database.

-

 _Add CSRF header to prevent cross site request forgery._

I don't believe there is a standard header to do this. I had to look up "csrf header". Correct me if I am wrong. I think this is framework specific (if and only if framework supports it). A better recommendation would be to enable CSRF protection and consult with the framework you use. Most modern frameworks would have CSRF protection built-in (but implementation of CSRF protection varies!!!!!!)

-

 _Add HSTS header to prevent SSL stripping attack._

Simply put, after the user has visited a site with both HTTPS and HSTS header present, user agent like Firefox will honor the header and always attempt to load resource (HTML, JS, CSS) over HTTPS up to the max-age declared in the header. The caveat is you must have visited the HTTPS site first. To actually implement HSTS 100%, you should always redirect user (301) to HTTPS from HTTP.

-

 _Use random CSRF tokens and expose business logic APIs as HTTP POST requests._

Needs clarification on what "business logic" mean and why POST only? What about PUT and PATCH which also allow body to be used? GET I kind of get it.

-

 _If you are small and inexperienced, evaluate using AWS elasticbeanstalk or a PaaS to run your code._

Again, caveat is doing everything right. PaaS and IaaS shields you away from some common mistakes, but not all. You can have a remote code execution on an EC2 with instance profile with full access to the entire VPC and the execution is to remove all instances except the one it is on. Perfect.

-

 _Use a decent provisioning script to create VMs in the cloud._

I have to be a little picky... don't say decent. This is so ambiguous. Did you mean don't reinvent the wheel, or did you mean have a solid engineering process (code review, testing), treating infrastructure automation as software engineering as opposed to an ad-hoc scripting shop.

-

 _Check for no /default passwords for databases especially MongoDB & Redis. BTW MongoDB sucks, avoid it._

I get it. You own the article you write whatever you want. Professionally, if you want someone to take this serious, please don't say that. I have seem people running Oracle just as good as running PostgreSQL. I have heard companies running Apache as successfully as running Nginx. I have heard horror story about Cassandra and success story about Cassandra. MongoDB has a few old mistakes like default to listen on 0.0.0.0 (I heard it is fixed by now?). BTW, I have used and have managed MongoDB, I know some of the pains, but half of that came out of not knowing what the hell I was doing.

-

 _Modify server config to use TLS 1.2 for HTTPS and disable all other schemes. (The tradeoff is good)_

Right tradeoff is to use data and figure out whether or not you need to support legacy systems like those stuck with XP. It may not be critical, but there are companies that do. Use data first before making a decision like this.

-

Four other thoughts.

1\. sanitization of inputs - context matters. The same sanitation technique for HTML doesn't work for XML. That to me is one of the most complicated part in securing application. I am not surprised XSS is still #1 (or at least top 3).

2\. Run code in sandbox mode. Not necessarily Docker or a container, but chroot and restrict application access to the available system resource. That's very important.

3\. Always use reputable framework. As a young adult I love inventing shit, but whatever you invent for your work you are now responsible and the next person picking up your work after you leave is also responsible. So think twice. I am not picking on Node developers because I have seen Python developers doing the same thing - before you import a random package that does a few thing, look at the standard library. Sometimes maintaining a 100-line code yourself vs doing in two lines after an import from the code is written by a random open source lover and is mostly won't be maintained a few years from now is dangerous.

4\. Always upgrade your framework, the toolsets you use, database server you use, etc.

I also think every framework should publish security best practice like [https://docs.djangoproject.com/en/1.9/topics/security/](https://docs.djangoproject.com/en/1.9/topics/security/) and even more details. Security is one of those things I'd wish I had more time to experiment and address. I am no longer active in that space of automation sadly, but from time to time I think about is the fault really on development practice and developers? Can we make everyone's life easier by having strong framework standard? Are we not making tools available? With so many formats being invented every year, we need to think about is our security flaws a result of our own creativity? Unfortunately, we can only hope for the best that we continue to improve security of our framework and we continue to add strong defaults. Also think about security testing. The low hanging fruit like detecting existence of certain security headers is trivial, but fuzzing and getting real good result of vulnerability within an app is extremely custom AND extremely hard to do (so many states, so little knowledge)... you've got very expensive consultants and then very inexpensive but also very general purpose security testing tools that may not do much and can expose common mistakes. One thought would be sampling and either repeating or mimicking user traffic and run simulations. Perhaps some machine learning stuff could help - not sure.

<comment><USER34> Add this to the github repo. It's more useful feedback this way. [https://github.com/FallibleInc/security-guide-for- developers...](https://github.com/FallibleInc/security-guide-for- developers/issues/new)

</comment></comment><comment><USER35> This looks like a great candidate for stack overflow documentation.

<comment><USER36> At first, I didn't know what you mean. Now I know: [http://blog.stackoverflow.com/2016/07/introducing-stack- over...](http://blog.stackoverflow.com/2016/07/introducing-stack-overflow- documentation-beta/?cb=1)

</comment></comment><comment><USER37> I thought this line in the checklist was rather interesting:

> Check for no/default passwords for databases especially MongoDB & Redis. BTW > MongoDB sucks, avoid it.

</comment><comment><USER38> I saw this cool site a while ago: [https://www.hacksplaining.com/lessons](https://www.hacksplaining.com/lessons)

It explains basic vulnerabilities in a very simple way and offers specific ways of avoiding them in different languages.

</comment><comment><USER39> I didn't see any mention on how to secure store the session id, only references to session data. It should be noted that information needs to be securely stored both on the client and server.

</comment><comment><USER40> One thing I totally disagree with: "Set secure, httpOnly cookies."

That is just security theater. It's worse than useless because it makes you think you're more secure, when you haven't prevented attacks are all.

<comment><USER41> This is not security theatre.

Secure => Attacker can't simply inject an img to a non-https version of the site and then intercept the cookie sent by the browser, therefore stealing the session.

HTTP-only => An XSS attack can't steal the session cookie. You're still in big shit, but it's much harder to persist the attack beyond the user closing the browser window.

<comment><USER40> It is security theater. Real attackers don't sit there waiting for a cookie to arrive so they can start to craft their malicious authenticated requests. If they can write a script to steal your cookie, they can also write a script to _execute the actual requests_ right there in your session. And httpOnly cookies do not prevent that at all. Security theater is worse than nothing because you think you're secure from XSS, when you should know better.

<comment><USER41> The "Secure" flag has nothing to do with protecting against XSS. It protects against anyone who can proxy your requests (i.e. when you connect to dodgy wifi) being able to steal your session simply by injecting <img src="[http://yoursite.com">](http://yoursite.com">) into __any non-secure web page your request __. That is a massive security hole and not theatre in the slightest.

The HTTP-only flag is less important but still useful. As I said, you're still in deep shit because of course they can make actual requests and if you think it's all you need to protect you then that's a problem. But there's still a difference between an attack that can be persisted, and one that gets interrupted as soon as the user navigates away from the page.

<comment><USER40> I'm talking only about the httpOnly flag. It's worse than useless because it makes you think that you dodged some kind of bullet, when in fact that same class of attack can still happen: the attacker needs to craft a _script_ to send the cookie to their server, so they might as well have that script execute _the actual requests_ in the context of your authorized session, the same way that they'd do it if _they_ had your cookie. They would write the script ahead of time. No real attacker would sit there at 3 AM making requests because their victim finally activated a script that sent them the cookie. Far more likely, that script is already pre-programmed to do what it needs to do. And if httpOnly cookies didn't exist, the people would care more about sanitizing their Javascript output to prevent XSS, which is the _only_ correct way to prevent this attack.

<comment><USER6> For what it's worth, I agree with the criticisms of HttpOnly, but I still recommend people set it as one of several redundancy measures.

The approach I take these days (for example: when I gave a three-hour tutorial on web app security at DjangoCon this week) is basically to provide combinations of basic mitigations and then more complex/advanced ones, and push people do at least some combination of them, even if they can't do all of them. So to take XSS/CSRF, for example: Django's template system autoescapes variable output by default, and there's a CSRF protection mechanism on by default. Those are the basic easy things, because the advice is just "they're on already, don't turn them off", and just those simple measures will deal with a lot of nastiness for you.

From there I can talk about cookie options, or CSP, or that kinda-sorta-works header that turns on reflection detection in a few browsers, and the pros and cons of each, and recommend people use combinations of them. CSP is my gold- standard recommendation nowadays, and I downplay HttpOnly as not super great, but I'm not going to complain if somebody just watches my talk and does all the things mentioned.

</comment></comment></comment></comment></comment></comment><comment><USER42> My problem with this is another howler for security:

Creating something that already exists.

Although OWASP are not legally mandated, they are the most respected go-to people for this kind of stuff and have much more exposure that your "guide" ever will, it also has a much greater level of review and scrutiny so instead to trying to help by increasing the web noise level and possibly making your own mistakes/ommissions (some of which are mentioned below), why not instead get engaged into the existing community and increase the quality of that if needed?

<comment><USER43> ISTM I've seen some rather trenchant criticism of OWASP's lists in the past. Maybe they've improved, but are they really a "respected go-to"?

<comment><USER6> As a basic starting point OWASP's top-ten list is fine. I use it when doing intro web-security sessions as a structured way to start people thinking about the things that can go wrong, and I like it for that purpose because some of its items are vague enough to allow good open-ended discussions that take people out of the "just check these boxes" mindset and into full-blown paranoia.

I typically follow it up with a rundown of less-obvious things drawn from my experiences with Django, to point out that even when you cover the OWASP checklist-y stuff you still very easily have major issues.</comment></comment></comment>


Ask YC: Android Developer Challenge results are in. Did you win? What did you make? - <AUTHOR>

I didn't make it into the final 50, I guess an app that "makes your notes more useful" isn't uber sexy but I do believe it is something people want.
http://groups.google.com/group/android-challenge/browse_thread/thread/41c9ebfcbffc77c7
One of the things that is really cool is that Google is letting you Opt-In if you want to get contacted by the judges to do consulting work.
Dear participant,
During the past few weeks, 100+ judges around the world reviewed over 1,700 applications.  They were extremely impressed with the diversity and the large number of high quality entries submitted.  It is clear that the number of great applications far exceeds the 50 top scoring applications that will move on to the final round of the Android Developer Challenge.
We regret to inform you that your entry was not among the top 50 submissions.  However, we'd like to bring a couple of interesting opportunities to your attention:
1. Due to the high quality of the submissions many of the judges who are also members of the Open Handset Alliance have showed interest in contacting some of the participants regarding their applications to explore further opportunities.
2. In the near future, we'll be creating an Android Developer Challenge Gallery where you can showcase your application.  We'll be providing more details shortly on how you can participate in this gallery.
If you're interested in either one of these opportunities, please fill out the following form: [url deleted] <comment><USER2> I did a Hecl port for it, and it didn't win. On the other hand, our daughter was born the other day, and she is simply wonderful:

[http://padovachronicles.welton.it/articles/2008/05/08/helen-...](http://padovachronicles.welton.it/articles/2008/05/08/helen- carolina-welton)

It's kind of tough to think of much else at the moment:-)

Besides the Hecl entry, I also got some client work out of it, and although unfortunately that didn't win either, at least I made a bit of money, and there's a chance we'll keep working on the app, which is pretty cool.

<comment><USER3> Congrats! You're in for a lot of fun, and a lot of sleep deprivation.

I noticed a comment beneath the photo that said your days of late night hacking are gone. This is true for the first 6 months, but things do improve on that front.

</comment></comment><comment><USER4> I did one app to translate and say what I type in. I wanted to learned the SDK and use the competition as a learning experience. I wish I had won it. But I was really happy when I saw judges used it until last Wednesday.

Since I know I passed the phase 1 judgment. I am working on porting it to iPhone and see how people want it.

\-- edit -- One lesson I learned from this is PG is right to found Y-combinator startup by number of founders. I did not start early so I did not team with other people in time. I guess a team definitely has better chance to succeed. And by mathematics, if a team can has better probability to win, even each one won much less, but the expectation value will be higher.

</comment><comment><USER5> I used the challenge deadline as a motivator to get me to learn the Android SDK quickly. Downloaded the SDK on the last day and had to submit by midnight. I built a simple twitter clone but instead of seeing what your friends write, you see what people within 10 miles around you write. Needless to say, I didn't win.

<comment><AUTHOR> Likewise, I used it as a deadline to get the RESTful API done. When I AJAXified my app a few weeks later it was dead simple since I had a solid API to write to.

The money would have been nice since I'm bootstrapped, but it would have allowed me to put off launching even longer. So maybe it was a blessing in disguise?

</comment></comment><comment><USER6> We didn't win. I don't think judges did a thorough job - I was monitoring logs on my server and they never tried the advanced features in our app. Those required the backend usage, so I would know and the phone-server connection was the whole point why we made the application in the first place.

Anyway, we have this app on Windows Mobile too, so we will launch it soon-ish to start getting the user feedback.

</comment><comment><USER7> We didn't win too. We submitted port of <http://www.bloove.com> for Android. In allows you to manage your mobile phone via web. If you have Nokia or Sony Ericsson phone you can try it without Android :)

<comment><AUTHOR> When you wrote your app for Nokia and SE did you write for MIDP?

</comment></comment><comment><USER8> No we didnt win either. our project was to have a trip planner which would scour bus and train timetables and present it on Android. This was only for the sydney region by the way. Very primitive (duh).

<http://talkingwombat.com/>

</comment><comment><USER9> Didn't win and I wasn't expecting to either. It would have been a neat app, but I only submitted an early version with pretty limited functionality.</comment>


Is a Project Manager who reads HN too technical? - <AUTHOR>

Just for background, have almost 20 years experience with databases and OS programming in addition to having been a certified (PMP) Project Manager for almost 12 years (some of that is concurrent). While several of my past clients have commented on how much they appreciated that I could balance Business Needs with Technical Solutions, I've had a couple interviews now where I've been told I was "too technical".<p>I find myself wondering if I should just drop any of the technical positions still in my resume, hide my Nexus One (does anyone make a N1 phone case that makes it look like a BlackBerry?), and never admit to having actually written a few games (Android, Flash, Python) in my spare time? Oh and per the subject line, feign total ignorance of Hacker News by saying something like "isn't that sort of like Digg"? <comment><USER2> Try to find a company that is right for you. For example Google requires programming experience, strongly favors CS education and technical background when interviewing for Product Management positions. I'm sure there are other good companies that value technical skills.

</comment><comment><USER3> By too technical, maybe the mean "lacking business knowledge"?

<comment><USER4> This is probably the impression (however wrong) that they're forming. I can't see how any sane company could see technical knowhow as a black mark, but "too technical" is a polite way of indicating they think your skill set is _too narrowly focused_ on the technical aspects of the project.

Instead of downplaying your technical background, maybe you need to add more emphasis and examples of your experience in budgeting, managing stakeholder expectations, leading teams etc.

<comment><AUTHOR> Appreciate the suggestions. Certainly helpful to get a point of view of what they may have meant as well.

Of course, any suggestions on where to look next are appreciated. My current contract goes through the end of the year, but January is a COLD month :-)

Thanks again!</comment></comment></comment>


Ask HN: When designing a personal site, how to get through creative-block? - <AUTHOR> I'm a front-end guy. I've done design here-and-there, but I'm no "designer". Still, I want to design my personal site.
My biggest fear is the blank canvas. Staring at a completely-white Photoshop canvas yields nothing but frustration.
My question is this: as coder, programmer, whatever, how do you get past the initial creative block? <comment><USER2> Go out on the wild and get some inspirations:

Dan Cederholm: <http://simplebits.com>

Spencer Fry: <http://spencerfry.com>

Mike Rundle: <http://flyosity.com>

Sam Brown: <http://sam.brown.tc>

Matt Mullenweg: <http://ma.tt>

Tim Van Damme: <http://maxvoltar.com>

Meagan Fisher: <http://owltastic.com>

Adii Pienaar: <http://adiirockstar.com>

</comment><comment><USER3> Do you already have ideas when you fire up Photoshop? If not, how about some inspiration?

<http://inspirationti.me/>

<http://minimalexhibit.com/>

<http://beautifulpixels.com/>

If you already have several ideas, I recommend getting something down on the canvas as soon as possible. Just start with one element, like a menu for example.

You might also try prototyping with a simple HTML page with embedded styles. This lets you concentrate on one file in your text editor and then move the styles into a stylesheet later.

I also recommend writing some copy before you start designing; that way the content will help dictate the form of the site (e.g., do you need to present a lot of text or only a little?).

</comment><comment><USER4> The best way to design a personal site is go minimal - bare minimum.

But problem is you need a designer to handle white space well. Non-designers fear it (yes the blank canvas is white space)

So just go with one column layout. Use Georgia, seif; typeface stack. Use variations of size and italics to differentiate high-lites. Use shades of gray. Don't make it wider than 1000px.

Bonus Tip: Keep line height of text (css propery: line-height: 1.5em;) to 1.5em and text size to 14px.

If you can pull this one off. You will have a side that even designer will envy.

Inspiration: <http://netspencer.com/> <http://www.kingsidharth.com>

</comment><comment><USER5> Marissa Mayer (Google Head of Locations, formerly Products) touched on this problem in a talk she gave. I vaguely remember, but I believe she talked about how a painter was always overwhelmed by his blank white canvas so he would paint a small stroke on each canvas to start with that. Often times having a start point can help spur you into motion.

One way I like to get started with design is by working on the logo first (which is relatively simple, since its plain text at first), and then continue to build around it until I'm past the block. Hope that helped.

</comment><comment><USER6> Start with content. Don't even make a stylesheet. Just get some content in there with the appropriate HTML tags. Then start a simple stylesheet that makes the content readable. Then you can start actually designing.

Starting from a blank slate is painful, but if you have content to work "around" it's much easier (for me at least). It turns out to be more like molding your design around your content than coming up with a design and then shoving your content into it.

(Note: I'm Nick's coworker, and I know he has plenty of content to start with)

<comment><AUTHOR> Right. I had considered this, but somehow shoved myself into wireframing mode, which turns out to suck just as much as staring at a blank PS canvas.

<comment><USER6> You're a frontend developer. I'm coming to your site for the content, not the design. As long as it's pleasant to read I'm happy. Anything else is just a bonus.

</comment></comment></comment><comment><USER7> You have to come to photoshop with a BIG idea that really excites you. Don't open up photoshop until that idea comes.

Form follows function. But function follows Idea.

The way I see it Photoshop is like the desert part of the process anyway. It's fun designing the site once you have a strong idea leading it.

</comment><comment><USER8> Let yourself experiment for a while. Just put some crap on the page, don't be afraid to throw it all away. Try different styles and have fun. Also it helps to sketch on paper before committing to a screen.</comment>


Show HN: Add web analytics to a Google Doc in 20 seconds - <AUTHOR> http://184.108.40.206/ <comment><USER2> Your URL is just an IP... bold move.

<comment><AUTHOR> when I was desperate for early feedback... :]

</comment></comment><comment><USER3> Wondering how (if) your product differs significantly from docsend (docsend.com) and if you have plans to take this further?

<comment><AUTHOR> So far it seems that people use it in a very different way from docsend. Usually people just put in a Google Form of survey and share the link.

For casual use cases, it's a lot faster to share than using docsend.

</comment></comment><comment><USER4> Not that useful. So it creates another link injecting other js? A bit of security risk for users...

<comment><USER5> I mean, you did just click on a link to an IP.</comment></comment>


Internet of Things security is so bad, there's a search engine for sleeping kids - <AUTHOR> http://arstechnica.com/security/2016/01/how-to-search-the-internet-of-things-for-photos-of-sleeping-babies/ <comment><USER2> I still don't get the Internet of Things.

The mental calculation just doesn't work out for most things. My personal rule of thumb is:

      benefitofmeaccessingXremotely(X) - costofotherpeopleaccesingXremotely(X)*riskofthathappening

Benefits being low for most things, costs high, and risks...uhmm...nah. Only exception I can think of is very limited amounts of sensors (eg. is X on?).

What's the benefit of me turning on a gas stove remotely? Almost none. What's the cost of someone else turning on my gas stove? Really high. How much is the risk? Way too high.

Then there's smart devices, another component of IoT. But how much smarts do we actually want? Screens are nice. Making my shower multi touch isn't (capacitive touch + water = no bueno. Imagine water from hell scenario and no way of turning it off with your wet hands). Fridge compiling shopping lists automatically? Neat. Cheap android tablet that comes with a fridge glued to it? Nah.

The only utility I see is locally connected devices. Using your phone as a remote. That seems handy. To a certain degree, we have that. Extra points if I don't need to download an app for everything, because don't you dare tell me that your blue-tooth on/off switch needs a 15mb .apk. If I gave one about the 14.9mb of branding you're including, I'd download your press kit.

There's some utility in home IoT wudget-thingimabobs, but I'm almost certain we'll mess it up to no end in our excitement. There'll be some legitimately useful products coming from it, but most of it will be utterly cringe worthy in retrospect.

/rant('IoT')

<comment><USER3> I was around when TV remote controls became popular. Couldn't see what was the point of them.

<comment><USER4> I guess what parent meant was that using some "smart" stuff locally (same room, same house, same LAN) can be useful.

To put your example in the perspective : how much useful would it be to operate the TV remote over the internet ? Yeah, it sounds cool that I've set the TV to channel 5, but I'm not there to watch it anyway, so it's kinda useless. Only thing that is now possible is some other people jerking around with the remote.

<comment><USER5> Operating the TV over the internet is useless .. but operating the PVR over the internet could be very handy. And operating the TV over the LAN from a smartphone could be handy: scroll through the EPG without disrupting the current programme.

(I spend an hour this afternoon trying to get tvheadend+Kodi working to do almost exactly this, to replace my Windows Media Center PVR)

<comment><USER6> Operating the PVR over the Internet is already obsolete: with IPTV, you can just "go back" and watch the show. There's no need for each client to record it, when the provider already has a copy and your device can stream it on demand. Both of our largest ISPs here in Portugal already offer this bundled with the TV service.

Same for the EPG: the app offered by my ISP simply downloads it from the web, no need to connect to my TV.

<comment><USER5> It seems everyone else already does it like you say, but the "go back" is usually time-limited. Whereas I still have the 2012 Olympic opening ceremony on my PVR in nice accessible MPEG2-TS format.

</comment></comment></comment></comment></comment></comment><comment><USER7> It's much worse than just passive webcams. Some devices which were never meant to be connected to the internet are out there.

Stoplights? HVAC Systems? Carwashes? Ice Rinks? POWER PLANTS?

Yes!

[https://www.youtube.com/watch?v=5cWck_xcH64](https://www.youtube.com/watch?v=5cWck_xcH64)

EDIT: I looked at his more recent talk from last November ... the situation has not improved

"115 batshit stupid things you can put on the internet in as fast as I can go by Dan Tentler"

[https://www.youtube.com/watch?v=hMtu7vV_HmY](https://www.youtube.com/watch?v=hMtu7vV_HmY)

Featuring Spanish Chicken Controls

<comment><USER8> How about smart TVs? Give it a few years and you'll have hundreds of millions of TVs with a camera on them exposed to the wild.

<comment><USER9> The disturbing thing today about smart TVs in particular is that it's increasingly difficult to buy a TV _without_ those features. Personally, I have no interest in them even without the obvious security and privacy concerns. I want my TV and speakers to be as good as possible at showing pictures and making sounds, and to accept signals from whatever sources I want to use in sensible ways. Everything else is just more cost, more scope for failure, and less future-proofing.

The _really_ disturbing thing about a lot of these IoT devices with sensors and remote communications in the future will be when they no longer rely on an explicit Internet connection being provided via the home network, and instead use some sort of mesh arrangement where they can get online independently and you won't even know about it. At that point, I think robust laws about both disclosure and the ability to opt out will probably be necessary.

<comment><USER10> Have you considered using a PC monitor instead of a TV? Honestly, their biggest feature when used as a TV is their lack of "features".

<comment><USER9> Unfortunately, PC monitors tend to be missing a few _too_ many features that really are basic TV functionality -- remote control, sound, large numbers of switchable inputs (particularly HDMI) on high-end models, etc.

They also tend to be physically smaller but often with a higher native resolution than TV/movie standards, so not the best fit for efficiently showing that kind of content.

<comment><USER11> Everything but size is solvable by building a small PC to use it as TV controller, no?

<comment><USER12> The cost difference of this theoretical setup is now reaching laughable proportions (in time, money, or both)

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I'm not sure how many others share my view but I think that regulation is worth the benefit to security. I have always been very skeptical of the "but it'll hurt innovation" claim. Won't it promote innovation in new approaches for securing low-cost devices? It sure seems nebulous to me, but I am willing to be convinced otherwise.

<comment><USER14> I wholeheartedly disagree about letting regulators have anything to do with technology. It moves too fast and has too many interpretations to be codified into common sense law, leaving just the big pocket corps to write the regulations just like they've already done everywhere else.

How do you define reasonable security practices? If there's PII, what's reasonable then? What's reasonable today OAuth, tokens, 2FA was over the top crazy/impractical/expensive/impossible in 2001. You think there's going to be a committee evolving this crap every month in perpetuity?

On top of that, if actual harm comes to users of these devices as a result of these devices then we already have plenty of consumer laws protecting them. Granted, they're going to have to come up with ways to apply it sometimes and you're going to have to prove it was that device that allowed the harm, but we have it.

I will say this though: I'm mostly okay with laws (whether they exist or not yet) that say that if your negligence or stupidity was the root cause, as a manufacturer of these goods, you are on the hook for a multiplier of damages. There are a lot of companies out there that know they are pushing shit to market in a race to the bottom and then just claim security is hard and they tried their best when clearly, they knew about an 8 year old bug and shipped anyway. I'm that case, I'm okay with hitting them hard.

<comment><USER15> > I'm mostly okay with laws (whether they exist or not yet) that say that if > your negligence or stupidity was the root cause, as a manufacturer of these > goods, you are on the hook for a multiplier of damages.

Such laws won't work, however, without a regulatory framework that ensures that -- for example -- click-through EULAs aren't used to lock customers into sleazy "binding arbitration" agreements that sacrifice their rights in return for permission to use an appliance they bought in good faith.

It may be difficult for regulators to keep up with specific technologies, but _much tougher_ consumer rights protection is _essential_ in order to hold negligent manufacturers responsible, because it's cheaper for the cowboy manufacturers to hire a lawyer to draft some dodgy contract boilerplate than it is for them to hire security experts and ship a safe product.

<comment><USER14> I agree with that. I'm much more in favor of punishing harshly when the mess up happens and could've been avoided but for willful negligence than trying to write a bunch of catch all regulations before we have a problem.

I think, at least in the US, we need much stronger consumer advocacy laws, something with teeth that can't be arbitrated down by a group of expensive lawyers.

We'd have to find a balance though, as we are already way too litigious and we'd be stifling innovation out of fear of getting accused of negligence.

<comment><USER16> I am a technologist; and yet, I am all for stifling innovation with IoT. The folks creating these devices are not qualified to make decisions for themselves or for us.

<comment><USER14> What decisions are they making for you? It's your decision to opt in to their system by buying. As a technologist you have a good idea how to spot the crappy ones that can put you at risk- or would just (rightly) assume that something like an internet connected Elmo is a bad idea. It's the general population that we have to worry about, as they'll be the ones most seriously harmed (identity theft is the thing I worry most about any of this) by these things going awry. They may also not even put things together that some of these devices could be or are internet connected in the first place, where to us it's obvious that there must be network connectivity of some sort.

That being said, let the bad actors fail. Let their names get dragged through the mud, let the big companies sober up after a few too many VTech/Mattel/LG style failures that make the headlines. Let them either back out of the market because this shit is hard to keep secure, let them work with someone who can, or let them triple down and figure it out themselves. We're going to see a lot of failures, but we'll be better for it.

I've connected my own devices around my house (securely), use z-wave, and consumer home automation hubs/hardware, as well as some well known stuff like Nest and Amazon Echo. I don't ever want to go back to NOT having these things.

I've accounted for many of the likely failure points by these very well regarded manufacturers and I've firewalled my network very tightly, among many other things. But damn it, I've seen the future and I don't want to go back. It's too nice, too convenient, and adds too much real value.

It's your decision to buy their goods, no one should be preventing anyone from trying to enter the market just because you get the heebie jeebies or don't see the value. Someone else does- or no one else does and they fold up shop.

<comment><USER16> History has shown us that all the the IoT devices are poorly coded at best and completely un-managed at worst.

It is also assumed that these devices have unfettered internet access. Most of them can do HTTPS. Either you allow it or you don't. How many Barbie dolls have been having inappropriate conversations with children that a human would otherwise be arrested for? How many televisions are feeding audio from families back to a company? How long is this data saved? Who has access to it? When must it be destroyed? What legal protections does anyone have against data abuse? What is deemed data abuse? If it turns out I am being spied on, what binding agreement do I have with the manufacturer and seller that will make them feel pain? Are they obligated to give me more than, "We're sorry. Gosh, we're just so darn sorry."

Sorry, no. These devices need to be recycled before they are ever used.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> 1995: Every object in your home has a clock & it is blinking 12:00

2025: Every object in your home has a IP address & the password is Admin

[https://twitter.com/mcclure111/status/688775402584731649](https://twitter.com/mcclure111/status/688775402584731649)

</comment><comment><USER18> During a review of W3C WoT & ETSI M2M standards I noticed that security is totally ignored in these tech-standardization bodies. The standards leave security as an exercise to the industry and the maker communities (who are not spending money on security until they have an problem). That said, it's also not trivial to implement something that at first sight seems straight-forward like 802.15.4 Security[0][1] without a deep understanding of the security architecture supported by the underlying platform:

[0] [http://www.jwcn.eurasipjournals.com/content/pdf/1687-1499-20...](http://www.jwcn.eurasipjournals.com/content/pdf/1687-1499-2006-093830.pdf) [1] [https://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf](https://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf)

Since the web is now getting "engaged" to the devices with CoAP and other protocols I wanted to create awareness of how bugs can spill over into the real world and do real damage there. If hacked insulin pumps or baby monitors don't scare you enough how about hacking a train? [https://media.ccc.de/v/32c3-7490-the_great_train_cyber_robbe...](https://media.ccc.de/v/32c3-7490-the_great_train_cyber_robbery) ?? (everyone should probably watch this simply because SCADA strangelove guys are crazy and awesome)

Anyway to counteract the usually very "marketing intensive" tone of IoT groups on LinkedIn I decided to start this IoT Security group: [https://www.linkedin.com/groups/4807429](https://www.linkedin.com/groups/4807429) it would be great to see people from _all_ camps (IoT is a combination of 3 silos: 1) embedded, 2) web 3) infosec) actively contributing with technical topics in this group. I will keep it open to posts from marketeers but am heavily policing it for blogspam and remove any posts that are not security related).

Also I have some ideas about hackerspaces ([http://hackerspaces.org/](http://hackerspaces.org/)) which IMO every city should have and support. They're needed to propagate knowledge between these individual camps properly. (my contact details are in my profile in case you are interested to discuss more offline).

</comment><comment><USER19> Most embedded engineer types know nothing about and never think about security. One example I saw once was an FTP server where the auth commands worked but were irrelevant. All commands always worked. It passed the unit tests therefore it was good.

<comment><USER20> I'm not even a developer so I know very little about unit tests but I would assume that in something with an authentication system you would have a unit test that verifies that known invalid credentials don't permit access.

<comment><USER21> It's _extremely_ common to write unit tests that only test success cases but not error cases. It's pretty much a special case of confirmation bias, as illustrated by the classic "2-4-6 task" (implemented here as 2-4-8, but it's the same idea):

[http://www.nytimes.com/interactive/2015/07/03/upshot/a-quick...](http://www.nytimes.com/interactive/2015/07/03/upshot/a-quick- puzzle-to-test-your-problem-solving.html?_r=0)

You're totally right that you should have a unit test that verifies failure with invalid credentials, not just success with valid credentials. But a lot of programmers are not as smart as you are here!

<comment><USER22> I guess my worry is that I don't know what I don't know (regarding security), but I'm pretty sure there are use-cases that haven't even been defined yet (insert favourite Relmsfeld quote here).

<comment><USER21> Security is hard, no doubt, and even careful tests may not turn up all problems. Not testing your negative cases _at all_ is such a basic failure, and an extremely common one too.

</comment></comment></comment></comment></comment><comment><USER23> While I agree this is bad, I think it's a misuse of the term IoT. Webcams have been around since the 90s.

<comment><USER24> The sort of webcams we're describing are very recent. For $50, you can buy a CCTV camera that includes a network interface and a web server. That has only been possible for a few years thanks to cheap smartphone-derived SoCs.

The IoT is turning consumers into inadvertent sysadmins. For the first time in the history of computing, inexpensive consumer products are functioning as servers. These servers are often dreadfully insecure, e.g. internet-accessible root access with a default password.

The market for a $50 IP camera is inherently different to the market for an $800 IP camera.

<comment><USER25> > That has only been possible for a few years...

I had a Linksys WVC11B IP camera like 12 years ago, I don't remember how expensive it was but it was definitely cheap and targeted consumers for home use.

</comment></comment></comment><comment><USER26> well, that was mostly depressing, but i found the part about mudge and the UL- like initiative encouraging:

"Peiter "Mudge" Zatko is a member of the high-profile L0pht hacker group who testified before Congress in 1998, and since he's gone on to head cybersecurity research at the Defense Advanced Research Projects Agency (DARPA) before joining Google in 2013. In June, Zatko announced he was leaving the search giant to form a cybersecurity NGO modelled on Underwriters Laboratories."

and above that, a section about a similar "consumer reports" style rating organization. that was also the first time i'd heard of the group i am the cavalry, which seems like a cool idea (in principle, at least, without really knowing much about the actual group).

and i understand this objection to that sort of approach:

"It's not the same quality problem... UL is about accidental failures in electronics. CyberUL would be about intentional attacks against software. These are unrelated issues. Stopping accidental failures is a solved problem in many fields. Stopping attacks is something nobody has solved in any field. In other words, the UL model of accidents is totally unrelated to the cyber problem of attacks."

it is a very different problem in a lot of ways, but that doesn't mean that an approach similar in spirit or presentation is doomed to failure. and i think it does fit into the broad category of messy consumer information problems that are hard to solve with specific detailed regulation.

</comment><comment><USER27> Brings to mind the Twitter account @internetofshit

[https://twitter.com/internetofshit](https://twitter.com/internetofshit)

</comment><comment><USER28> Isn't it common sense to at least set a randomly generated password as the default one? Especially for something as sensitive as an Internet webcam.

<comment><USER29> > Isn't it common sense to at least set a randomly generated password as the > default one

You're increasing your support cost by a factor of 100 to 500, and that's a very conservative estimation.

<comment><USER30> Boo-fucking-hoo? As things stand these devices are dysfunctional or broken, would you recommend delivering new cars without brakes and brake fluid because that saves you money?

<comment><USER29> > would you recommend delivering new cars without brakes and brake fluid > because that saves you money?

No, I recommend delivering cars with brakes and brake fluid because that saves support costs.

</comment></comment></comment></comment><comment><USER31> I have a Denon receiver with a web interface, which can control everything over HTTP (volume, source selection, firmware, etc). Of course there's no CSRF protection, so anyone could just control my receiver by getting me to visit a page that tried POSTing to 192.168.0.XXX – it would be trivial.</comment>