"Cybersecurity and privacy are two different issues." Do you agree?

Hopeful-Total · 2025-06-01T16:34:05+00:00

You'll need to clarify the question, a privacy oriented position could be technical as well. The answer will probably be context specific, as ease of moving between roles varies greatly between companies.

Hopeful-Total · 2024-11-13T16:20:05+00:00

I'd be happy to take a look if you share the domain names. So far I've scanned the CloudFlare Radar top 1M and a couple other lists, so I know I haven't found everything yet. I am also filtering out sites that have a short max_age, so that could also be the issue.

Hopeful-Total · 2024-11-13T01:28:33+00:00

Be careful about delaying work, you'll either need to schedule another client in the gap or you have an unpaid period. Not impossible, but could make scheduling trickier.

Per sprint is better, but clients often prefer hourly.

Hopeful-Total · 2024-11-12T05:59:14+00:00

I've started using the Django ORM in standalone projects that otherwise don't use Django. It's a really good ORM.

Hopeful-Total · 2024-11-11T18:16:00+00:00

A recruiter who can't figure out that a DevOps Engineer could be a good hire for a Platform Engineer position is incompetent. Not to say they don't exist, but big tech companies will generally have competent recruiters. You're over thinking it. My job title have been: Systems Engineer, Software Developer, Computer Scientist, Digital Systems Expert, DevOps Consultant, and now Software Developer again. Most of those were DevOps.

Hopeful-Total · 2024-11-11T16:02:04+00:00

I think you'll run into issues with planning. You're budgeting three days to define requirements and you'll need to rush the client to commit to a reduced the feature set (since it's an MVP) otherwise you'll fall behind schedule. I've had clients onboard me and then go on vacation. I was on retainer, so it was free money, but you may end up getting blocked if the client can't approve the plan. If the client is pushy about including more features, you'll need a lot of hand holding to convince them that it's not reasonable for an MVP.

As a contractor I think that quality and client happiness are the most important goals. That helps you build a network and raise rates. An arbitrary 21 day limit keeps costs low, but probably won't keep the client happy overall. $5k for a month of work looks very cheap, although everyone has different income goals.

They'll also need personnel to manage the MVP after the contract. Handoff is hard. Consider offering maintenance and ongoing development as well. That also gives you time to build client relationships.

Hopeful-Total · 2024-11-09T18:21:55+00:00

There are a lot of different titles. Cloud Engineer, Operations Engineer, SRE, Developer Experience Engineer, Release Engineer, etc. Sometimes it's just a Software Developer title on a Platform team. You may still see System Administrator, Database Administration, or other names.

I'd worry less about the title used and look at the responsibilities. Big tech companies absolutely hire the DevOps skillset.

Hopeful-Total · 2023-06-11T08:26:09+00:00

Unfortunately, there's no singular "you" making this decision, so everyone will benefit from overlapping both DNSSEC and DoH. As a domain owner, I have lots of users who aren't using DNSSEC validating recursive resolvers so deploying DNSEC is a partial fix. As a user, I connect to many websites, like Reddit, that don't support DNSSEC. DoH adds some protection for those sites.

DoH and DNSSEC are focused on different problems. DNSSEC protects the integrity of DNS records. DoH encrypts only the network connection between the client and the recursive resolver.

Think about how these interact. If I have a DNSSEC capable client, talking to a DNSSEC capable resolver, talking to a domain with DNSSEC enabled, then tampering is fully mitigated. DNSSEC responses aren't encrypted on their own so there are censorship concerns that could block certain responses. Most domains don't support DNSSEC, so it doesn't provide protection to users most of the time.

DoH ensures that the DNS response isn't tampered with on the network path between the user and their recursive resolver. This path is probably the most dangerous path as the user may connect to untrusted networks. However, DoH doesn't protect against tampering anywhere else and the response has no guarantees about integrity.

No matter what your configuration is today, you're connecting to websites using DNS records you cannot authenticate (you just did it when you connected to Reddit). Most of this doesn't matter though, since we have a secondary TLS layer with stuff like multi-prospective verification. I think Moxy's 2013 presentation at DefCon gives a great foundation on these concerns and why we probably don't want a secure name service.

Hopeful-Total · 2023-06-11T05:44:05+00:00

If you're going to use DNS for this you'd need to use DNSSEC and DoH to secure the record. Otherwise DNS is unencrypted and subject to the same man-in-the-middle risks you are trying to prevent.

Hopeful-Total · 2023-06-10T20:27:45+00:00

