Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most “mandatory requirements” in corporations are imaginary

nibblestew.blogspot.com

Post reply on HN
Print view View original

321–330 of 405 posts

Re: Most “mandatory requirements” in corporations are imaginary

#321

Post by rcoveson »

AnIdiotOnTheNet wrote: post #202
aliswe wrote: post #160

Earlier quoted context omitted.

Mandatory additional detailed info: Division by zero in floating point equals to Infinity because in a floating point data structure there is space to represent such a value. For integers, there is no such information and therefore an exception should be thrown. For a 32-bit float, the following are true: Positive infinity: 011111111(and then 23 zeroes) Negative infinity: 111111111(and then 23 zeroes) NaN: x11111111(…

Mathematically speaking though, infinity is not the correct answer to x/0 anyway. It's just a usefully incorrect result in a lot of situations.

It's not the correct answer for division of the reals. For division of IEEE 754 floats, it is the correct answer, because division in that context is defined that way.

Re: Most “mandatory requirements” in corporations are imaginary

#322

Post by vpilcx »

waheoo wrote: post #297
grogenaut wrote: post #285

Earlier quoted context omitted.

This is literally my job. Amazon calls it Dive Deep/Earn Trust. I get called in constantly to "Remove Blockers". Part of it is just understanding why the policy exists and then getting a policy modification. While it's definitely an art, it's not as hard as a lot of people think, but you can't be afraid to escalate.

More people need to read "the goal."

Who's the author? There's three different books with that title on Amazon.

Re: Most “mandatory requirements” in corporations are imaginary

#323

Post by TimTheTinker »

EVdotIO wrote: post #320
rubatuga wrote: post #310

Earlier quoted context omitted.

It was before WSL

Yes, while WSL2 has some filesystem quirks, it works pretty darn well for what I do (ruby development). I picked up a 5 Y/O 2 CPU E5 v4 Xeon workstation for 300 bucks. I've sunk in an additional 400 for an SSD, RAM and GPU, and when paired with Microsoft Remote Desktop, I've got a solid setup that allows the best of all worlds.

If ruby development is your gig, and especially if Linux is your target runtime environment, I don't understand why you'd choose anything other than Linux, unless the choice was made for you.

Speaking as a web dev on a company-issued Mac, running my local dev environment inside a Parallels Linux VM. I asked to switch to Linux but was turned down.

(Now if Microsoft released LSW, i.e. an Ubuntu-based distro with Windows syscall support via a KVM-hosted NT kernel, I very well might opt for that instead.)

Re: Most “mandatory requirements” in corporations are imaginary

#326

Post by klmadfejno »

andi999 wrote: post #65

My reason for this rule would be: if you allow consultanta to work from home, how do you make sure they are not double- selling their workhours? Like they bill you 8h, but only work 4h on your project.

Why would you care, assuming the work gets done on schedule? Billable hours is just a proxy for getting things done.

Re: Most “mandatory requirements” in corporations are imaginary

#327

Post by thaumasiotes »

the8472 wrote: post #312
thaumasiotes wrote: post #308

Earlier quoted context omitted.

> I was faced with a password "security policy" that pretty much only whitelisted SHA2 + salting for password hashing. We were using a time-hard (not memory-hard though) password hashing function instead and several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference. You can comply without downgrading by just applying the SHA2 hash after yo…

That's possible but it would mean unnecessarily changing security-critical code. I'd again have to make sure to use constant-time comparisons of the different output, migrate the existing data or require users to reset their passwords and so on. All to tick a box. Ultimately we pretty much did that, switched to scrypt which is based on sha2 and pointed to the standard saying it's sha2-based. But that does not change…

> I'd again have to make sure to use constant-time comparisons of the different output

Why? What would this mean? You have a flow like this:

1. User sends "password".

2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done.

3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password.

But even in step 3, you don't need constant-time comparisons. What purpose would they serve?

Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH.

But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.

Re: Most “mandatory requirements” in corporations are imaginary

#328

Post by Shared404 »

pak9rabid wrote: post #309
jimmaswell wrote: post #300

Earlier quoted context omitted.

That many people willingly moved to OSX? Why? Was it a graphics company?

OSX is great at getting the fuck out of the way and letting you get more work done in my experience (development work).

I think it's just what you're used to.

Put me in front of a Linux desktop, and I can just start working.

Put me in front of a Windows desktop, give me 30 minutes to set up what I need, and I can start working.

Put me in front of a Mac, and come back to me still yelling at it five hours later.

I'm sure I could learn if it was worth the time to me, but I definitely wouldn't argue that it's superior (for me personally at least).

Re: Most “mandatory requirements” in corporations are imaginary

#329

Post by kergonath »

jimmaswell wrote: post #300
robbyking wrote: post #263

Earlier quoted context omitted.

I had the opposite experience once: at my previous company we were all issued mid-tier ThinkPads. Completely out of the blue we all received an email saying we'd be given a set budget and would be able to choose any machine we wanted. We went from 100% Windows to about 80% OS X within a week. They ended up giving the old ThinkPads away. (I put Ubuntu on one and gave it to my mom.) This was in 2012 or so, and because…

That many people willingly moved to OSX? Why? Was it a graphics company?

OS X is a great platform, less frustrating to use than Windows, with lots of well-designed GUI apps, a true MS Office, and a whole UNIX under the hood.

Re: Most “mandatory requirements” in corporations are imaginary

#330

Post by icedchai »

the8472 wrote: post #108
sfifs wrote: post #25

In BigCorps, if there's a stupid requirement, there's usually a reason for the stupid requirement to be there in the first place but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. A more productive use of time would be to understand the reason for the policy, document out why it doesn't apply to your case and then a…

> but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. And appending "exceptions may be granted for equivalent or better processes"…

Are the people "enforcing" the policy going to actually look at the code? Probably not. Just tell them what they want to hear so they can check their box. If it comes up again, just tell them it was a mistake. Sorry, I thought we were using SHA2... we're really using more-secure-thing.
Post reply on HN