Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Password-Storage Field Study with Freelance Developers [pdf]

net.cs.uni-bonn.de

Post reply on HN
Print view View original

11–20 of 21 posts

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#11

Post by blotter_paper »

hardwaresofton wrote: post #10
gregmac wrote: post #2

Good summary: https://twitter.com/PwdRsch/status/1103021803503607808 > Researchers asked 43 freelance developers to code the user registration for a web app and assessed how they implemented password storage. 26 devs initially chose to leave passwords as plaintext. > Those devs were then asked to rewrite their code to 'store passwords securely.' Overall here are the methods of password storage chosen by the developer…

I'm curious as to why they only said 3 of 17 used salt -- most bcrypt implementations will automatically generate a random salt (since the salt is visible in the generated hash), and 7 people used bcrypt? Literally bcrypt and you're done (for now).

> only 3 of 17 participants, who used other hash algorithms, implemented salting.

Emphasis added.

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#12

Post by blotter_paper »

ecesena wrote: post #9
penagwin wrote: post #4

Earlier quoted context omitted.

It's insane to me that it's not "common knowledge" to AT LEAST hash the passwords. It's also interesting because 6 used an encryption algorithm, 10 used MD5 which is as good as plaintext nowadays IMO, and 8 used Base64, so even though 24 people thought they "secured it" the passwords are trivial to recover.

To play devil’s advocate, to me plaintext means I want to finish quickly because you haven’t asked and are paying too little, while any solution other than bcrypt/pbkdf2 means I don’t know what I’m doing.

Having once run my own freelance web dev company, I feel very comfortable saying that I would not take a project where I wasn't getting paid enough to bother hashing passwords. That's beyond justification. Either reject the client or protect their users.

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#13

Post by andregumieri »

gravypod wrote: post #7

What was the task they were asked to perform? For most work a contract under 1k isn't going to get you an extremely high quality developer. In finding, planing, negotiating, and implementing a project you accrue a lot of billable overhead time. If you assume it takes.... - 1hr to apply, negotiate, and accept job - 1hr to do job - 1hr to submit and aid in support & integration of code Then at $200 you're making $66/hr…

I understand your point but that also depends on the geographic location of the developer. 66 US Dollars here in Brazil – as well in many other countries – is an excellent rate and you find top notch developers. Even with half of that you would find excellent and experienced developers around here.

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#14

Post by hardwaresofton »

blotter_paper wrote: post #11
hardwaresofton wrote: post #10

Earlier quoted context omitted.

I'm curious as to why they only said 3 of 17 used salt -- most bcrypt implementations will automatically generate a random salt (since the salt is visible in the generated hash), and 7 people used bcrypt? Literally bcrypt and you're done (for now).

> only 3 of 17 participants, who used other hash algorithms, implemented salting. Emphasis added.

ahhh thank you I did not read closely enough

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#15

Post by ben_jones »

penagwin wrote: post #4
gregmac wrote: post #2

Good summary: https://twitter.com/PwdRsch/status/1103021803503607808 > Researchers asked 43 freelance developers to code the user registration for a web app and assessed how they implemented password storage. 26 devs initially chose to leave passwords as plaintext. > Those devs were then asked to rewrite their code to 'store passwords securely.' Overall here are the methods of password storage chosen by the developer…

It's insane to me that it's not "common knowledge" to AT LEAST hash the passwords. It's also interesting because 6 used an encryption algorithm, 10 used MD5 which is as good as plaintext nowadays IMO, and 8 used Base64, so even though 24 people thought they "secured it" the passwords are trivial to recover.

Right? You literally have to go OUT OF YOUR WAY to not be exposed to hasing/salting - every framework does it, most tutorials include it, for most environments its a simple library import/api.

I have to wonder how they sourced their developers. I don't think researchers would be motivated to do much more then post a low bidding ad on craigslist, meaning the quality of the developers will be commiserate.

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#16

Post by woah »

ecesena wrote: post #9
penagwin wrote: post #4

Earlier quoted context omitted.

It's insane to me that it's not "common knowledge" to AT LEAST hash the passwords. It's also interesting because 6 used an encryption algorithm, 10 used MD5 which is as good as plaintext nowadays IMO, and 8 used Base64, so even though 24 people thought they "secured it" the passwords are trivial to recover.

