HN user

dkopi

2,085 karma

Software engineer, Security researcher and entrepreneur.

Posts5
Comments333
View on HN

Not really. Every country that has weapons development also has export controls.

It isn't about believing your government is moral or good. Its about understanding that your government is responsible for the safety of citizens, and that your enemies will want to kill you (or at least kill your soldiers).

If you support export controls for security reasons, this is kind of inevitable.

The government shouldn't be forced to buy any type of military technology someone creates. But even if the government won't buy your tech, it still can be dangerous in the hands of other countries.

One could argue that if the government is preventing you from selling your tech abroad - there should be some sort of compensation for this. Others could argue that's just the cost of being in the business of weapons manufacturing.

Twitter isn't sinking. It just isn't ascending as fast as investors would like to ensure hyper growth.

While its always great for your career to be in a company that's constantly growing - sometimes being that person that can help the company do a lot more with less resources is even better for your career. When everyone's jumping ship - the people who choose to stay on-board can often be very rewarded as far as their career growth goes.

PayPal 2FA Bypass 10 years ago

This often happens when I'm travelling internationally. If I plan on buying a local sim card instead of purchasing a roaming plan - I might not have access to my SMS until I get back home.

PayPal 2FA Bypass 10 years ago

Great point. "correct horse battery staple" wouldn't be vulnerable to such an attack.

PayPal 2FA Bypass 10 years ago

Mistakes were made, and there are definitely lessons to be learned, but if we want to improve the state of security, we really need to change the way we react to these types of bugs.

If a service has an outage and a company posts a postmortem, we all think: "wow! that was an interesting bug, lets learn from this". We shouldn't be treating security issues differently.

People who make security mistakes aren't idiots. They aren't negligent. They're engineers just like us, who have tight deadlines, blindspots and mistakes. Shaming people and companies for security bugs will only cause less transparency and less sharing of information - making us all less secure.

This is a really cool bug. Kudos to the researcher for finding it, responsibly reporting it, and to paypal for fixing it in a timely fashion. Hopefully - this type of bug changes some internal processes and the way the company thinks about 2FA.

As for security questions - these are obviously insecure, and should really never be relied on. If you can opt out of security questions - do so. If you can't - just generate a random password as the answer. "I_ty/:QWuCllV?'6ILs`O12kl;d0-`1" is an excellent name for your first dog / high school. Just don't forget to use a password manager to store these.

PayPal 2FA Bypass 10 years ago

More likely along the lines of

  if ((isset($_POST["SecurityQuestion0"]) && $_POST["SecurityQuestion0"] != $answer0) || 
  (isset($_POST["SecurityQuestion1"]) && $_POST["SecurityQuestion1"] != $answer1)

Is it really a Chicken and egg situation? SF prices in the last years have skyrocketed, through out the city. The financial incentive to build is there. But there isn't massive building of new housing. That isn't because of the lack of subways. It's because of zoning laws and building regulations.

Subways make sense in dense urban areas - When a lot of people are within walking distance from the subway station.

For SF to justify extensive subway infrastructure, it needs to start building higher density neighborhoods.

The weakest link I can identify here is MITM attacks when you're sending the link.

Imagine:

  Alice generates a link. 
  Sends the link to Bob over an unencrypted/unauthenticated link.
  Mallory intercepts the link. Generates his own link and send that link to bob.
  Bob enters the confidential information on Mallory's link.
  Mallory sees the confidential information, and then sends it to Alice's original link.
The only way to prevent this type of attack is sending the link over a secure channel. But if you already have a secure channel - what's the use case?

"It's showing the extreme (clearly unacceptable) end of the spectrum to ask someone how they decide where to draw the line."

That's actually very lazy. It's shifting the burden of "drawing the line" on the other side.

It's the "well, why don't we just kill toddlers as well? Where do you draw the line?" in an abortion argument. It's the "why don't we just give 12 year old's automatic assault weapons" or "why don't we disarm the police and military as well" in a gun control debate. It's the "So why don't we just tax corporations 100% of their income" in a corporate tax debate.

I agree with the first part, it's kind of a self reinforcing decision. Intel wanted INT 3 to be for break points so they gave it a single byte instruction, and because INT 3 is a single byte instruction - it's the only one that makes sense for debug breakpoints.

Lets say you have a lot of single byte opcodes:

  40 INC EAX
  43 INC EBX
  41 INC ECX
  C3 RET
And you want to set a breakpoint on INC EAX. If you replace "40" with "CD03" - you'll overwrite INC EBX as well. That can cause your program to crash if there are control flows that end up jumping to INC EBX without going through INC EAX first.

That's the main reason why 0xCD, 0x03 isn't used.

What's even better is that breakpoints haven't really changed over that period of time. They just work.

While a lot of tech is rapidly moving and constantly changing - this is the type of fundamental knowledge that will probably prove valuable for the rest of your career.

The reason INT 3 is used is that it's the only interrupt that has a single byte opcode (0xCC). Other interrupts require two bytes: CD <interupt number>.

This makes setting a breakpoint really easy, as all you have to do is replace a single byte (and restore a single byte) where you want to place your breakpoint. INT 3 being only one byte is also important when you're setting a breakpoint instead of a another single byte instruction - your newly set breakpoint won't override the consecutive instruction, which might be jumped to somewhere else in the code.

The most important thing to remember about developer compensation, especially when comparing to more "traditional" roles, is scale.

A programmer working at a large internet company may be impacting millions upon millions of people. Building a feature that lets you collect (or save) a penny from a user every month is worth $240K a year when spread out over 2 million users. $120M when spread out over 1 billion users.

That's really my answer to the common question at the end of the post: "I don’t understand this at all and would love to hear a compelling theory for why programming “should” pay more than other similar fields, or why it should pay as much as fields that have much higher barriers to entry."

"Amazon’s awesome, but Google Cloud is built by developers, for developers, and you see it right away."

AWS is built by developers for developers as well.

Most of the complaints here about AWS aren't actually about AWS not being "for developers", but about AWS requiring a certain learning curve.

It's a perfect trade-off between power and flexibility vs agility.

While the privacy concerns are more than valid, reverse engineering is common practice in trying to copy your product.

Reverse engineering isn't inherently good or bad, it's just a tool. That tool can be used for both good and bad.

I always recommend certificate pinning in order to prevent MITM attacks. I also recommend it if you're backend API gives out a lot of information about your product's "secret ingredient".

That said - certificate pinning can often be bypassed: http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-...