Threads for r0b

  1. 2

    Don’t ever use leaked passwords

    At what point does the entropy pool of leaked passwords approach the entropy of the pool of unleaked passwords? As time goes forward the key space of leaked passwords is only getting bigger, and the key space of unleaked passwords is essentially constant.

    1. 4

      tha password set has ~ 1e9 passwords whereas 10 digits of bas64 make 1e18.

      Hard to believe, but the space is still sparsely filled:

      The whole current leak set fills the space about as much as a single password fills the leak set.

    1. 2

      Clever hack. The node package ecosystem needs more of this.

      1. 1

        It was just a joke))

      1. 7

        Really cool project, and great to see homegrown home automation as opposed to it all running on a “cloud” which can disappear at any time.

        1. 8

          Maybe it’s my age showing, but I’m reluctant to deploy home-grown automation solutions because they inevitably break or others in the house get frustrated with them.

          My garage monitoring solution is an off-the-shelf Z-wave garage door tilt sensor that sends updates to my Z-wave network, which are picked up by Indigo running on a Mac Mini. This starts a timer and sends a Pushover notification to my wife and me if the garage door is left open for more than 10 minutes.

          1. 3

            Their is always a risk with external services being not available anymore, like Insteon Shutdown. But I really dislike “face-lifts” or behaviour/feature changes for apps. It’s annoying and most often this change doesn’t have a benefit for me. Something like a rearrangement of products in your favourite supermarket. I try to use simple solution to avoid the not working frustration. For my Hue lights I just used two modes (bright or dimmed) which I can set with a text message to my XMPP bot. I also use this bot to get the current outside temperature or to send me a reminder via email.

            1. 3

              Maybe it’s my age showing, but I’m reluctant to deploy home-grown automation solutions because they inevitably break or others in the house get frustrated with them.

              This was front of mind when building this project. I tried hard to reduce the surface area of breakage in this project by stripping the system image down a lot. Time will tell I suppose :)

              1. 2

                I’m with you there. I have the same setup, but with node-red. This particular sensor is on Zigbee, but the door controller is on Z-wave. I want local control, but for technical ownership of these problems I want as close to zero as possible.

            1. 1

              Nothing groundbreaking in this article. It’s good to see the idea of deliberate CSS getting some traction. He kind of self defeats though:

              Make your own default.css where you define colors, dimensions, round corners and all the important HMTL elements that you are planning to use.

              Followed by:

              Here is my take on this problem: It’s called Basic.css

              Where he provides a general purpose utility for the entirety of HTML to look the same in all browsers.

              1. 1

                My main point was don’t define the same HTML element over and over again. Limit to minimum the number of sets and resets. Some small differences in the various browsers are Ok. Basic.css is not identical in all the browsers mainly the HTML forms.

                1. 1

                  Yeah, I get that. But as the project develops, more and more will get swallowed into Basic.css, and it’ll become closer to what you’re trying to eliminate. Perhaps with reset omitted, saving a layer, but using Basic.css still means the browser is parsing rules for a dozen elements (or more) which I never use.

                  1. 1

                    Yes is true. There is always a risk that the default css will be overwritten as the project develops in time. We all have witness garbage WordPress themes with thousands and thousands lines of CSS code and maybe 5% is actually rendered by the browser. That is why I was super careful to include only the bare minimum into the Basic.css. Plus you always eliminate the parts you don’t use.

              1. 59

                It’s going to be cheaper. Especially when you consider employee costs. The most expensive AWS RDS instance is approximately $100k/year (full price). It’s not an apples to apples comparison, but in many countries you can’t get a database architect for that salary.

                “not an apples to apples comparison” is putting it mildly. You’re comparing the cost of some infrastructure with the cost of an application-level specialist you’d need either way. The equipment to run a comparable database instance on-premises should cost less than half that. Ops costs are harder to compare, but $work certainly doesn’t retain an operations engineer per big RDBMS instance.

                More generally, though, I think this is the way things are going without encouragement, and I hate it. It feels like the list of places where ops involves working with computers is shortening. I could offer all sorts of reasons why I think it’s a bad trend—it’s concentrating people, information and resources in a few huge companies, network effects stifle innovation, bespoke architectures are more efficient, your NOC is more likely to answer your calls when they work for you, blah blah. Mostly, though, it just makes me sad to see the things I enjoy becoming increasingly irrelevant except to a small group of companies I don’t want to work for.

                1. 30


                  Yes, always cheaper at first. And then your tiny thing grows, and then you cannot live without your managed services, and your managed service knows it, and then it is not cheaper anymore.

                  1. 13

                    This. Half of the jobs I had could be summed up as: oh shit, managed service X got out of control and its cost became unbearable.

                    In one instance, it ended up in the company firing 70% of its employees, because one morning, some GCP service costs had sky rocketed causing the main project of the company to fail. To be honest, had they made a simple extrapolation when they signed up for the service, the situation would be 100% expectable.

                    Of course it depends. S3 value offer is difficult to replicate as a self managed service, but things like hosted RDMS or even ec2 instances are really only an advantage when starting up and toying with tiny loads. Once your serviece start scaling, they quickly result in 1-3 orders of magnitude of extra costs. Which is unlikely irrelevant.

                  2. 16

                    You’re comparing the cost of some infrastructure with the cost of an application-level specialist you’d need either way.

                    I beg to differ. Lots of places can get by without the application-level specialist. Until they can’t. Making that decision is of course is an art, but using a managed service will extend how big you can get without a FTE (maybe you will need some consulting for tuning a query, for example, but that’s cheaper).

                    More generally, though, I think this is the way things are going without encouragement, and I hate it.

                    I understand this perspective. I still think there are ops tasks and jobs, but yes, they are certainly changing. I do think that managed services lets people build a lot more software (the same way that blogs let a lot more content be created than hand written html) but appreciate that the effects aren’t entirely positive.

                    1. 16

                      (I think it’s kinda relevant that you are a developer evangelist for one of these hosted services. Neither good nor bad, just an important datapoint.)

                      One thing that I think gets lost in this is that a company is theoretically valued also at the in-house talent. If your company is basically just a glorified rebundler and reseller of service providers, you lost the ability to leverage that in-house talent. You also by definition reduce the ability to distinguish yourself from other companies that are doing the same thing.

                      Second, there is a very real problem where people buy a service provider and then just patch over the issues with it using…another service provider! This has this weird inflection point where suddenly any scaling is a heart-stopping event as you graduate from the “developer wants to pad resume tier” to the “somebody in the C-suite needs to sign a contract tier”.

                      1. 5

                        I think it’s kinda relevant that you are a developer evangelist for one of these hosted services. Neither good nor bad, just an important datapoint.

                        Thanks for pointing that out! I have actually been espousing this viewpoint for years. I also taught AWS certification courses and built a start-up in the last 5 years and both of those cemented my view about leveraging managed services.

                        But yes, where people sit definitely affects where they stand, and I am no different. (I will also submit that, in my opinion, my employer’s offering beats the pants off the hand rolled authentication systems I have seen over the years.)

                        One thing that I think gets lost in this is that a company is theoretically valued also at the in-house talent.

                        That’s a good point. I think every company needs to decide what it is good at. That may be infrastructure for some companies, for others it might be enterprise sales, etc, etc. I have left companies where I knew my department was never going to be the focus of the company, because that limited my growth. My favorite old post about this topic:

                        From that post:

                        If it’s a core business function — do it yourself, no matter what.

                        As you mention service provider sprawl is a real problem. Being disciplined about managed services, including when to leave them, is just as hard as being disciplined about maintaining your own code. Maybe even harder because the effort is lower for the managed service (which would argue against my thesis, as you say).

                        1. 5

                          But yes, where people sit definitely affects where they stand, and I am no different.

                          Same here! And I didn’t mean that as a gotcha, more of as a “this poster has probably seen the spectrum of this philosophy in practice and that is relevant.”


                    2. 7

                      You bring up a lot of good points, especially about bespoke architecture. I think my only push back would be that the landslide majority of the time I set up a database (or any other service), it’s with the same configuration and features as everyone else. It makes more economic efficiency to cater to the general case, both for the vendor and the customer (or for the DBA and the company). Inevitably there will be divergence especially as a company or product grows in complexity.

                      I enjoy working on these architecture as well, but I find setting up the same old database again and again tiresome. I’d rather defer that action to a vendor until there’s a real problem worth solving and dive deep there.

                      It’s not fading into irrelevance when more companies are given the ability to use database (or whatever) at scale. On the contrary, more companies using databases mean more relevance for the people that know how to use them well. The statistical majority can stay under the middle 50% of the use case covered well by the vendor and leave me to cover the outer 50% where the inside and outside tails have interesting use cases.

                      1. 4

                        These complaints seem like general grievances with any kind of automation. More work is accomplished by fewer people, and those people are increasingly specialized. Bespoke widgets are replaced with cold, stamped-out widgets. Customer service decreases.

                        This isn’t to say your frustrations are invalid, only that they are normal and increasing as we automate away more and more skillsets. It’s a bummer to see your hard-won skills falling to a dramatically cheaper service.

                      1. 7

                        It’s more worth reading to the end than I expected. I was expecting to find the author touting the modernity we have, and presenting some case where everything we do and know today is better than it was.

                        1. 11

                          The point about I/O is important — it makes these sorts of comparisons hard to summarize (“we went to the moon with a pocket calculator!” …no). People don’t realize how much was done in hardware on the guidance computer to allow it to connect to so many sensors and maintain real-time accuracy with such limited CPU power. Nowadays one uses an overpowered general-purpose computer because it’s much cheaper to just throw excess cycles at the real-time problem.

                        1. 1

                          I wonder what’s happening in Apple’s QA and testing process. Though perfect testing is difficult, I think Apple has enough resources to do this better. They don’t have to make such trade-offs between quality and cost like start-ups.

                          1. 2

                            I don’t know, some of the bugs I’ve seen with their windowing features make wonder what their QA goals are.

                            Screen time on macOS is a neat try at useful software but it’s barely more stable than an alpha… and even after several release of macOS versions, full screen / split screen is still buggy. Combine the Full Screen with Screen Time at your own risk.

                          1. 3

                            Rails’ credentials/secrets file is the devil. So I recently integrated with my app, and it was a breeze to do. Might be a pricier than the AWS solution, but the capabilities I get are pretty nice.

                            Being a super small startup, I preferred paying EnvKey some money to offload the dev effort to come up with something which would never be as good as the EnvKey solution.

                            A few months in, and so far so good!

                            1. 2

                     looks interesting, and there’s definitely some merit to using a third party to store and encrypt your credentials over using aws to encrypt credentials for aws services.

                              $20/month isn’t terrible, but it’s a bit pricey and per-seat pricing feels a little out of line with the value of the service they’re providing. But who am I to judge a SaaS that looks like it’s paying the rent?

                              I worry about one thing: how do you securely deploy your envkey api key?

                              This is the same problem with HashiCorp Vault or any external secret keeper. There’s a secret which unlocks all your other secrets…that makes it the most important secret. How are you injecting that secret into your application? The whole reason the AWS Parameter store is viable is that access to download and decrypt your secrets isn’t controlled by a key stored on the machine. It’s controlled by the EC2 or container’s instance role.

                              1. 2

                                Hashicorp Vault has many ways to authenticate and get a token, you can tie to EC2, or you can auth against LDAP/Github, AppRole(where you can tie it to specific machine(s)/applications, etc. But it is definitely a turtles all the way down approach. The goal of Vault is to only have to worry about deploying the token and vault will then handle ALL of your secret/sensitive information for you, with transit, DB and the other backends. So at least the problem becomes “manageable” since it’s only the 1 token you have to get out there.

                            1. 5

                              aws kms create-key

                              I think that costs a little bit of money? IIRC I saw a dollar or so from KMS on my bill… Damn Bezos :D

                              Anyway, fetching from a service that always reveals the secrets to your machine is not that different from a local file on that machine. It’s good against random people trying disk recovery on a volume (though that’s not a problem on EC2, they do wipe all data) and accidental backups/snapshots (“your VM is cast into an AMI” as you mentioned), but fundamentally it’s still secrets-on-your-machine.

                              I think it might be reasonable for these services to support additional protection — not just based on secrets, but also, say, IP address whitelisting. So that if someone gets your secrets from an AMI you accidentally included secrets into and made public, they couldn’t access your accounts because they’re not accessing from your machines.

                              1. 4


                                costs $1/month until you delete it.


                                1. 1

                                  costs a little bit of money

                                  Unfortunately, yes. As said below, it’s $1/mo. It’s unfortunate they charge for it, but most of the AWS accounts I’m privvy to are spending a couple hundred a month so it goes unnoticed.

                                  but also, say, IP address whitelisting

                                  Absolutely! I use an IAM instance role to allow retrieving and decrypting credentials, so the machine/container has to be launched in AWS and under the right role to allow retrieving credentials.

                                  With clouds being so dynamic, IP address whitelisting is harder – containers and instances come online at different places by default. Elastic IPs, etc, make some room for lockdown. Fetching secrets at container start, process start, etc is a great way to keep the secrets off the file system, but it’s only one component of the broader picture of protecting your database credentials.

                                  1. 2

                                    to allow retrieving credentials

                                    I mean, require the right IP/machine to connect to the service the credential is for. I guess you already have that for AWS services :)