> and I know for a fact 90% of the sites I personally sign up to online also follow that same process.
This is a totally legit response. After all if something goes wrong they must have followed "best practices". No reasonable person would expect them to do more.
And it's true (if you only consider the needs of the business). This is a solid strategy for getting lawsuits dismissed. I've seen it in physical security too [+]. It only took one investment bank to put badge-checking turnstiles in place and then they all had to do it. That stuck with banks only for a while until one more conventional business did it...and now I was at Twitch the other day and they have it.
Of course who's missing here is the customer. But the customer's needs aren't paramount: the business's are -- and more specifically the manager who has to spend the money on security. If they have put in just enough that they won't get fired when it fucks up, and if they saved money and effort in the process: WIN!
[+] my favorite physical security story is old, so at the end: when leaving Intel's Santa Clara fab in the 1990s you would have to hand over your briefcase for inspection to make sure you weren't leaving with any Intel documents. They didn't care if you had floppy disks. Why? Because this was a defense against shareholder lawsuits and "what else could the guards do?" This is where I learned the explanation above: once anyone in the industry increased plant security they all would have to, which nobody wanted. So LCD was the name of the game.
1. I don't really give a shit either way when I encounter one but as a businessman I am against them as something I should have to pay for. My points were twofold:
A> there's a games theory/cartel issue around "best practices", and you basically have no liability if you provide the "standard of care". This is true in security practices, medicine, etc.
And B> there is often an incentive mismatch between the implementor of a process and those subject to it which biases aggressively down or up, against gradualism. The most visible extreme is TSA in which the risk of letting a shoe bomber is extremely high (i.e. the decision maker would lose their job if it actually happened) while the cost is borne by all the miserable travelers who, realistically, fare essentially epsilon risk of actually encountering such a device.
With regards to your point B, I'm happy to remove my shoes if it reduces my chances of being killed in a terror attack from (making up numbers) 1/1M to 1/1.05M. It's just that it's unclear whether the TSA's screening methods are effective, and/or optimally-effective, and/or optimally-effective while minimizing passenger inconvenience. (They're probably at least somewhat effective, at least as a psychological deterrent, seeing as there hasn't been a successful terror attack on a US airplane since 9/11).
Correlation does not equal causation. There also have been no successful terror attacks on a US airplane since they 1) Implemented reinforced cockpit doors, 2) stopped allowing people to line up for the forward bathroom, 3) added air marshals to the planes, 4) implemented TSA pre-check.
So we have no idea, if any of these, has actually improved security. It's possible that just no one has tried since 9/11 because there was no reason to.
And "probably" doesn't equal "certainly." It's certainly within the realm of possibility the TSA's screening methods are ineffective.[1] But given the 16-year perfect record[2] in preventing not only hijackings but also bombings (which cockpit doors, air marshals and bathroom line policies are powerless to prevent), it's only reasonable to say their methods probably have some effectiveness to them, which (repeating myself here) is not to say they're the best possible screening methods. And there are most certainly people who think there's "reason to" attack US airplanes, hence the foiled incidents (shoe bomber, liquid bomb plot, underwear bomber) that engendered the more annoying TSA screening policies.
[1] Although I'd say the more likely problem is that the personnel doing the screenings may be ineffective, rather than the fairly-standard-worldwide screening methods they use.
[2] Which in all honesty is quite impressive. Immediately after 9/11 I'd never have guessed we'd go 16 years not only without another 9/11-scale attack, but no attacks on airplanes at all. It's not yet as good as Israeli airport security's 41-year perfect record, but it's nothing to sneeze at.
Who knows if it's untrue? Although it almost certainly is. What's "legit" is the point "lots of other people do it so why should I go to any greater effort? And anyway I don't actually give a shit about my employer's customers."
(I was being sarcastic about "legit" -- it's only legit from the selfish POV of the web admin)
Sorry, I grew up in a culture in which being so explicit was rude, while being barely-elliptically witty is the normal mode of discourse. I sometimes forget.
But almost as bad: websites that insist on over-elaborate security measures for trivial stuff. Take a bow, HM Revenue & Customs:
> You’ve got a new message from HMRC
> Dear Fred
> You have a new message from HMRC about Self Assessment.
> To view it, sign in to your HMRC online account. For security reasons, we have not included a link with this email.
> Why you got this email
> You chose to get paperless notifications instead of letters by post. This means we send you an email to let you know you have a new message in your account.
> From HMRC Self Assessment
And HMRC have mandatory 2FA. So to read the spam they've sent me - and it is pretty much spam, it says "you need to do your self-assessment before next January", I know that already - I need to go through the rigmarole of entering my Government Gateway number, which I don't remember but starts with a 4 or something and hopefully that will be enough for Chrome to autofill it, then authing with my mobile phone. Which I think I left upstairs or something. Wait while I ring it with the landline to find where it is.
Seriously, I might just go back to getting letters by post.
Edit: No. My Government Gateway number which starts with a 4 is my company one. My Self-Assessment login appears to be a different number.
People elsewhere in the world, whenever anyone tells you that the UK Government Digital Service is a beacon of usability and good practice, please don't believe them.
People elsewhere in the world: whatever anybody tells you when they're crapping on the UK Government Digital Service, make sure they're not using HMRC as an example.
Famously HMRC resists everything GDS has ever tried to do, and after GDS built a entire system for secure gov ID login which is deliberately not tied to a single vendor, HMRC refused to use it and instead is building another one, which is locked to a single vendor in perpetuity.
Search "UK GDS HMRC" for a sample of just the most recent bit of tiresome Whitehall infighting.
[Edit: Oh, and -- the identity system that HMRC wants is a replacement for its nearly-20-year-old pre-existing one. This may or may not have anything to do with the fact that it's insecure in a massively corrupt way. http://www.bbc.com/news/technology-38979144 ]
That's so frustrating. The GDS is one of the shining beacons of government tech done right, I was very impressed with their work and team when I lived in London from 2011-2014.
I guess HMRC took one look and said "this not sufficiently bureaucratic for our needs". In general I liked the HMRC much better than the IRS, but I was sort of shocked to receive a paper cheque for my refund as it was the only time I ever saw a check in the UK. They have their ways I guess.
GDS has a great blog[1] which I recommend, and have published a lot of stuff to GitHub too[2]. I never imagined the words 'government' and 'IT' could be used in the same sentence without laughing before learning about this group.
Whenever I read of yet another multi-billion pound failed IT project by SAIC or the like, I always wonder why on earth they didn't just let GDS at it.
One could argue this is actually a good security practice. It's bad to train users that their bank/whoever will be sending them links via email, because then when the user gets a phishing email, they will have no way to tell the difference.
If users can be trained to see "Login to your bank account to see the message", that's much better for their own security.
> It's bad to train users that their bank/whoever will be sending them links via email, because then when the user gets a phishing email, they will have no way to tell the difference.
I got an email using the PayPal template headed "Dear PayPal Customer" once. The copying was so faithful that it preserved the footer at the bottom noting "Communications from PayPal will always address you by your name, never as 'Dear Customer' or similar".
So there can still be ways to tell the difference. Point of interest: would it be more alarming to the PayPal-using public generally if their fake emails omitted that footer, or if the fake emails preserved the footer while still addressing the victim as "dear customer", as happened with mine? You, the phisher, can't avoid having some difference between your email and legitimate email, but you can choose how much and what kind.
I don't mind the login security, but it logs you out after only a couple of minutes of inactivity, clearing the page. Can anyone do anything tax related without spending a few minutes looking at papers or a spreadsheet?
> and hopefully that will be enough for Chrome to autofill it
Doubleclicking text fields or pressing the Down arrow key (with the textbox focused) sometimes produces helpful responses.
If you're just dealing with numbers, though, you only have ten possibilities for the first digit, and actually typing a character is likelier to have higher chances of success.
It's not a message that needs to be delivered securely. It is literally just "you need to fill in your tax return by the same date everyone else in Britain needs to fill in their tax return". That could have been included in the email body with no security implications.
It's basically crying wolf. Next time they have something really important to tell me, I suspect I'll just go "nah, it wasn't important last time, I can't be arsed to spend three minutes logging in" and delete it.
Nowadays every login requires a 2fa with a sms so got to have that phone handy to login. And as a bonus juggle multiple ids if you have a business account too in addition to your personal returns. Pure crap.
Programmer (not me!) manually iterates over user file (passwords plain text natch). If he finds a matching username (format is enforced so dead easy to guess). He sets the auth cookie. THEN he goes looking for the password. You don't have to enter any password. At that point, just hit the back button a couple of times and refresh and BING! You can impersonate anybody on the system. Including the admin because guess what the admin's username is.
This guy is notorious for writing crap like this. But according to the powers that be, he's a 'god'.
I used to work at a life insurance company that had a sessions page for the developers that wasn't locked down at all. If you could get someone's id you could go directly to this page and set your user id to that. Done.
They also had a contest for their agents and the database they used to store all of the entries and information was an access database that happened to be sitting in the public directory for the website to simply serve to anyone who knew to request the database.
Seeing so much "security" makes me realize that a large majority of sites out there are a complete shit show, especially if the companies I worked for / with couldn't get it right and they actually had some money to their name.
Yes, most medium-or-smaller sized companies, including ones in fields that should take security seriously like insurance and lending, will have tons of stuff like this. It shouldn't surprise anyone at this point.
Even large companies depending on how you want to classify one as "large". Back when Palm announced their new phone, the Palm Pre, I was given early developer access on their developer portal. I reported to them multiple security vulnerabilities including one that allowed anyone to change a simple integer in the URL and instantly see everyone's SSN / TIN, payment information, etc. It took them 3 months to fully resolve, too (their first fix was simply changing a GET call to a POST, sigh). They never even disclosed it to anyone despite my pleas (I should have but was still sorta green back then and didn't think it through).
Been there done that. The only thing you didn't mention was that if you do give a wrong password, it calls the logout function. So all tests do work. You can't login with wrong password.
Nope. Just refreshes back to the same page. Sorry, forgot to mention that the logout button doesn't actually DO anything except redirect to the Login page. Auth cookies are still intact.
You
send them your public key in a GET request, and the payload you get
back is the encrypted HTML page. Make sure to pick a big enough key size, or
you might not see the whole thing...
Huh, couple years ago Santander in the UK changed their web layout. No big deal, except that my password wouldn't work anymore - I rang them up, and they said "did you have any special characters in your password? If yes, then they have been removed because the new system does not support special characters. Please use the same password as before, but without special characters".
1) This is one of the largest banks in the UK and they don't accept special characters?
2) If you store my password encrypted(as you should be!), how could you remove any characters from it?
I sent them an official complaint, they replied saying their security is fantastic and there is nothing to worry about, I closed my account a week later.
my (former) bank used social security numbers as user accounts, and lets you reset your password over the phone with nothing more than address and birth date.
They (as seems to be standard) ask you to enter 3 characters in positions of their choosing, so they need plaintext to be able to do that.
It's clearly not as secure as it could be, and it's annoying to work out too - I wish they'd just do normal 2FA. Those plastic keyfobs HSBC use are even worse.
This approach is geared at telephone banking. It means no single employee will learn the entire secret during a call. You generally have a regular password in addition to this step.
How are they more secure than your phone? If by phone you mean SMS, then I agree. But as far as I understand, TOTP (ie Google Authenticator) is pretty secure. But I'm not a security expert.
This is getting into very marginal territory, but attack surface. Your phone is an entire network-capable OS with god-knows what security vulns or backdoors. Those dongles are an air-gapped, often tamper-resistant chip.
For the record, I think services should ideally offer all three options (SMS, TOTP and physical device), since the biggest problem in security is actually getting users to use ANYTHING at all, and something like SMS that offers 99% of the protection in return for easier setup/ease of use is well worth it.
The plastic key fob is totally isolated from any network. If your phone was isolated like this you would need a new phone. Google Authenticator can be cloned if you compromise the device. A plastic key fob that has no input is for all practical purposes impossible to clone and if it's stolen it can be easily revoked.
It's one thing to reject special characters at password change time, that's silly but not massively insecure. It's another thing to modify passwords at rest to delete the special characters. (However, the backend could easily have always been doing that, and the frontend changed from silently deleting what you typed to refusing to accept what you typed.)
It's silly but probably has to do with some percentage of customers not realizing that - and _ aren't the same character or something.
I don't know if it's a good practice or not, but i usually just pick a word to use for all security questions, that's totally unrelated to the question.
ex. I what town did you first meet your best friend? "potato".
> Sometimes I use a straight up password generator for the answers. Hope I never have to give those out over the phone.
I filled the security answer for my Blizzard account with random ascii garbage, which I didn't record, confident that I would always know my password.
That was true. But Blizzard disabled my account for purchasing time codes with a credit card other than the one that my account designated "preferred payment". (The card I was paying with was also listed under my account, but it wasn't "preferred". I have no idea what attack they think they're defending against.)
I had to call in. Phone-based customer service accepted "I don't think I can give you the answer to the security question" as a valid answer.
I've had to do it a few times, because I do that same thing. They usually respond with exasperation and say something like, "No, sir we need your security answer not your password." Then it's my turn to be exasperated and say, "No, check again, that's the answer." Very fun.
Don't do that unless you don't care about that account. Often the answer to a security question effectively acts as a password. You are not defending against someone guessing your answer, you are defending against someone using an automated dictionary attack. A common word like 'potato' scores quite high in the common password lists.
A safer option is to just generate a random password for those questions as well and store it on your password manager.
If you do that then it's super easy to social engineer the company in question. "I don't know what I put for mother's maiden name, I just mashed the keys a lot on that".
When you want to retrieve the password for an account you created 5 years ago, but you only remember creating it between 5 and 15 years ago and you have 2 dog loving grandma's each of whom have 2-3 old doggos all the time....well, good luck in remembering and identifying the correct name of the possible 10-15 dogs
This is a case where you think of an _idealized_ grandma, and her perfectly preserved dog, `Mr. Mycroft Applebottom III`, who has been sitting on her mantlepiece since you were in gradeschool. [0]
The site doesn't have to know you're making it up.
0: Obviously, it'd be better if your idealized grandma spoke with your password generator beforehand, and therefore named her dog something less guessable, like `ff627f056c51b694e2e5d0bdc168c647`.
That's a good suggestion actually: just remember that you always ignore the question, and you've saved the actual securely generated answer as 'sitename-sec-question' or whatever.
Right but if there are six possible dogs at creation time you choose a different question.
If the answer is unique when you create it, but a new dog comes into the picture when you need to recall it, I doubt that's going to cause much of a problem. Maybe you get it wrong once and try again - you're only going through this because you already forgot your password.
If your grandmother is alive and has one dog and you use that dog's name as the answer you are not terribly secure because this information is easy to obtain. It's only virtue is that it is, supposedly, easier for you to remember.
I'd argue this is one of the more secure questions compared to other common questions like "Your mother's maiden name" or "The make of your first car".
Exactly. I don't know how to go about finding out someone's (not personally known to me) grandmother's dog's name, but if I know someone's name then mother's maiden name is easy in the UK.
It's a bad idea to use anything that might change. For example, "What was the make of your first car?" Might be OK. "What is the make of your favorite car?" Not good, odds are decent your favorite will change between setting the answer and trying to use it.
I feel like we need laws in place on software and hardware security. Laws to punish crimes is good, but we also need some regulation, simple ones, to govern how companies have the obligation to manage software and hardware security.
I think:
* companies running a website and collects customer data must have an incident response plan laid out.
If we punish bad service providers reported by consumers, why can't we do the same? We are talking about companies ignoring and downplaying even the most low-hanging fruit vulnerability, and companies that don't understand web security because the workers there have no clues what they are dealing. If we can't raise our cyber security awareness and education domestically, then we fail at being a top technology leader in this world. I don't expect every company hires a security engineer, perhaps under some managed services.
This is a very dicey subject. I think it's best to keep it loose as long as possible. Introducing a regulatory body into any field is perilous, but something as fast moving as software and security would be frightening. What happens when the regulation is that you have to use the algorithm that was cracked last month? Eek.
Voluntary, socially-enforced customs are better. Things like the MPAA rating system have successfully staved off government intervention. Such standards are much more flexible.
We already have this de-facto via TLS and the browser's angry messages if you don't comply with their expectations, but it'd be interesting if browsers started running a more thorough security verification program and giving preferential treatment to sites that implemented it.
That is also scary because it centralizes more control in browser manufacturers (which, today, means Google almost as much as it meant Microsoft in the oughts). But still better than the government I guess, and blocking a site in software is much more motivating than the risk of a fine for non-compliance.
I remember when cookies was where every site kept their cached credentials in plaintext. It was so popular you didn't need a password manager, just a cookie and form manager.
In case most of you didn't know/forgot: a large amount of the modern security practices on the web are due to browsers making it easy for sites to attack users, and making MITM trivial. The most common attack vector is literally the browser and protocol design, not a bug in the browser.
Also, to replace passwords, all you need is TOTP. You can combine TOTP with a 2nd factor for a little boost, but TOTP is much better than passwords, and more convenient when automated. Combine this with password reset and one-time use codes and the majority of users would not need to remember more than one or two passwords (the password for their e-mail or OAuth provider). You can also password-protect the shared secret to protect data at rest (some VPNs do this as alternative to physical tokens)
A protocol extension could define a handshake to negotiate TOTP tokens. The browser would generate a token with a plugin and send it securely after prompting the user to authorize it, and optionally try to verify the identity of the site. It could be extended to rotate the shared secret after an expiration period.
Also, it's about time we defined a better secure mail standard so we can rely on password resets to be valid and eliminate phishing.
It's a nice idea, but their implementation proposal is lame. They keep depending on a phone like a phone is secure or ubiquitous (of which it is neither) or on keyfobs or "gestures" (of which the former nobody will use, and the latter is just a less secure password).
They rely on public key auth, which is more complicated and less reliable than a simple TOTP token. Considering that web browsers already support public key authentication but nobody uses it because their design is a UX garbage fire, I don't think that scheme will work well.
Other things are problematic too, like scripts (rather than the web server) having control of the process; this is an unnecessary attack vector. They also depend on browser-specific technology which limits how this system can be extended to other clients. This spec was clearly written by a JS developer, for JS developers.
This should not be a "web standard". Service providers that need strong authentication for HTTP don't only use web browsers. It will be more useful to be able to support existing applications through the use of an HTTP extension, rather than updating every single web app in the world to support this scheme.
In fact, now that I think of it, you could tack TOTP onto existing HTTP authentication right now! Just allow "TOTP:<token>" as a password entry. I don't know why I didn't think of that before.
If you contacted Rackspace's chat support while logged in, the representative sometimes asked the security question. To which (remember, you're logged in) you could click "Account Settings", "Security Question" copypaste.
A former employer of mine had internal security questions. Five of them. They were all inane questions, the "favorite movie?" type, so I came up with a somewhat random answer and used the same answer to all of them. The one time I had to use it, the representative asked all five questions, and I gave him the same ridiculous answer each time. He did it all with a straight face somehow, and looking back, I don't know why I didn't stop him at the fourth question to ask "if I knew the first three, you really think I don't know the last two?"
That actually was a typo. Amazingly, a typo that has earned me a -3 downvote so far...
People seem really freakishly touchy about word choice around here lately. Honestly, that's likely to make me care less about their delicate sensibilities.
It's likely because the joke didn't add much. Word choice seems to be less important than humour with no other content, from what I've seen over the past few years.
The number of webmasters who wanted me to set up ssl to 'secure' their site, while the backend emailed cc info in the clear to the orders dept is larger than I have digits, even the extra adolecent joke ones.
To be honest credit cards are a terrible system in terms of security. Everything to make a charge is on the card and people freely give it out to different websites.
All of my cards have excellent theft protection policies though. If my card gets stolen, I'm not responsible for any damages. That's a great security policy; better than most websites.
They _assume_ card numbers will get stolen all the time and invest in identifying suspicious behavior. And all behavior is 100% auditable all the time. Security isn't just about authentication/authorization. I wish more websites assumed passwords might get phished and thought through how to protect users in that case.
My credit card numbers are one of my pieces of private information I feel _least_ apprehensive about sharing.
Is this not changing though?
I can't remember the last time I bought something online without having to either use password or 2factor auth, and there are no places here that do not require a pin code when using a cc in a store.
I'm in Sweden though (but using mastercard).
Hmmm, that's interesting. I've never been to Sweden, but pretty much no shops in any country I've ever visited required a pin code for Visa or Amex credit cards. Is this really changing?
What do they require then? I've never in my entire life used my credit/debit card without typing in the PIN number(except for contactless payments, of course). I'm in the UK.
I think they can be used with a signature too? Maybe? I've never heard of anyone actually signing a bill instead of using the pin, and besides, I don't even sign my cards.
Chip and signature is the norm in brick and mortar stores in the USA. Even then, many purchases will not require a signature unless the transaction is over a certain amount, typically $50. Many card issuers were too nervous to go full chip and pin in US markets for whatever reason.
Yes, they require a signature. I'm not saying this is a safe practice, just that I've never seen a store where they asked me for a pin code for major credit cards such as Visa, Amex and (I'm pretty sure, but I don't have one) MasterCard. And I'm talking not only my own country, but also the US and several countries in Europe. When I was in the UK some years ago, they didn't ask me for my pin code when I used my Visa credit card, either. Maybe it's the type of card?
I'm talking about credit cards, mind you. Debit cards are different, and while in my country Visa Electron doesn't require anything but a signature, it's entirely possible if I tried to use it abroad they'd ask for a pin code. Not sure.
I believe it is possible to use a cc here without the pin if you show ID and sign a receipt. I think I've seen it for people who've forgotten their code and tourists who don't know their code.
I have both British and Polish debit and credit cards, Visa and Mastercard(Visa Classic credit cards), I've used them in Spain, Germany, Netherlands, France, Spain and Portugal, and literally never had to sign for them, be it in shops or restaurants.
I'm not saying there aren't cards that need signing,but I've literally never seen any.
My experience is the opposite: I've never used a PIN.
I've done some reading and now I believe it depends on the country which issued the card (as opposed to the country where you're using the card). So if you have a card issued in the US and Latin America, you probably won't asked for a PIN -- because you don't have one -- and instead you'll be asked for id and your signature. If you have a card issued in Europe, you'll be asked for a PIN.
Interesting. A PIN seems safer than a signature to me, or possibly the combination of chip + PIN, but it simply doesn't get used where I live.
Now I've done some reading, and it seems my country (in Latin America) is following US standards. It seems US-issued credit cards only require signatures, even when used abroad, and only recently (as far as I can google it) are they slowly starting to switch to either PIN or chip-based cards. Newly issued cards where I live have chips (this is a relatively recent development), which I'm not sure exactly how are supposed to be safer than magnetic strip cards, and also don't require PINs.
As someone who has used Flexible SSL, it's perfectly reasonable for some threat models. In our case, credit cards and passwords were both managed by external services and the actual data we stored was not sensitive. We really just needed to prevent account hijacking in cafes via Firesheep.
Why do we still use passwords? When I connect to Amazon.com I don't ask them for a username and password to verify they really are Amazon. I verify their certificate. Why can't I authentic with a certificate too?
Back in the dark, dark days before LetsEncrypt, I had some StartSSL free certs. At one point, I was logging into their site using a certificate. I assume it was quite secure, but it was a complete PITA to set up. Especially when I wanted to log in on a different machine.
You can. Client side SSL is a thing, and it totally prevents phishing - pretty much any browser has supported it for ten years.
It is also a UX nightmare. The browser you are reading this with almost certainly support it, but try to see if you can find the menu option to install one.
I've actually played around with that. Yes, the browser side UX is a nightmare. It was real fun (for extremely small values of "fun") installing the client certificate on Firefox and Safari (on the Mac, on the iPad and on the iPhone). I was rather surprised by the number of different browsers (and number of computers) it needed to be installed on.
This has been implemented before. I briefly maintained a legacy project that supported it via IE. In practice, it's a nightmare. Users constantly lose their certs and require manual re-auth. There was a complex install process to get the new cert in place. Usernames and passwords were still a thing; the cert was just to verify that you're coming from an authenticated computer.
Something like your proposal may work if it involves a one-way hash of biometric data (fingerprint scan) so that people can't "lose their cert", but that comes with its own problems too.
>Something like your proposal may work if it involves a one-way hash of biometric data (fingerprint scan) so that people can't "lose their cert", but that comes with its own problems too.
Such as biometrics make terrible passwords because they can't be changed. Once compromised (3d printed fingerprints anyone? [0]) then you are forever compromised. Just in case someone wanted an example of why biometrics are terrible.
Does anyone here buy from auction sites often? Those are a nightmare, they let the sellers do pretty much anything and very few accept paypal (they're THAT stingy) - sellers on liveauction.com routinely ask buyers to provide credit card info over email. It looks like a lot of sellers are flocking to these because ebay is too strict, wait, I mean "sane".
Recently I won an auction at Galabid.com. They use Stripe and after putting my credit card, it was denied (I think because it was a large payment and I have no limits). Unfortunately, the Stripe JS popup didn't let me change the card. I don't know why - I tried incognito, diff browsers, but it was helpless. I had to send another Card number and all its data through email or the items were going to be auctioned again if I didn't pay in 24hs.
* inactivates your account if your account is negative.
* one reason for negative account is the credit card is expired.
* you cannot update your credit card if the account is inactive.
Another example of possible poor security (which seems to be depressingly common with UK banks) is to ask for certain characters from your password. Like say, the 1st, 3rd and 5th characters in the word.
However, if the password was encrypted, they shouldn't really have this information should they? So by asking for it, they're basically admitting everything's stored in either plain text (very bad) or a reversable form of encryption (also quite bad).
There are other complaints about this too (like accidentally encouraging people to write the passwords down so they can figure out which character is the 3rd one or what not):
I can't believe people still inform and try to counsel these tone-deaf corporations. The upside is so small and the downside is potentially quite large. Catch some moron CEO in a bad mood and they've got plenty of resources to make your life hell even if they don't have a legal case.
> And before we all lose out minds going "the password must die", nobody has yet figured out how to make that happen!
If I were designing a new product today, I would never consider having usernames and passwords. While it is a shame Mozilla killed Persona before it could even have a chance, it is still way, way more reasonable to use third party signin buttons than to try to do it on your own. Again. Brokenly. For the thousandth time per person.
It is a shame that one button alone does not work, but just OpenID connect includes Google, MS, and Amazon (so one login backend and three click buttons and you are covering probably 99% of people, who will have one of those three accounts).
Some of this stuff is absolutely terrifying. I mean, using the last four digits of a mobile number as a password? Damn, it's a site where a leaked username list is literally a major data breach.
If there’s one thing that needs to go away ASAP, it’s “security” questions. They are so time-consuming, they increase the amount of information shared with 3rd parties, and the quotes I used are intentional because the questions provide no security whatsoever. Quite the opposite: these questions simply force people to share more information than they should be required to share, and (for most people who don’t think to lie) it increases the chance that sensitive secrets will be revealed and used to impersonate people.
It’s even worse when these “security” questions are coupled with the “Monday-Friday, 9-5 ET” phone numbers. I once had a mobile login “lock out my account” on a Friday night and I was informed that I could not unlock it without calling one of those numbers and answering my “security” questions. So instead of having access as a customer, I had over two full days of nothing, followed by the obligation to find time to call these people, followed by the awkward process of wondering if I would even remember the damned questions or answers. Every last bit of that process is broken, wrong, unnecessary, adds no security, and disrespects customers.
And in case you think account-lockouts are any better, consider that it is TRIVIAL to use this as an attack. Someone you don’t like? Odds are you can find their E-mail log-in. “Guess” their password 3 times, and they can’t access their account at all for some extremely-inconvenient length of time. Ever-increasing delays between log-in attempts work just fine as an alternative to lockouts.
I've seen the "Express <Form with Personal Data>" vuln before, but with people's SSNs, DOBs, and bank account numbers, plus sequential numeric user IDs instead of emails. It's fixed now, thankfully, but, uh, yeah.
This reminds me of AT&To Gophone website. Your username is your phone number and your password is a 4 digit PIN. The same pin you can use to transfer out your number.
this is exactly why 2FA with SMS is not secure at all. If someone really wants to get into your account all you have done is added one extra step where they need to steal your phone account and then they steal your other account. It has been shown how easy it is to steal someones phone account and transfer the number to a cheap burner phone or online service. This also kills your cell service so unless you have another phone to use you cant even call to secure your accounts so the attacker has plenty of time to break in to all your other accounts
Absolutes are the wrong language. It adds a significant burden (steal the user's phone account), which if nothing else requires individual attention, which drastically changes the economics of an attack vs, say, mass automated attacks using leaked passwords checking for re-use. Sure, you and I might have unique randomly generated passwords for our accounts, but not everyone is so careful, and SMS verification can and does save many an account.
One of my pet peeves is that 1password doesn't seem to support security questions out of the box, so I have to manually generate random passwords with it, fields for Q1, A1, etc., then set those fields to type "password".
@troyhunt: Have you seen the latest leak by Atlassian?
I got an email on 4th April, 2017 that reads as follows:
Hello,
This weekend, our Security Intelligence Team detected an incident
affecting HipChat.com that may have resulted in unauthorized
access to user account information (including name, email address
and hashed password). Atlassian ID is used to manage access to
your HipChat.com account and other Atlassian services you use.
The password is encryprted using bcrypt with a random salt. In
our security investigation, we found no evidence of unauthorized
access to financial and/or credit card information. We can also
confirm that we have found no evidence of other Atlassian systems
or products being affected.
As an added precaution, we have reset your Atlassian ID which is
used to access all Atlassian services, including HipChat. Please
go to https://id.atlassian.com/login/resetpassword and enter your
email address to trigger a password reset email for your Atlassian
ID account. If you have been using your Atlassian ID password on
other sites, services or online accounts, we recommend that you
immediately change those passwords as well.
Please refer to the HipChat Blog at http://blog.hipchat.com for
additional information about this incident. We regret any
disruption this may have caused and appreciate your immediate
attention. If you have questions, please do not hesitate to
contact HipChat Support via our support portal or by sending email
directly to support@hipchat.com.
– Ganesh Krishnan, Chief Security Officer
Nice of them to provide links to reset your password - anyone quick on their feet and with access to that database could have got people's passwords.
I think if you tweeted at them they would release an email list to you for updating the https://haveibeenpwned.com/ website. I imagine there's still a lot of people that are unaware that their details are out there and that their accounts are vulnerable.
They have their email and their ID, added with the knowledge they are compromised. That's enough to build a spoof password reset email and get them to type in an old/new email.
Oh no! someone could send me an email confirming that I want to reset my password! Just like every other site out there that has a forgot password link.
They know their email and ID - so it's targeted. Without this information it is generic and easily spotted. Quoting your repository is a lot more personal and believable.
Additionally you can use the previous warning emails to really target somebody as one of the few that need "further recovery/security" steps. This is a security issue.
Are you saying that they don't check that the email address you enter is the right one? That would be bad, but I can't see how you can conclude that from the message you quoted.
I am not using HipChat but I am using Trello and now that they have been acquired by Atlassian I wonder if they linked all of Trello's accounts to an Atlassian ID?
As an added precaution, we have reset your Atlassian ID
which is used to access all Atlassian services
"No really, I've seen some very stupid security stuff out there the likes of which make the above example not just believable, but likely. Don't believe me? Here, hold my beer..."
The "Here, hold my beer..." line is totally played out at this point, anyway, but the usage here doesn't even make sense. The implication is that you're about to do something stupid, not that you're about to tell us about some stupid things other people have done.
Why would I need to hold your beer while you tell me a story?
Sadly British and other Commonwealth countries like Australia seem way too overrepresented in crap like this. Something about British culture leads to atrocious ignorance of security.
This is a huge problem and has been for a long time. We allow pretty much anyone to code up a website. It'd be similar to allowing anybody to start practicing medicine.
I've lost count of how many websites I've used that were blatantly insecure. Sometimes you have no choice but to do it, like when I had to apply for a Brazil travel visa. Their SSL certificate has expired, and has been expired for years now.
There would be benefits to licensing web dev. I wouldn't suggest that a license should be required for any web development but if the website is used to safeguard PII or secure financial transactions then I don't think it would be too unreasonable to do so to get rid of these clowns. I used to work in an SMB web development shop and the incompetence that I'd see daily from our competition really changed my perspective on the field.
I used to feel almost like an imposter when I first started but I've seen so many "experts" who have been selling their services for decades yet they don't understand even the fundamentals of their profession. We already require licensing professionals for many things which are arguably less important than a lot of websites. I think a fair balance could be struck here to make sure that large businesses like Betfair can't get away with this crap yet not stifle hobbyists or businesses whose websites don't pose any appreciable risk.
This is a totally legit response. After all if something goes wrong they must have followed "best practices". No reasonable person would expect them to do more.
And it's true (if you only consider the needs of the business). This is a solid strategy for getting lawsuits dismissed. I've seen it in physical security too [+]. It only took one investment bank to put badge-checking turnstiles in place and then they all had to do it. That stuck with banks only for a while until one more conventional business did it...and now I was at Twitch the other day and they have it.
Of course who's missing here is the customer. But the customer's needs aren't paramount: the business's are -- and more specifically the manager who has to spend the money on security. If they have put in just enough that they won't get fired when it fucks up, and if they saved money and effort in the process: WIN!
[+] my favorite physical security story is old, so at the end: when leaving Intel's Santa Clara fab in the 1990s you would have to hand over your briefcase for inspection to make sure you weren't leaving with any Intel documents. They didn't care if you had floppy disks. Why? Because this was a defense against shareholder lawsuits and "what else could the guards do?" This is where I learned the explanation above: once anyone in the industry increased plant security they all would have to, which nobody wanted. So LCD was the name of the game.