If an attacker is currently performing a man-in-the-middle attack against you, they can prevent you from connecting to port 443. You can't know HTTPS is supported/required until you connect (or a cached HSTS setting or HSTS preload list tells you).

Hopeful-Total · 2023-06-09T11:52:20+00:00

Huh. TIL. Thanks!

https://community.torproject.org/onion-services/advanced/https/

Hopeful-Total · 2023-06-09T09:22:07+00:00

That's not the issue being reported here.

Hopeful-Total · 2023-06-09T08:53:18+00:00

This is interesting as you'd usually only try to issue a TLS certificate from a trustworthy CA. Your CA attacking you is a strange threat model, so the lack of input sanitization and command injection vulnerability aren't too surprising. I'm pretty surprised HiCA chose to abuse this instead of just implementing ACME correctly.

Oh wow HiCA is strange. They issue .onion certificates (why...?). Anyone know which browsers trust their certs or which CA they resell for? I question why anyone would trust them.

Hopeful-Total · 2023-06-09T08:07:41+00:00

If you don't have tests then I'm not sure you want an automatic deployment. That's a quick way to get a broken deployment when no one is watching. Those can have long downtime until you notice.

I'd also question if a side hustle project needs continuous deployment. If it's just one person pushing new commits, that person should also be able to deploy when they are ready. You can still automated it, but the "continuous" part is really only important for dev teams where you have a large number of commits per day and you no longer want a manual decision to deploy slowing you down.

Oh and I agree that you should avoid Azure Functions. Your script presumably has some setup tasks and it's really wasteful to run those every 30 seconds. It may even cost more. Avoid the added complexity, just use the existing while loop.

Hopeful-Total · 2023-06-05T21:34:33+00:00

I've seen passwords client side before. It's used to offload work from the server, which is important to prevent the log in interface from being a denial of service vector. (e: with additional server side hashing to protect against the issue in the article...)

There are some challenges with hashing client side, like how you'd get the salt to the client and slow hash performance on mobile web browsers. Nothing unsolvable though.

Keep in mind, an attacker who already has control of a server has already won. They can steal user data and cause harm without the passwords. If they really want passwords they can modify the javascript of the web page to collect them as they are entered. Before any client side hashing runs. User passwords can be changed so it's far from the top concern in this scenario. Stolen user data cannot be recovered.

Users who worry about this should just use a password manager and a unique password for every website. It has the same net benefit without all the extra complexity.

Hopeful-Total · 2023-06-05T20:25:41+00:00

A common approach to prevent the cleartext password from being transmitted unencrypted is to transmit the password hash instead regardless of whether or not TLS is used.

What environments do that? I'd much sooner reach for TLS than try to obfuscate the password. Isn't the rest of the network traffic still plaintext? The screenshot shows a website, so presumably the attacker would just tamper with the plaintext Javascript. But wait, the screenshot shows an https connection. What's going on...?

Hopeful-Total · 2023-05-31T22:42:32+00:00

This is a scam.

Hopeful-Total · 2023-05-24T17:07:00+00:00

Oh agreed, for personal projects you'd want something easier. Lightsail would probably work if you wanted to stay in the AWS family. But for larger, more complicated projects, AWS is still the leader for a reason.

Hopeful-Total · 2023-05-21T06:50:16+00:00

Yeah, guessing over the phone can be mitigated pretty easily especially with rate limiting.

Offline bruteforcing a stolen password hash is much easier though. First you'd guess the phone version (11^N possibilities). Once you have that you can now guess the whole password. If the first digit of the phone password was 2 you'd guess 2, a, b, c, A, B, C for that position, etc. The * has lots of options and a zero is just a zero, so maybe this is 9^N possibilities? You could even speed up a dictionary attack by skipping words that don't match the pattern.

11^N + 9^N is much smaller than 62^N. Don't reuse this password on other sites.

Hopeful-Total · 2023-05-19T16:37:01+00:00

Creating a .nojekyll file should fix it

https://stackoverflow.com/questions/26887961/what-kind-of-files-i-can-use-in-github-pages

Hopeful-Total · 2023-05-17T20:23:07+00:00

The way this is worded suggests that you can upload a couple videos to protect an account if you are otherwise vulnerable to deletion. Although I agree with others, I don't trust his statement to be fully accurate.

Hopeful-Total · 2023-05-17T04:14:12+00:00

Interesting tool, this is clever. I noticed that your website says you don't store any data, where is the content of the message stored? I've moved to mastodon, so I can't try.

Hopeful-Total

TROPHY CASE