What Craigslist Did Right: User Management Without Usernames or Passwords(jobpoacher.com)
jobpoacher.com
What Craigslist Did Right: User Management Without Usernames or Passwords
https://jobpoacher.com/blog/blog/2012/02/13/what-craigslist-did-right-user-management-without-passwords/
16 comments
Scribd over-complicating things since they used PDFs to display text.
I just visited their site again, I'm not exactly sure what they are using now, it does look good, but my god is it slow on my low end machine.
I am not surprised to hear they are needlessly complicating session tracking as well.
I just visited their site again, I'm not exactly sure what they are using now, it does look good, but my god is it slow on my low end machine.
I am not surprised to hear they are needlessly complicating session tracking as well.
I've been browsing since forever with JavaScript and cookies disabled and with a middle-man (NoScript in my case) to selectively enable cookies for sites that are worth it, it is no problem.
I cringe using other people's browsers that do not block ads and javascript. Some sites that I thought weren't that bad turn into hideous ad-monsters.
Over the years the web has gone from a peaceful landscape to Times Square.
I cringe using other people's browsers that do not block ads and javascript. Some sites that I thought weren't that bad turn into hideous ad-monsters.
Over the years the web has gone from a peaceful landscape to Times Square.
If it's too complicated with Cookie Monster, I open another browser (my trash browser, I use it for sites requiring Flash).
Craigslist has a big spam problem to deal with; anonymous e-mail based accounts make spamming very easy. They've dealt with this through phone verification -- if you try to post to a high-spam category, or your account is otherwise suspicious looking, you get prompted to enter a phone number and take an automated call or SMS with a code to put in the site. That phone number gets tied to your e-mail and can't be used to authenticate another, so spamming now requires throwaway phone numbers (harder to acquire) instead of throwaway emails.
I haven't made any attempt to test it, but they probably block using VOIP and other non-fixed phone numbers too. There are APIs available to check whether a number is one of those types, so, say, you can't sign up for a bunch of numbers through Twilio and use those to spam Craigslist.
I haven't made any attempt to test it, but they probably block using VOIP and other non-fixed phone numbers too. There are APIs available to check whether a number is one of those types, so, say, you can't sign up for a bunch of numbers through Twilio and use those to spam Craigslist.
There's a way to get around the phone requirement, too. I've seen this as far back as 2010.
You pay to post a fake job (something unskilled that will get a lot of applications) on a site like Simply Hired, Indeed, etc. Applicants come to your fake careers site. Applicants fill out the application for the non-existent job and are asked to input their phone number to verify their application.
When they input their phone number, the backend of the careers site submits that number to Craigslist. The applicant receives the call from Craigslist which reads them a number. The careers site instructs them to enter the number to confirm their application.
A few days later your site auto-emails the applicant saying that you're sorry, but the position has been filled. They forget about it and no suspicion has been raised.
For the price of posting a single job, you can get hundreds of phone-verified Craigslist accounts working.
You pay to post a fake job (something unskilled that will get a lot of applications) on a site like Simply Hired, Indeed, etc. Applicants come to your fake careers site. Applicants fill out the application for the non-existent job and are asked to input their phone number to verify their application.
When they input their phone number, the backend of the careers site submits that number to Craigslist. The applicant receives the call from Craigslist which reads them a number. The careers site instructs them to enter the number to confirm their application.
A few days later your site auto-emails the applicant saying that you're sorry, but the position has been filled. They forget about it and no suspicion has been raised.
For the price of posting a single job, you can get hundreds of phone-verified Craigslist accounts working.
ive been unable to get Craigslist's phone-token thing to call my VOIP DID without throwig errors. title there and here is misleading, i need a username/pasword to login to both VOIP and EMail accounts to fiddle with all of CL's post-approval stuff. it feels positively mid-90s
Not having a mandatory registration step definitely lowers the entry barrier for new users. Doodle (doodle.com) uses a similar technique for their polls. A user doesn't need to create a login to manage a poll, he just gets an admin URL and he/she can use that to edit/delete/manage the poll later on. Participants, meanwhile, get a different participant URL that does not have the admin options. Their pages are not served over HTTPS though, so I suppose it's not perfectly secure.
I know I'm probably asking a stupid question, but why can't my browser adopt some variation of OAuth and automatically authenticate me everywhere, forever? Imagine if we never had to discuss sign-up forms anymore. Everyone has an identity built into the browser, no questions asked. That's way better thank cookies, and just as transparent.
What am I missing? It would just take one browser (such as Chrome or Firefox) to support it and I think it would take off.
What am I missing? It would just take one browser (such as Chrome or Firefox) to support it and I think it would take off.
it's not quite as transparent, because your browser will prompt you to share your ID with the site whereas cookies just work without the user ever seeing a login form, but yes. browserID is a pretty cool concept and i hope to see it take off.
"Ask rails developer how to do authentication, and you’re likely going to hear 'devise' or 'authlogic'. These are great solutions for most use cases."
I like that the author thought through what the minimum amount of code needed would be to get the job done for his specific case. However with recent improvements to Rails, Authlogic & Devise are usually overkill even if you are going the standard route. It's easier than you think to roll your own, and you'll end up with a similar amount of code. Here's a good post summing it up: http://www.farbeyondprogramming.com/2011/05/63-rails-user-au...
I like that the author thought through what the minimum amount of code needed would be to get the job done for his specific case. However with recent improvements to Rails, Authlogic & Devise are usually overkill even if you are going the standard route. It's easier than you think to roll your own, and you'll end up with a similar amount of code. Here's a good post summing it up: http://www.farbeyondprogramming.com/2011/05/63-rails-user-au...
Not to be cynical, because I don't necessarily think there is a "right" answer for this particular application, but I don't see a huge advantage in doing this over a simple registration form with a password.
An email is a unique field anyway, so when you say that "nobody likes creating a new username and password for a website" you are making the process sound more complicated than it really is. For the case of this site, the only difference is whether or not a password is required to log in. Additionally, should you want to add user-specific functionality later that persists across sessions, you will have to add an authentication system.
Again, that's not to say that this method is right or wrong, but I myself have started down the road of maintaining sessions with cookies instead of full-blown authentication, and every time I have ended up going back to authentication because I always end up deciding that the benefits outweigh the drawbacks.
An email is a unique field anyway, so when you say that "nobody likes creating a new username and password for a website" you are making the process sound more complicated than it really is. For the case of this site, the only difference is whether or not a password is required to log in. Additionally, should you want to add user-specific functionality later that persists across sessions, you will have to add an authentication system.
Again, that's not to say that this method is right or wrong, but I myself have started down the road of maintaining sessions with cookies instead of full-blown authentication, and every time I have ended up going back to authentication because I always end up deciding that the benefits outweigh the drawbacks.
This looks wide open to csrf attacks.
Another site can post a form on behalf of a user automatically, and the cookies for job poacher will be sent. Meaning that a malicious site can take actions on behalf of a logged in user.
Perhaps their solution is more complicated than they let on, but I doubt it given it's "20 lines of code".
Another site can post a form on behalf of a user automatically, and the cookies for job poacher will be sent. Meaning that a malicious site can take actions on behalf of a logged in user.
Perhaps their solution is more complicated than they let on, but I doubt it given it's "20 lines of code".
This is why you check for tokens in the form that correspond to the current user's session. Rails does this for you automatically.
that has nothing to do with using a password or not to authenticate. anti-forgery tokens are the answer to csrf.
I’m not too familiar with Rails (and this is unrelated to the point of the article), but is this code vulnerable to a session fixation attack (https://www.owasp.org/index.php/Session_fixation)?
I notice that it doesn't destroy the session when you log in/out, just changes a session variable.
I notice that it doesn't destroy the session when you log in/out, just changes a session variable.
No; session fixation requires that the attacker gain access to a session id and pass that on to the user. Rails doesn't use session ids by default. All session data is stored in the client cookie, and is verified with a cryptographic hash. If you can steal the cookie, you win, but that's much harder than session fixation.
the thing about https and your employer.... be very aware that on managed workstations, its trivial to intercept https traffic by pushing out a new trusted ca across the company....
assume your employer can see everything you are doing.
what are you doing job hunting on his dime anyway? uncool.
assume your employer can see everything you are doing.
what are you doing job hunting on his dime anyway? uncool.
Therefore when job hunting never use the browser your employer installed on your computer, always use one you installed yourself. Did I say job hunting? I meant checking your bank balance. Although if you don't trust your employer this much maybe you SHOULD be job hunting. Besides, they can always install a key logger.
In our rails model, we generate a SHA1 string based off of the user’s email address, the random obfuscated email address that we generate, and a salt.
Why people still do this, when HMAC is even easier to use? http://www.ruby-doc.org/stdlib-1.9.3/libdoc/digest/rdoc/Dige...
It also seems like the salt here is not actually a salt, but a secret key.
Edit:
Why people still do this, when HMAC is even easier to use? http://www.ruby-doc.org/stdlib-1.9.3/libdoc/digest/rdoc/Dige...
It also seems like the salt here is not actually a salt, but a secret key.
Edit:
@listing = Listing.find_by_confirmation_code(params[:code])
My website does this too - example: http://textbookcentral.com.au/26/university-of-new-south-wal...
It sends you a confirmation email which you must click on before your post is broadcast to other buyers and sellers.
I figured this beats user accounts because students buying / selling users would come here at most once per semester, they are never going to remember their account credentials anyway.
No spammers, yet. (the spammers post without confirming)
It sends you a confirmation email which you must click on before your post is broadcast to other buyers and sellers.
I figured this beats user accounts because students buying / selling users would come here at most once per semester, they are never going to remember their account credentials anyway.
No spammers, yet. (the spammers post without confirming)
This can work if your app is an impersonal one like CraigsList. It doesn't if it's a social one where you want people to use an username, or their full name to interact with other people.
Good post... but amazing how many rails applications and examples, don't use SecureRandom or ActiveSupport::SecureRandom
This was a really useful post. Thank you.
This is a good solution where people will use a site infrequently.
This is a good solution where people will use a site infrequently.
I think Craigslist's authentication scheme only works if your users don't need to be logged in very often. Otherwise it's a royal pain.
The nice thing about Craigslist's authentication is that it allows casual users to post easily (and anonymously) without having to create an account, but they also allow you to create an account if you plan to use the service often.
They are able to account for both types of people.
They are able to account for both types of people.
It seems if you later decide to make an account, it aggregates all your posts into a useful summary pane.
I was able to sell a couple of things using Craiglist. I was surprised at how easy and smooth it went.
I was able to sell a couple of things using Craiglist. I was surprised at how easy and smooth it went.
Good point I wasn't thinking about the account creation part when I read the article. I have only posted once on CL and didn't create an account.
I use Firefox + Cookie Monster, which allows me to enable temporary cookies for the sites that I'm just browsing and permanent cookies for my webmail and social networking sites.
The only site which sits in the middle of these -- it breaks without cookies but I don't use it enough to justify cookies -- is scribd. It's gotten to the point where I actively cringe whenever I see the word "scribd" anywhere. Basically they show you a perfectly working presentation for about ten seconds and then suddenly send you on an infinite redirect loop which simply says "optimizing your Scribd experience", and once you temporarily enable cookies they dump you on an index page having nothing to do with the presentation you just started reading.
I might shift them to a "store cookies permanently" exception, but it still bugs me. You should never require cookies for content which can be read by solely clicking "Temporarily Allow Cookies for this domain name." Cookies don't do anything if you delete them immediately after the transaction is over. (I am looking especially at you, New York Times: you are guilty, guilty, guilty of this.)