• P (unregistered)

    You know the old saying, they can't hack you if your website/webservice/server is down. It's the ultimate secure option to surpass SSL.

  • Howard Richards (google)

    Benny should be fired on the spot for resisting SSL on web applications if they accept login credentials. He clearly knows nothing about security.

  • Robert Morson (google) in reply to P

    You're joking, but that's basically the philosophy the security folks at my company subscribe to.

  • (nodebb)

    I always find it amusing the anti-hosted service sort of mentality you see because "it's on the internet and vulnerable!". If millions of companies, including ones much bigger and more profitable than your rinky-dink operation, use it with no problems then you can too.

  • Little Bobby Tables (unregistered)

    Self-important blowhard who knows nothing and loves the sound of his own voice making up excuses as to why his area of responsibility is falling short. Seen 'em everywhere.

    TRWTF is Randy's boss who takes his word for it.

  • (nodebb) in reply to P

    It's also cheaper.

  • (nodebb)

    Part of the audit process is making an action plan to address the deficiencies identified in the audit. The next audit meeting would start with a review of the how the company dealt with the deficiencies.

    Implement SSL on websites:  Won't fix, on Benny's recommendation.  He says it is too expensive to implement.
    

    Hopefully all that happens is they fail the next audit, at which point management realizes they need to bring in somebody who knows what they are doing with regards to SSL. I can also see what would happen after they finally find out about a data breach of their user credentials or customer credit card data from a man-in-the-middle. Now that will be too expensive!

  • Scott (unregistered)

    I don't know about certs and SSL costs, but if everyone else on the planet is doing it, it might just be an o.k. idea.

    Kind of reminds me of the idiots I work with: MVC is too hard, ADO.NET data access is better than EF, etc, etc. In other words, "I'm too lazy and stupid to learn the (not even particularly) new technology, so I'll be aggressively stupid and defend the use of old technology, rather than provide any actual reasoning."

  • Altaree (unregistered)

    To Benny: "OK, Boomer."

  • (nodebb)

    I still remember people paying $2000 for a certificate. If you're still in that mindset, $20 or free certificates sound like a scam. Benny has the right attitude of resisting things that are too good to be true, but is ignorant of the facts on the ground. Somebody should talk sense into him. Otherwise next thing you know he'll go buy CRT monitors because LCDs are too good to be true.

  • Geoff (unregistered)

    I feel like this story is fake. Randy knows what LetsEncrypt is but he does not have at least testamentary understanding of how SSL/TLS authentication/trust works to call out Benny's complete and utter male cattle excrement?

    From a security perspective I don't think LE has been good thing either but the damage is already done in the sense their CA certs are in everyone's trusted stores already and if you administratively 'fix' that glitch they way you should with the CA's of certain foreign nations administratively well LE is at critical mass so everything will break and the users will revolt. So as far as client systems accessing a website the ship has sailed there might as well just use LE.

    Randy ought to be able to suggest some alternative even if Benny wants to run a completely closed network and not let things like certbot/dehydrated out fetch new LE certs. A good option would be stand up their own CA (free) and fairly easy when the number of clients that will need to trust it is smallish and already under your administrative control.

  • Hasseman (unregistered) in reply to Robin Koch

    'Yep, cost less and generates less revenue

  • Right (unregistered)

    I once worked at a company where everyone used telnet for years because the only version of ssh available for our (SunOS) servers had a hole. This was in the late '00s. One day, one of the developers just installed it anyway and fire rained from the sky.

  • Nathan (unregistered) in reply to Mr. TA

    Well, you still can spend over $2000 for a cert if you want. (Look up the cost for a SAN cert with wildcard alternative names. Relatively new, and very pricey.) I guess it depends on the site, company (public/private/government), and what they're doing, but with with all the various audit standards that exist today (PCI, HIPPA, FFIEC, SOX, etc., let alone non-US-centric requirements) I really can't imagine a company getting away with publicly exposed sites that are anything more than static pages not performing any sort of authentications or transactions.

    Just wait until Benny gets asked about adding MFA. ("But we can't ask employees to use personal devices for work-related authentication, and issuing company devices, physical tokens, or hardware that supports biometric is going to be too expensive!!!")

  • (nodebb) in reply to Nathan

    You can also spend $20,000 on a handbag.

  • (nodebb) in reply to Nathan

    Just wait until Benny gets asked about adding MFA. ("But we can't ask employees to use personal devices for work-related authentication, and issuing company devices, physical tokens, or hardware that supports biometric is going to be too expensive!!!")

    He would be right about one aspect, though. They can't (mustn't?) ask employees to use personal devices for work-related authentication. It's probably illegal, and if it isn't, it should be, and anyway, any employer that tells me I must use my own phone / other device for work-related MFA will get told to See Figure One. (I would probably be polite about it, but not very polite.)

  • Rob Hoffmann (google) in reply to Steve_The_Cynic

    My employer's 2FA requires using personal devices (via an app). Not sure why that's a problem (certainly in terms of legality), but you do you.

    I'm still trying to figure out how anyone bought the idea that one is MORE secure by not using SECURE Sockets Layer. That whole enterprise is TRWTF.

  • tbo (unregistered)

    Not gonna lie, the site earned its name today. Because I read the story and just thought...

    What... the fuck?

  • Jaloopa (unregistered) in reply to tbo

    Not gonna lie, the site earned its name today. Because I read the story and just thought...

    What... the fuck?

    Um, you do know the name stands for Worse Than Failure don't you?

  • Shannon (unregistered) in reply to Rob Hoffmann

    I'm with you, I see no issue with having MFA including a personal device. Something you know and something you have being the basics of MFA, right? I'd complain if included some kind of data snooping app, but something equivalent to Google's Authenticator app is quite non-invasive.

  • Just a Dev (unregistered) in reply to Jaloopa

    Actually, in the old days of this site it stood for exactly what he said :P It's just more politically correct to say worse than failure now, less offensive for today's snowflakes.

  • Little Bobby Tables (unregistered)

    Never thought the use of personal devices as being a problem. We get messaged a one-time pwd to our phones when setting up a VPN connection. Works fine. As long as I remember to go through and clean up my inbox. Small price to pay for the privilege of working from bed, I mean home 4+ days a week.

  • sizer99 (google)

    Benny only gets his SSLs from the most trusted name he knows: GoDaddy - they had a superbowl ad.

  • (nodebb) in reply to Geoff

    Thanks for pointing this out. It does not prove the story is fake, though. Hanlon's Razor still applies: "Never attribute to malice what is sufficiently explained by stupidity."

    In addition to what you wrote, I may point out that there are additional mitigations against fake server certs, for one, Certificate Transparency (implemented by some browsers). Second, using a client certificate instead of or in addition to a password would be powerful, because it prevents impersonation and, with that, MITM. E.g., if you can fake a webmail certificate and redirect traffic to your server, and can even get clients to log in, but still can't log in as that user on the original webmail server, then you can do none of the following:

    • Get immediate access to the client's webmail account.
    • Present a convincing fake in order to prompt the user into giving away additional information.

    Of course, client certificates are a potential support headache – it can be hard enough to educate users about picking a good password – but where there is a will, there is a way.

    Another interesting observation is that HTTP authentication is still an utter mess. HTTP Digest Auth is not supported by all browsers and completely outdated. HTTP Basic Auth transmits cleartext passwords and completely relies on a trustworthy server certificate. JavaScript solutions are no good because if you can fake a certificate, you can send whatever HTML/CSS/JS you want, defeating any additional protections you may have originally implemented.

    This grim situation could be changed if an up to date, secure digest method could be agreed on and adopted by browsers, I am thinking mainly of SCRAM-SHA-256. But still, you would then need to educate users to only enter their password in the official browser authentication pop-up window, so even this ray of hope is very dim indeed.

    PS: IMO, security should be like an ogre – it should have layers.

  • Torgo (unregistered)

    But is it more expensive than the lawsuit and reputation loss of a data breach?

  • Jaime (unregistered) in reply to Steve_The_Cynic

    Steve, we don't require anyone to use their personal devices. However, those that choose not to have to do all of their work in the building. No need to be rude to anyone, we'll all be able to IM you from our living rooms.

  • Regurgitated rubbish (unregistered) in reply to Jaloopa

    Um, you do know the name stands for Worse Than Failure don't you?

    You must be new here: https://thedailywtf.com/articles/Announcement_0x3a__Website_0x2e_RenameTo(0x201c_Worse_Than_Failure_0x201d)

  • Klimax (unregistered) in reply to Shannon

    I'd complain if it would require insecure and unsecurable stuff like Android or iOS. (Also one where you are at mercy of phone maker and OS vendor)

  • Worf (unregistered) in reply to Shannon

    Some companies require you to attach your personal phone to their network in order to get their apps, including the 2FA app or they won't approve it. This mobile provisioning certificate can do anything - they can install anything to your phone.

    Even more importantly, they can remotely wipe your phone or configure it in ways you don't approve of.

  • Fnord (unregistered)

    That's sad, because a response of "it's not on the Internet, it's in the CLOUD!" would probably have carried the day around that level of stupidity.

  • (nodebb) in reply to Worf

    In that case, your answer should be "Sorry, I don't have a phone that's capable of running your MFA app" - after all, there are plenty of people out there who don't use smartphones, myself included.

  • A dba (unregistered) in reply to Fnord

    Lol you laugh, but ‘the cloud’ has become my company’s holy grail. They just realized this month what their Azure bill looks like.

  • (nodebb) in reply to Jaloopa

    I did not.

  • NULLPTR (unregistered) in reply to Regurgitated rubbish

    InvalidArgumentException("Link throws a 404 error");

  • Paranoid (unregistered)

    Of course Benny protested - his cousin will need time to set up a shell company that sells certs for $3000. And deciding to use LetsEncrypt now would kill off that plan.

  • doubting_poster (unregistered) in reply to kbauer

    Good, because it's not called that.

  • Jaloopa (unregistered) in reply to doubting_poster

    What the fuck do you think it stands for then?

  • You can't have my name (unregistered)

    SSL was a failure out of the gate. The CAs haven't been keeping up with their end of the deal. This is a good read on the whole mess https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf

    It's scary we are still using it.

  • stuart lynne (google)

    And even if your infrastructure can't support HTTPS you can just hide behind CloudFlare or CloudFront and let them do the heavy lifting. I just had an email this morning from AWS saying they were renewing an SSL cert on one of my static S3 based websites.

  • Pavel (unregistered)

    TRWTF is SSL and LetsEncrypt together in one text.

  • Anonymous (unregistered)

    On MFA, I think the difference is between an employer allowing the authenticator app to be on personal devices, and requiring it be so. For my company if anyone really doesn't want to use their own phone for the MFA then we can give them a cheap PAYG phone for it.

  • eric bloedow (unregistered) in reply to Fnord

    when someone said "why don't you just store your data in The Cloud", someone else responded "the cloud is simply SOMEONE ELSE'S COMPUTER."

  • Officer Johnny Holzkopf (unregistered) in reply to Quietust

    Many years ago, in order to begin a time-limited work for a company (they paid below average, but I needed the money, not the job in particular), I was asked to provide them my private phone number and install their authentication app. The reasons explained by my to-be supervisor: "With this app, we will monitor your phone and make sure it's secure. We'll also be able to call you in case we need to." Keep in mind, there was no "on duty during nights or weekends or on vacation" in our job agreement, so I politely asked my to-be supervisor: "I understand. Please tell me your private phone number so I can call you if I have further questions. I'll probably call you around midnight when I'm home, or whenever I feel like it. I'd also like you to install the app I wrote on your smartphone so I can hear and see what you're doing - just to make sure I'm not interrupting you or anything, because I'm very polite and helpful." Facial expressions were exchanged. The issue was then brought to the manager's attention, to who I explained that I don't even own a smartphone and that I won't be willing to buy one, pay for a SIM card plus contract (or prepaid), and energy consumption for charging. We finally agreed that I get issued a smartphone by that company, with one of their numbers (they had a "fleet contract" already), and that I will charge it in their offices. And as per our agreement, I switched the thing off after leaving the office, simply because - and I made sure they understood it - I won't be available for company stuff in my free time without payment. Yes, it is that simple, you get what you pay for. Free marked rulez.

Leave a comment on “The Most Secure Option”

Log In or post as a guest

Replying to comment #:

« Return to Article