3 ms·

They use the same key and iv for every user What dev sits down, starts writing code, and thinks something like this is a good idea? Not to mention all the ot

by beardog 10y ago

They use the same key and iv for every user What dev sits down, starts writing code, and thinks something like this is a good idea? Not to mention all the other problematic choices.

kk_cz 10y ago
- hey dude, what is this "key" parameter? - IDK, just copy this code from the stackoverflow, it works for me
blowski 10y ago
Developers at agencies with extremely tight deadlines. 'Caring' brings no revenue and if it means you miss the deadline, it actually means less revenue. Thus agency developers tend to implement the bare minimum to show it working. Everything else is chargable later.
ianamartin 10y ago
You ask this question, but it seems like you don't know how the real world works. In a lot of places, you aren't asked to build a product. Especially if your core isn't technology. You are on a tech team that exists within the structure of a large organization that really doesn't care about technology at all. It's just a thing they want on a check list. So you get asked to throw something together to see if people like it. So you do. And you don't in your wildest dreams think that this piece of shit is going to see the light of day. It's just concept. And then the next thing you know, some assclown decides it's good. Okay great. But you didn't hear about it because the company is the size of McDonalds. Not a small startup with 6 people who all know what they are doing. So ops and infra get together and deploy this toy shit that you thought was just a joke mostly, and now you have incredible security problems. That's one way this happens. There are many others. Reality is a lot more complicated than what you are trying to suggest.
- mmahemoff 10y ago
  Also, that tech team might in another large organization (not McDonald's) in another part of the world, where any work they do has to be budgeted for, agreed on, spec'd, tested, and released through a tedious process. Someone might be casually thinking "hmmm this doesn't seem quite right" but there would be a dozen hurdles to jump from that suspicion to getting anything done about it, so they keep quiet and move onto the next project. They might never even know or care if their code went live.
  - bluedino 10y ago
    >> budgeted for, agreed on, spec'd, tested, and released through a tedious process This. You have to spec out even the most simplistic security practices when you send work to a remote team or they won't get implemented.
- Deestan 10y ago
  > So you get asked to throw something together to see if people like it. So you do. And you don't in your wildest dreams think that this piece of shit is going to see the light of day. It's just concept. One of my previous products was a custom failover application for one of our customers. It took a year on and off, with a quick prototype to see if we were on the right track ("yep looking good!"), rewriting as proper application, sending test verisons ("yep, we received it!"), getting replies back ("yep, the new update works!"), after which we decided it done and parked the project. Then came a feature request. They wanted us to change some text in the program that was annoying one of the operators. Specifically, the text "!! PROTOTYPE VERSION - DO NOT USE !!" in the window title, and the "!!PROTOTYPE VERSION - DO NOT USE!!" text in large letters on the main window. It was also called "PROTOTYPE" in the start menu launcher, but they'd helpfully managed to rename that themselves. So yeah, they were still using - in production - the initial quick test I bashed together in two days, and some CA on our end or customer representative in the middle was either horribly confused or just faking the project management part all the time.
- ngUutIaJek 10y ago
  "Not a small startup with 6 people who all know what they are doing." Another scenario is a small startup with 6 people who _don't_ know what they are doing, but the auth code has got to get written somehow. By the time the company gets big enough to have major high profile customers the person that wrote the auth code is now in a senior management position, the senior devs don't want to touch the auth code because it "works" and they know better than to break something just because a junior programmer has raised a theoretical issue they only just understand and they've never seen in the real world. (I may have been that junior programmer. I'm sure there have been more since then.)
- DonHopkins 10y ago
  I heard this happened with an air traffic control monitoring demo after 9/11.
Groxx 10y ago
I would generally assume it's much closer to "code, code, code, cookie[key] = crypt(password), code, code". Many (most?) crypto libraries have incredibly accident-prone APIs. When presented with both `crypt(input) -> encrypted` and `crypt(input, iv, nonce, secret, etc, wtf, abc | 23 << 2) -> encrypted`, which do you choose?

