Let me say up front that I'm not particularly asking for advice here, more just whining out loud. Because where I have questions, I think I know the answers to those questions and the answers are unpleasant.So DNA Lounge has an online store, where we sell tickets to all of our events (we sell a lot of those), and a tiny amount of physical merch (like, a handful of shipments a month).
The store is a giant pile of PHP code that started out as the online store for Unspun Records in like 1997 or something. John and I have been beating on this pile of shit ever since, and we've made it pretty secure, but it's still a pile of shit and every time I have to touch it, part of me dies inside.
But we operate our own store because giving a percentage of your sales to someone else just to process checkouts for you is a sucker move.
It's a pile of shit, but it's our pile of shit.
Anyway, our checkout page is pretty damned simple: calendar event page → put a ticket in your cart → checkout → enter CC, email, billing address → receive candy.
It doesn't do all kinds of jQuery alpha-fades and slide things around on you, like you uppity kids enjoy so much these days, but it works and it's easy to understand.
But wouldn't it be nice if we had the option to save all of that for you, and not make you enter your card and addresses every time? Yeah, it would. Fun fact: internally, Amazon used to refer to the "one click checkout" button as "The Money Vacuum".
So, you know what I don't want to do? Write a login and user management system. Because it needs, at a bare minimum to be useful in this modern world: create/edit saved CC, shipping and billing addresses, email; verify email addresses any time they change; change passwords; emailed password reset tokens; login throttling; log in with Facebook; prompt for all the extra info that Facebook doesn't provide; oh, and the knowledge that the Facebook API gets rewritten from scratch every two years.
I mean, none of that is rocket surgery, but man, I really just don't wanna.
So about a year ago, someone suggested "PHP-Login" as something that might be relatively small and easy to integrate with our existing pile of shit. I looked at it for a minute, and the feature list sounded pretty nice, but the thought of digging through someone else's PHP code and deciding if I thought it was secure enough to trust my own store with it sounded really unpleasant, so I left it on my todo list and ignored it for another year.
Well the other day I came back to it for a second look, and guess what? In true Open Sores style, since the last time I looked at this project, it has been rewritten from scratch! You didn't see that coming, did you? Yeah. You did. You really did. So now it's called "Huge", which is about the least confidence-inspiring name imaginable.
So I'm reading through the README, hoping against hope that what I read will let me convince myself that this sounds like something I could trust, and these are the gems that jump out at me from that reading:
It is littered with smilies. I know I'm just an unfrozen caveman, but that's like dotting your eyes with hearts on a resumé.
With a straight face, and no emoticon, this piece of security software suggests that you install it by doing
"wget | sudo sh". I'm just gonna leave this here:
Documentation
A real documentation is in the making. Until then, please have a look at the code and use your IDE's code completion features to get an idea how things work, it's quite obvious when you look at the controller files, the model files and how data is shown in the view files. A big sorry that there's no documentation yet, but time is rare :)
Hopefully a real grammar is also making. Smiley not smiley.
Also: "There's no reason to complain (!) about free open-source software."
Uh huh.
So I don't mean to bust on this guy too much, because he's being honest about what this project is: it's someone's Learning Experience. There's nothing wrong with that. Everyone's got to learn somehow, and writing things is the only way to do it. But that makes it a toy, not a product.
And that means the answer to the question of, should anyone use this in production, with actual money on the line, is: "are you insane?"
As learning experiences go, I know I'd trust my learning experience more than someone else's, but like I said, wow, I just really don't wanna. I know it would make my business better, but actually doing the work sounds about as pleasant as a root canal.
I guess what I'm saying here is, everything is terrible.
For someone in Berlin who likely doesn't speak English as their first language, that grammar isn't terrible.
The minute I saw those smileys, I knew that guy had to be german. That said, I don't get why a low single-digit fee for using Shopify or whatever would incentivize anyone to host his own crappy PHP shop in 2015. Nobody does that anymore.
The world looks different when you don't assume there are sugar-daddy VCs sparing you from having to actually balance the books of your business.
Amen.
:|
With the ability of browsers to autofill forms, maybe logins aren't as useful as they used to be? It certainly avoids all the risk of saving credit card data.
I wonder if there has been a user study comparing browser autofilling with user accounts...
Based on the number of mis-typed email addresses and zip codes we see, I can assure you: the vast majority of people do not use auto-fill or password managers.
If you are accepting credit card payments, you are already making the sucker move of letting someone have a cut of sales, just like Uncle Sam takes his cut in taxes when you aren't losing money. And there are some (not profit-oriented) reasons that you might want to pay a premium' for example, Square charges a lot, but doesn't perform credit checks on new customers, avoiding incidental usury. Traditional merchant services (e.g.) will also offer to store your customers cards for them, and absolve you of the formal responsibility if not the reputational damage if they leak. They will also give you a reasonable API for widely varying values of reasonability.
Forget Square, sorry. They want people to use their store instead, but no API for it....
Look at the bright side: if you're not saving CC's and logins, there's less to steal, and you're less a target. Personally, I'm happy typing in name & CC info again vs. yet another login/password (make up a new one!) to keep track of.
Indeed, I'd have my CC number memorized... except it keeps getting stolen from those other e-commerce sites so the bank keeps sending me new ones.
Practically speaking, you can't store credit card information. The certification process is expensive and crazy. I know you're not asking for advice but I'd just implement Stripe Checkout. Lets users Dave cc info without storing it on your servers and their rates as a payment processor are very reasonable. Their API is also very straightforward which is especially refreshing if you've ever dealt with the insanity that usually passes for a payments API.
Yeah, that's sort of what gives me pause about this too, but remember that PCI DSS is an industry-agreed standard, not law. So if your customers are dumb enough to give you their CC info without proof of any sort of external audit, and the CC servicer you work with doesn't turn around and insist that you be audited, you can get away with it. But, you know, you "shouldn't".
(I know this because I have done "professional services" installations for software that purports to aid businesses in the PCI audit process. The one that Splunk sells these days, if you care, although they may've rolled that into their "Enterprise Security" app at this point. I don't work for that employer any longer, nor for Splunk.)
I'd posit that the only people that know what PCI is are people that have worked for a company that went through the process of cretification.
Joe ticketbuyer on DNA louge
i work for a company that sells a Virtual POS service and, at least in Europe, PCI DSS certification is a must if you want to work with mid-sized and bigger partners.
cardholders have NO idea of what it is but certification is such a pain in the ass and acquirers charge you with such higher fees that it is an actual advantage when you're selling a POS solution.
Yeah, this. 2.9% processing fee is probably a rounding error off from what you're paying already to whomever is running your cards, and you can use their checkout if you want, or roll it into your own with minimal fuss (real, actual documentation and a great API, as Jay said).
And you don't ever have to store anyone's credit card data. Stripe's API will return a token that you can use to reference the credit card data stored on Stripe's servers, so you can just stash that in your DB next to the user's account and cross of a portion of the unfun....
User accounts, though, are even less fun than payments, I think. I can't vouch for any one toolkit in particular, which makes me useless to you, but this is slightly more likely to be useful than Huge: http://phptrends.com/category/56
How can you dismiss 2.9% without knowing how much they make?
On the one hand, 2.9% is either an insignificant rounding error.
On the other, it's a contractor fee for implementing a decent, secure, NIH solution.
2.9% is what Stripe charges to process credit cards on anyone's behalf. If Jamie were going from 0 to 2.9%, that would not be as easily dismissible. But since he's already taking credit cards, and every credit card processor charges for this, I would be astonished to find out that his current implementation was costing him less than 2.5%. It's more likely that he's already paying whomever 2.9%, when switching to Stripe would mean no appreciable change in what amount he ends up with, but gives access to their API and checkout flow and the various other niceties (not least of which is never ever having to store a credit card number himself).
So, the answer is, you don't know how much Jamie's currently makes.
Stripe charges 2.9% plus 30 cents. Most credit card processors charge around 1.9% on average (Mastercard is the big culprit about that number being so high.) You can keep calling 1% a rounding error, just don't expect a business owner feel the same.
Also, I don't know how much Jamie pays on credit card processing, but I guess he already did his homework.
No, it wouldn't. At least, not for your customers.
I mean, I can see what you're getting at. I can see why it's nice to use it at Amazon: they sell a zillion things, and I'm gonna be there a lot. But if I'm buying tickets at DNA, I'm not there as often as I'm at Amazon. I can type in my address and CC on occasion, it's super easy, I have that stuff memorized by now and can do it anywhere.
If you want me to create a login, then that's another login I'm gonna have to make up and save in a password manager. And then I worry about why (and how well) you're gonna store my address and CC info. And then the next time I want to buy from your shop, instead of the low-friction "oh yeah here's my address and my CC#", it turns into, "ugh, I gotta open up my password manager, find DNA, copypaste my email and password.."
If you want user accounts because you think it'll make things easier on you (marketing, correct address info, etc), then be honest with yourself about that. Is it worth becoming a more tempting hack target for that? But don't believe it'll be easier on your customers. It's just one more account to make on top of a pile of other accounts, and they might not want to make one more. You can lose as many sales as you'd gain.
I think you just said "my password manager sucks".
I personally have saved account info on TicketBastard, TicketWeb, TicketFly, and probably others that I can't remember right now, and it definitely saves me time at checkout. Sure, maybe I'm not typical, but on the other hand, all of those businesses, who do a lot more ticket volume than we do, made the decision that having user accounts was worth their effort.
That's kinda what I heard, too. My password manager requires me to type in the master password (duh) and then suddenly any from I've used more than once is automatically filled in. And if I'm too lazy to even think of a new username and password, it'll do it for me.
Sounds like this guys 'password manager' is more like a 'spreadsheet with all my personal info in it'.
I recently bought tickets to 2/3 days of a 3-day festival. The first day I missed out on because they sold out whilst I typed my CC details in. (this is after the 'you are front of the queue' and 'these tickets will be held for you for x minutes' lies). I learned for the other two days.
(And "Wire" were amongst the highlights of the Festival)
And I would certainly not make accounts mandatory. You'd still be able to use it the same way as today.
I always choose not to make an account at checkout, if I can. All my shit's memorized, and I really don't mind typing it in.
I thought about memorizing my credit card numbers, but my bank will occasionally surprise me by sending me a brand new credit card with a brand new number on it through the mail, and happily inform me that activating it will deactivate my old one.
Easier to just store all that crap in a password manager.
Good show.
For me, whether or not a shop makes me create an account is a strong factor in my deciding I want to do my shopping elsewhere.
Having seen numerous websites and mobile apps completely redesign themselves every few months, I don't think it's accurate to say that CADT is an open-source problem. How many times has OSX rewritten the printer preferences dialog by now?
Also, #NotAllOSSProjects, because I work on a 13+ year-old codebase that has never been totally rewritten.
A quick five minute perusal of the codebase has some eyebrow-raising things like:
// clean the input, strip usernames longer than 64 chars (maybe fix this ?)
$new_user_name = substr(strip_tags($new_user_name), 0, 64);
and:
// generate random hash for email verification (40 char string)
$user_activation_hash = sha1(uniqid(mt_rand(), true));
The PHP documentation says of
uniqid, "This function does not create random nor unpredictable strings. This function must not be used for security purposes." On top of that, mersinne twister isn't a secure PRNG. For the sake of generating hashes, I mean... I guess, but why not just call into OpenSSL's PRNG, which is available from PHP? I'm not too enthusiastic about the correctness of this code...That code is just for generating a nonce to stick in the url in a verification email. It doesn't need to be cryptographically secure in any fashion, just something not trivially guessable. Part of security involves knowing what to secure and what you can leave be.
Mind you I'm not saying there aren't other facepalmworthy fuckups in the code, especially given the rundown above...
kaniini: for years, the PHP documentation actually recommended uniqid as being "extremely difficult to predict". (Note that the old page contains a code sample which is very similar to the one used in Huge.)
That's not that surprising; lots of projects have asserted their homegrown stuff as being secure when it probably wasn't, and then later backpedaled on it when it was shown to be otherwise.
And this is why I hoped that Mozilla Persona would get support. Because then I wouldn't have to store more than an email address.
Sadly, they seem to have completely failed to get anyone else to go along with it.
That ship sailed the day they decided to reuse the name from the hugely front-and-centre theming engine called "personas" they had/have.
The question I have is how does having to enter your login and password any easier then entering a credit card number? I never lose my credit cards, but pretty much half the time I enter a password I have to use the "I forgot my password" feature.
That said, I'm guessing your customers tend to buy tickets often or at least more often then I use PayPal or eBay.
A rule of thumb for web login system assessments: if they use scrypt, bcrypt or PBKDF2 to store passwords, they might be worth your time auditing their code. If not, amateur hour. Bonus points for documenting how to tune the work rate.
While I like the spirit of your comment, and it may well be Jamie's best option in the circumstances, I feel duty bound to say this:
Passwords suck. Shared secrets are a crappy security choice, and storing those secrets in a person's working memory is a joke solution that should never have seen practical implementation. Jamie is closer to the Right Thing™ with "login with Facebook" despite the fact that Facebook is clearly awful. Nobody wants any more passwords. The handful of people sophisticated enough to really use a password manager rather than just saying they will, or even keeping a little notebook with the passwords written down (which is what my elderly mother does) are irrelevant in the bigger scheme of things, and PBKDF2 on your site doesn't save you from the user having the same username and password on the next web forum they sign up to. Everything is terrible.
Why doesn't Facebook have email addresses for its users?
I can verify that everything is terrible.