4 ms·

While I agree with you, adding special restrictions on passwords is a way to lose some customers (who can't be bothered or never remember their passwords). So w

by gommm 15y ago

While I agree with you, adding special restrictions on passwords is a way to lose some customers (who can't be bothered or never remember their passwords). So while I know about basic security practices and will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. EDIT: To answer the questions below. Of course, I would not allow people with administrative access to use weak passwords. But if a user uses a weak password and someone gets access to his account, he can't do all that much (save for changing the plan the user pays, which can be easily reversed)... I'm not responsible for users choosing weak password, however I'm responsible for making sure that no user data/passwords and so on is leaked due to security breach. And that's why I use bcrypt to encrypt password, that's also why I outsource the storing of credit card numbers to authorize.net or other companies that are more competent than me, why I secure as much as possible the website. All of this is a matter of trade offs. Currently, the only websites that I manage that have credit card numbers on files for some users sell virtual/digital goods. So, it would be very easy for me to refund a transaction if it was fraudulent (and in my interest to do so to avoid chargebacks anyway). I might have a different view point in different circumstances.

iamdave 15y ago
NO company that puts sales/profits before security of my billing information is a company I'd ever do business with.
- hackinthebochs 15y ago
  How is standard, restricted user password security in any way related to site security (assuming the site is consciously making the tradeoff)?
  - iamdave 15y ago
    That's an exercise with a huge multitude of variables, but at the core, a website that cares more about selling widgets / booking accounts to the point of reducing its depth of defense with user passwords leaves a very sour taste in my mouth.
    - sbov 15y ago
      Most sites out there must leave a sour taste in your mouth then, including Amazon, Netflix, and Newegg.
tansey 15y ago
> will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. This seems incredibly short-sighted, highly unethical, and a breach of the perceived (or possibly legal, IANAL) fiduciary responsibility of an e-commerce site. You are knowingly and willingly risking your customers' sensitive data and, by extension, their financial well-being in order to benefit in the short term. Edit: In response to the above edit, my whole point is simply that if you are trusting your credit card details to a site, then you should be confident in the security of that site. I meant that it appears from all evidence I've seen that a good heuristic is to say that no creation rules implies an insecure site overall. This won't be true for all sites of course, since it's abductive reasoning, but I think in practice it's useful. Another important point I made is that there is no point in saying "I use bcrypt" as a defense here. If you let users choose any password without any checks, they will choose passwords that are short, common, and consequently easy to crack, even if hashed and salted via bcrypt. It may take 1000x longer than if they were encrypted with just a salted MD5, but we're still talking about effectively instantaneous cracking in either case. I'm not sure why everyone thinks I'm overreacting here. If your users cannot see/access their cc info because it's stored securely via some other service then I suppose that is a lot better, since an attacker cannot actually gain access to the credit card data. Still, it just seems wrong to me to be so insecure about user information simply because they don't understand/care about the potential consequences right now.
- hackinthebochs 15y ago
  Don't you think you're overstating it? Assuming privileged accounts require a secure password, what is the risk here except for an individual with a poor password's information? This person is responsible for their own weak password. Putting a weak password warning is about as much responsibility as a site owner has here. Security policies are always a trade-off between securing information and usability. People seem to forget that around here.
  - tansey 15y ago
    And in this case, I am talking specifically about security policies for sites that store credit card information, like specialforces.com did. I do not believe that having no password is an acceptable trade-off in this situation.
biturd 15y ago
I really don't understand why anyone stores CC's. You don't need the number ever again after the initial transaction. Even for reoccurring transactions. Authorize.net needs only the transaction id for a refund, which can't be more than the original transaction or the API kicks back. You can also send in certain commands to their API to mark a user as reoccurring, thereby negating the need to store the CC for future use, let alone storing the CVC. If for some reason you don't want to use authorize.net, use paypal, which also has an API, though no one seems to use it. You don't have to see a single paypal logo, and can use paypal as a raw gateway, leaving the user none the wiser that the transaction is even going through paypal. Paypal is actually a good option to save money if you are a small startup and can't afford the high cost of a merchant account, though those costs are getting lower and simpler as every day passes. I also find their API a little simpler to use that authorize.net. Though I have a nice library for authorize.net that I have tuned over the years to account for the hundreds of possible error codes they may return and how I will handle those cases. Paypal is a little steep on the per transaction fee and the percentage that they take, so if micro sized payments is your game, they may not be ideal. Anything over $5.00 and you should be good. And again, with paypal, just like authorize.net, you don't need to store a credit card number ever. It makes no sense why this is happening. It simply shouldn't be happening. And the certification is a joke. The steps that some of these CC certification companies make you go through weaken security, and are often arbitrary. But what do you do? My HOA charges a $20.00 fee to pay by credit card. This is against the terms of their merchant provider as per VISA's terms and conditions. I have tried to report it 3 times now, and give up in frustration before I ever get close to being transferred to the correct department. My HOA should have their merchant account yanked for that behavior, as should any merchant who mandates a $5.00 minimum purchase rule at the counter. I have taken steps to protect myself by using a unique password for every site, as long as allowed. My defaults are letters, numbers, and symbols, 32 characters in length. The password manager I use will adjust down if the site can't handle the length or characters. Yet I run into sites that mandate a 6 character password of letters only. Ugh. A bank being the 6 character one. My main protection these days is to use gift cards and pre-paid visa cards. Apple screwed my account and I will never trust them with my CC again. Not for security reasons, but because if you ever ask support a question, they seem to think you are reporting a fraud case, and blacklist your CC for life. I had a business card that was shared with 10's of users, all of which now had to create a new Apple ID password, re-enable all iCloud services, and reset a ton of stuff. Solution? $50.00 gift cards for everyone, they can get a new one at any time the old one runs out. No more CC's in Apple's kit ever again. For the rest of the sites, I use pre-paid visa cards that have $100.00 on them. I figure I am OK to get burned on $100.00. If the purchase is any greater, and I need the protection of a real VISA card, I may take the chance, but I will look the site over carefully. This is a lot to ask of your average user, and I consider this the bare minimum attitude that someone should have to online purchasing. Or, just order everything from Amazon and don't do any CC transactions with anyone else. Look at the html source of ATT.com and tell me you trust them with anything at all.

by gommm 15y ago

iamdave 15y ago

NO company that puts sales/profits before security of my billing information is a company I'd ever do business with.

hackinthebochs 15y ago
How is standard, restricted user password security in any way related to site security (assuming the site is consciously making the tradeoff)?
- iamdave 15y ago
  That's an exercise with a huge multitude of variables, but at the core, a website that cares more about selling widgets / booking accounts to the point of reducing its depth of defense with user passwords leaves a very sour taste in my mouth.
  - sbov 15y ago
    Most sites out there must leave a sour taste in your mouth then, including Amazon, Netflix, and Newegg.

tansey 15y ago

> will always store passwords with bcrypt, sanitize user input and not store any purely private data in plaintext, I'm not going to make a decision about password security that might mean losing customers. This seems incredibly short-sighted, highly unethical, and a breach of the perceived (or possibly legal, IANAL) fiduciary responsibility of an e-commerce site. You are knowingly and willingly risking your customers' sensitive data and, by extension, their financial well-being in order to benefit in the short term. Edit: In response to the above edit, my whole point is simply that if you are trusting your credit card details to a site, then you should be confident in the security of that site. I meant that it appears from all evidence I've seen that a good heuristic is to say that no creation rules implies an insecure site overall. This won't be true for all sites of course, since it's abductive reasoning, but I think in practice it's useful. Another important point I made is that there is no point in saying "I use bcrypt" as a defense here. If you let users choose any password without any checks, they will choose passwords that are short, common, and consequently easy to crack, even if hashed and salted via bcrypt. It may take 1000x longer than if they were encrypted with just a salted MD5, but we're still talking about effectively instantaneous cracking in either case. I'm not sure why everyone thinks I'm overreacting here. If your users cannot see/access their cc info because it's stored securely via some other service then I suppose that is a lot better, since an attacker cannot actually gain access to the credit card data. Still, it just seems wrong to me to be so insecure about user information simply because they don't understand/care about the potential consequences right now.

hackinthebochs 15y ago
Don't you think you're overstating it? Assuming privileged accounts require a secure password, what is the risk here except for an individual with a poor password's information? This person is responsible for their own weak password. Putting a weak password warning is about as much responsibility as a site owner has here. Security policies are always a trade-off between securing information and usability. People seem to forget that around here.
- tansey 15y ago
  And in this case, I am talking specifically about security policies for sites that store credit card information, like specialforces.com did. I do not believe that having no password is an acceptable trade-off in this situation.

biturd 15y ago

I really don't understand why anyone stores CC's. You don't need the number ever again after the initial transaction. Even for reoccurring transactions. Authorize.net needs only the transaction id for a refund, which can't be more than the original transaction or the API kicks back. You can also send in certain commands to their API to mark a user as reoccurring, thereby negating the need to store the CC for future use, let alone storing the CVC. If for some reason you don't want to use authorize.net, use paypal, which also has an API, though no one seems to use it. You don't have to see a single paypal logo, and can use paypal as a raw gateway, leaving the user none the wiser that the transaction is even going through paypal. Paypal is actually a good option to save money if you are a small startup and can't afford the high cost of a merchant account, though those costs are getting lower and simpler as every day passes. I also find their API a little simpler to use that authorize.net. Though I have a nice library for authorize.net that I have tuned over the years to account for the hundreds of possible error codes they may return and how I will handle those cases. Paypal is a little steep on the per transaction fee and the percentage that they take, so if micro sized payments is your game, they may not be ideal. Anything over $5.00 and you should be good. And again, with paypal, just like authorize.net, you don't need to store a credit card number ever. It makes no sense why this is happening. It simply shouldn't be happening. And the certification is a joke. The steps that some of these CC certification companies make you go through weaken security, and are often arbitrary. But what do you do? My HOA charges a $20.00 fee to pay by credit card. This is against the terms of their merchant provider as per VISA's terms and conditions. I have tried to report it 3 times now, and give up in frustration before I ever get close to being transferred to the correct department. My HOA should have their merchant account yanked for that behavior, as should any merchant who mandates a $5.00 minimum purchase rule at the counter. I have taken steps to protect myself by using a unique password for every site, as long as allowed. My defaults are letters, numbers, and symbols, 32 characters in length. The password manager I use will adjust down if the site can't handle the length or characters. Yet I run into sites that mandate a 6 character password of letters only. Ugh. A bank being the 6 character one. My main protection these days is to use gift cards and pre-paid visa cards. Apple screwed my account and I will never trust them with my CC again. Not for security reasons, but because if you ever ask support a question, they seem to think you are reporting a fraud case, and blacklist your CC for life. I had a business card that was shared with 10's of users, all of which now had to create a new Apple ID password, re-enable all iCloud services, and reset a ton of stuff. Solution? $50.00 gift cards for everyone, they can get a new one at any time the old one runs out. No more CC's in Apple's kit ever again. For the rest of the sites, I use pre-paid visa cards that have $100.00 on them. I figure I am OK to get burned on $100.00. If the purchase is any greater, and I need the protection of a real VISA card, I may take the chance, but I will look the site over carefully. This is a lot to ask of your average user, and I consider this the bare minimum attitude that someone should have to online purchasing. Or, just order everything from Amazon and don't do any CC transactions with anyone else. Look at the html source of ATT.com and tell me you trust them with anything at all.