by beardog 10y ago

They use the same key and iv for every user What dev sits down, starts writing code, and thinks something like this is a good idea? Not to mention all the other problematic choices.

kk_cz 10y ago

- hey dude, what is this "key" parameter? - IDK, just copy this code from the stackoverflow, it works for me

blowski 10y ago

Developers at agencies with extremely tight deadlines. 'Caring' brings no revenue and if it means you miss the deadline, it actually means less revenue. Thus agency developers tend to implement the bare minimum to show it working. Everything else is chargable later.

ianamartin 10y ago

You ask this question, but it seems like you don't know how the real world works. In a lot of places, you aren't asked to build a product. Especially if your core isn't technology. You are on a tech team that exists within the structure of a large organization that really doesn't care about technology at all. It's just a thing they want on a check list. So you get asked to throw something together to see if people like it. So you do. And you don't in your wildest dreams think that this piece of shit is going to see the light of day. It's just concept. And then the next thing you know, some assclown decides it's good. Okay great. But you didn't hear about it because the company is the size of McDonalds. Not a small startup with 6 people who all know what they are doing. So ops and infra get together and deploy this toy shit that you thought was just a joke mostly, and now you have incredible security problems. That's one way this happens. There are many others. Reality is a lot more complicated than what you are trying to suggest.

mmahemoff 10y ago
Also, that tech team might in another large organization (not McDonald's) in another part of the world, where any work they do has to be budgeted for, agreed on, spec'd, tested, and released through a tedious process. Someone might be casually thinking "hmmm this doesn't seem quite right" but there would be a dozen hurdles to jump from that suspicion to getting anything done about it, so they keep quiet and move onto the next project. They might never even know or care if their code went live.
- bluedino 10y ago
  >> budgeted for, agreed on, spec'd, tested, and released through a tedious process This. You have to spec out even the most simplistic security practices when you send work to a remote team or they won't get implemented.
Deestan 10y ago
> So you get asked to throw something together to see if people like it. So you do. And you don't in your wildest dreams think that this piece of shit is going to see the light of day. It's just concept. One of my previous products was a custom failover application for one of our customers. It took a year on and off, with a quick prototype to see if we were on the right track ("yep looking good!"), rewriting as proper application, sending test verisons ("yep, we received it!"), getting replies back ("yep, the new update works!"), after which we decided it done and parked the project. Then came a feature request. They wanted us to change some text in the program that was annoying one of the operators. Specifically, the text "!! PROTOTYPE VERSION - DO NOT USE !!" in the window title, and the "!!PROTOTYPE VERSION - DO NOT USE!!" text in large letters on the main window. It was also called "PROTOTYPE" in the start menu launcher, but they'd helpfully managed to rename that themselves. So yeah, they were still using - in production - the initial quick test I bashed together in two days, and some CA on our end or customer representative in the middle was either horribly confused or just faking the project management part all the time.
ngUutIaJek 10y ago
"Not a small startup with 6 people who all know what they are doing." Another scenario is a small startup with 6 people who _don't_ know what they are doing, but the auth code has got to get written somehow. By the time the company gets big enough to have major high profile customers the person that wrote the auth code is now in a senior management position, the senior devs don't want to touch the auth code because it "works" and they know better than to break something just because a junior programmer has raised a theoretical issue they only just understand and they've never seen in the real world. (I may have been that junior programmer. I'm sure there have been more since then.)
DonHopkins 10y ago
I heard this happened with an air traffic control monitoring demo after 9/11.

Groxx 10y ago

I would generally assume it's much closer to "code, code, code, cookie[key] = crypt(password), code, code". Many (most?) crypto libraries have incredibly accident-prone APIs. When presented with both `crypt(input) -> encrypted` and `crypt(input, iv, nonce, secret, etc, wtf, abc | 23 << 2) -> encrypted`, which do you choose?