To play devil’s advocate, to me plaintext means I want to finish quickly because you haven’t asked and are paying too little, while any solution other than bcrypt/pbkdf2 means I don’t know what I’m doing.

How much time does it take you to drop in bcrypt?

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#17

Post by penagwin »

thaumasiotes wrote: post #6
penagwin wrote: post #4

Earlier quoted context omitted.

It's insane to me that it's not "common knowledge" to AT LEAST hash the passwords. It's also interesting because 6 used an encryption algorithm, 10 used MD5 which is as good as plaintext nowadays IMO, and 8 used Base64, so even though 24 people thought they "secured it" the passwords are trivial to recover.

MD5 is a little better than plaintext. Difficult passwords are still difficult when you know their MD5 hash. Base64... is actually plaintext; that's much, much worse.

Yeah MD5 is better to a degree, although 5f4dcc3b5aa765d61d8327deb882cf99 is still the most common password (md5 hashed) hehe :P

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#18

Post by Ayesh »

ecesena wrote: post #9
penagwin wrote: post #4

Earlier quoted context omitted.

It's insane to me that it's not "common knowledge" to AT LEAST hash the passwords. It's also interesting because 6 used an encryption algorithm, 10 used MD5 which is as good as plaintext nowadays IMO, and 8 used Base64, so even though 24 people thought they "secured it" the passwords are trivial to recover.

To play devil’s advocate, to me plaintext means I want to finish quickly because you haven’t asked and are paying too little, while any solution other than bcrypt/pbkdf2 means I don’t know what I’m doing.

This should be part of the job, no matter how tight the budget is. Password hashing is quite accessible in almost every language and I can't think of any excuse not to hash passwords.

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#19

Post by Ayesh »

PostOnce wrote: post #3
gregmac wrote: post #2

Good summary: https://twitter.com/PwdRsch/status/1103021803503607808 > Researchers asked 43 freelance developers to code the user registration for a web app and assessed how they implemented password storage. 26 devs initially chose to leave passwords as plaintext. > Those devs were then asked to rewrite their code to 'store passwords securely.' Overall here are the methods of password storage chosen by the developer…

Maybe the segment of in the industry in which the cheapest outsourced devs work, anyway. Their conclusion states as much (hiring more expensive devs on freelancer.com got them more secure solutions): "In addition, we found a significant effect in the freelancers’ acceptance rate between the €100 and €200 conditions for the prompted task and examined the effect of different payment levels on secure coding behavior. We…

I am freelancing on my 10th year now (never set foot in an office to work), and let me tell you hiring people on freelancer.com, no matter how much the budget is, won't end up good.

Fiver and freelancer.com has the worst kind of freelancers in my experience.

Re: A Password-Storage Field Study with Freelance Developers [pdf]

#20

Post by rnotaro »

ben_jones wrote: post #15
penagwin wrote: post #4

Earlier quoted context omitted.

It's insane to me that it's not "common knowledge" to AT LEAST hash the passwords. It's also interesting because 6 used an encryption algorithm, 10 used MD5 which is as good as plaintext nowadays IMO, and 8 used Base64, so even though 24 people thought they "secured it" the passwords are trivial to recover.

Right? You literally have to go OUT OF YOUR WAY to not be exposed to hasing/salting - every framework does it, most tutorials include it, for most environments its a simple library import/api. I have to wonder how they sourced their developers. I don't think researchers would be motivated to do much more then post a low bidding ad on craigslist, meaning the quality of the developers will be commiserate.

It's inside the paper. They used Freelancer.com and gave 100EUR/200EUR to 100 developers. They created a fake company website and asked the devs to completed the sign-up portion of their fake social network because of one of their fake developers resigned recently.

They used 2 tier of payment to see if the payment had an effect on the security of the code.

> Final Study For the final study we recruited freelancers via direct messages. We searched for all freelancers and filtered for the skill “Java.” Unfortunately, Freelancer.com’s search function also returns JavaScript developers or developers where we saw no connection to Java, so we manually pruned out developers whose profile did not include Java skills. Based on our experience in the pre-studies we added two payment levels to our study design (EUR100 and EUR200). We only accepted freelancers’ submissions if they were functional

Post reply on HN