The internet started sucking when it became big business, when it became "serious," when it was somehow important to trust it.
This.
Commercialization of the internet transformed internet culture into something very different, and worse.
And it also made the Internet much more useful, because there's so much of it. Those things go hand in hand. It's like the difference between quirky coffee shops and bookstores in SOHO, or Mall of America. The former is going to be much more interesting, but you can't find most of what you need. The latter is big and sanitized and commercialized, but there's very little you can't find.
You don't get scale and breadth without commercialization, because scale and breadth are expensive.
Of course, the Internet does still have the obscure, quirky and interesting, you just need to look for it.
All information about a consumer is also a liability.
Tell that to Equifax.
Well, in their case information about consumers is their entire business. Which means they should be crazy paranoid about security, because it literally is their entire reason for existence, to securely gather and disseminate -- but only when and where it's proper -- highly-personal information.
Dollars to donuts in 2 years it'll be business as usual.
Yeah...
I'm generally pretty laissez-faire, but this is an area that I think we need regulation. There should be specific, and severe, penalties for data breaches. And even more severe penalties for hiding data breaches. Keeping large amounts of data about individuals needs to be recognized as a dangerous thing to do, something to be done only when absolutely necessary, and only with extreme attention to security.
To sell it to Rachel from Cardholder Services, I expect.
What organizations have 2FA that might do this? I'm not saying there aren't any, but I can't think of any.
I don't know where Rachel from Cardholder Services got my cell phone number, but she certainly got it from somewhere.
What makes you think it's from some 2FA? Seriously, what organizations do you give your number to for 2FA? Your bank. Your email provider (e.g. Google). Can you think of one that not suffer more by being discovered to sell those numbers than they would gain?
The historical record does not back you up on this.
Red herring. Those links are about data breaches, not sales. The claim here is that organizations offering 2FA ask for your number specifically to misuse it.
Chrome vs Safari and Firefox: Chrome is 1.27% better.
Chrome vs the retarded Duo (Internet Explorer and Edge): Chrome is 45.9% better.
"Let's use the 45.9% one."
Well, if you look at vulnerabilities and hacking competitions, FF is perhaps a bit better than Edge, but Safari is far worse. I think the choice was mostly made based on what enterprises are likely to use, since enterprise security is the main focus. That means the relevant OS is Windows, and enterprises typically either (a) use what comes with the OS (IE/Edge) or (b) use Chrome. Enterprise use of FF is rare AFAICS.
My opinion on the research itself: A quick scan on the document doesn't have mention of "Punycode", which was a semi-recent vulnerability which is rather important.
This isn't that type of security analysis. It doesn't assess known vulnerabilities, but instead analyzes organizational and architectural characteristics to determine how likely the browsers are to resist future vulnerabilities. Both sorts of analyses are useful and informative. Rapid and effective correction of vulnerabilities discovered is an important tool for security, but so is designing for defense in depth.
To sell it to Rachel from Cardholder Services, I expect.
What organizations have 2FA that might do this? I'm not saying there aren't any, but I can't think of any.
Personally, I think you're nuts. I've been around the security business for the last 20 years, working for and consulting with many organizations that have set up 2FA for their users... and I have never, once, heard anyone suggest that it is useful for phone number harvesting.
Moreover, knowing peoples' phone numbers really isn't all that useful.
All information about a consumer is useful information, if you have enough of it. You may not know yet when it will be useful, or what it will be useful for, but if you're a big info corporation harvesting info, you want to harvest all the info you can: it will be useful someday, and once people understand how giving that info to you was a bad bad idea, they will stop giving it to you-- so you want to get it now, before they realize it.
All information about a consumer is also a liability. Lots of organizations haven't figured this out yet, but I think pretty much all of them savvy enough to be implementing 2FA understand it.
Personally, I think you're nuts. I've been around the security business for the last 20 years, working for and consulting with many organizations that have set up 2FA for their users... and I have never, once, heard anyone suggest that it is useful for phone number harvesting. Moreover, knowing peoples' phone numbers really isn't all that useful. I suppose there may be some rare situation in which it could be used to correlate information from various sources to create a more comprehensive dossier, but I can't think of a single such scenario where there wouldn't be other data elements that could be more easily and reliably used for the correlation. I guess there may be some organization out there who would sell your phone number to telemarketers, etc., but none of the organizations I deal with that use 2FA would do that. Do you have any examples of some that would?
From a security perspective I've been uncomfortable with SMS-based 2FA for a long time. I still have it enabled on a few accounts either because no other option is offered (none of the banks I use have anything other than SMS), or because I want to have SMS as a backup option, even though it's not the one I use most of the time. This research makes me think that I should stop using it as a backup, and just make sure I'm sufficiently covered in other ways.
There's an important paragraph in the introduction:
The analysis has been sponsored by Google. X41 D-Sec GmbH accepted this sponsorship on the condition
that Google would not interfere with our testing methodology or control the content of our paper. We
are aware that we could unconsciously be biased to produce results favorable to our sponsor, and have
attempted to eliminate this by being as transparent as possible about our decision-making processes and
testing methodologies.
You can read the paper yourself to determine whether they succeeded at avoiding biasing their results. One up-front question is why they didn't include Firefox. Based on public vulnerabilities and Pwn2Own and similar competitions, FF is less secure than Chrome, but often better than Edge. Safari tends to trail by a large margin, so its exclusion doesn't surprise me, nor does the exclusion of Opera and other browsers with very small market share.
It's an interesting exercise to try to solve these problems, no doubt. However, we actually have a couple of decades of serious academic research into these problems, and they're pretty well solved. You should read the Scantegrity paper: http://www.usenix.org/event/ev....
It's not the last word, I'm sure, but it's extremely good, and eminently practical.
If you've been around long enough, you need to take a little time to show the newbies how to do a CRUD screen instead of letting them reinvent the wheel and come up with Method #39 on their own. Proper coaching or even code reviews in IT seem to be rare.
Depends where you are, obviously. Where I work, every new hire is assigned a mentor, and no code can be submitted without first being reviewed and signed off both by an "owner" of the relevant codebase and by someone who focuses on code readability. But, yeah, if you're a senior developer at some place that doesn't do those things, you should exercise some leadership and start those practices. Of course, that also requires learning to play the political game, but such is life.
I like the analysis part, especially the trickier screens or flows, but want to keep a foot in the code side. Although perhaps I should let go of that final connection. It's kind of like cutting the umbilical cord to youth: I'm hesitant to admit my coding days may be finally over.
I don't mean stop coding, just stop coding the boring, repetitive stuff. Of course, that depends on what your employer builds, but changing employers is an option as well.
I've seen several dozens of way to do plain old CRUD screens over the years. Do we really need 38 ways to do the same thing and throw out #1 thru #37 to get 38?
Seems like the thing to do is to reach for bigger and more interesting problems and leave the CRUD screens to the newbies. If you've been around long enough to see so many variations, you have too much experience to be wasted on such things. At most you should be doing the code reviews.
Web browsers require HTTPS server operators to obtain a fully-qualified domain name and a certificate from a certificate authority trusted by the browser publisher. Though Let's Encrypt makes certificates available without charge to domain owners, the domain itself still requires a recurring payment to a third party. The requirement to own a domain and keep it renewed imposes an extra $15 per year (source: Gandi.net) tax on running a server inside a home LAN.
In a home LAN you can just use a self-signed certificate and add the cert to your browsers' trust stores. Or just use plain HTTP, since you don't have any concern about malware injection. If you want a domain name you can use for free locally, you can use the.invalid or.localhost TLDs, though that's orthogonal to the question of TLS.
But your issue is really unrelated to whatever WaffleMonster was talking about, because the discussion was about a context in which ISPs, et al, could do injection attacks, not a home LAN.
I get that we're talking about security here, and trust, but I personally see a high cost. Plain HTTP is great. HTTPS is a moving target, and seems like it will remain so.
Web security is a moving target, and will remain so, and that applies to plain HTTP as much as to HTTPS. Your computer with eight year-old chrome is a security breach waiting to happen. You could browse some site with malware that compromises your browser, compromises the machine, then attacks everything else in your home network that is accessible from that machine.
Using unpatched (and unpatchable!) software is just a bad idea. If HTTPS changes forces you to keep things closer to current, that's a feature, not a bug.
Many sites don't need https since there's not much to protect in the communication when people just look at memes and pictures of cats.
You're making the common error of believing that the purpose of TLS is to protect the secrecy of the content stream, but that's only one half of it, and in most cases the less important half. The other goal is to ensure the integrity of the content stream, not because your cat pictures are important but because browsers are too big and too complex to secure effectively. TLS ensures that no one can inject anything malicious (or even anything annoying) into your stream of cat pictures. Of course, the site you're getting the pictures from could be malicious (and/or annoying), but with TLS you only have to worry about the origin site, not every network hop between it and you.
Oh, you also have to worry about entities capable of and willing to create bogus site certificates. That's an inherently self-limiting problem, though, because unless it's kept very rare, use of bogus certs will be noticed and the compromised root certs stripped from browsers. Entities who do those sorts of attacks have to limit their use to specific, important cases.
What's the point of laboring like a slave through your life, when you can coast through it with just enough minimal effort?
The point is that putting in more effort will probably give you a better life, in at least two ways. One, you'll be rewarded in terms of career position, giving you more flexibility in what you do during your working hours, including opportunities to do work that is more intellectually and emotionally satisfying. Two, you'll be rewarded financially, giving you more flexibility in what you during your non-working hours, including the opportunity to spend less of your life working, if that's what you want.
A third point is that coasting with minimal effort also tends to be pretty stressful, since it usually means that you're always on the edge of disaster, not having worked hard enough to build a cushion. That's not necessarily the case, but it's usually the case.
the NSA (in their role of protecting the nation's data infrastructure, not their role of spying on everyone -- two very different organizations within the NSA)
Or so the NSA would have you believe...
I've worked closely with people from both organizations. They're real, though in the post-9/11 NSA the former was significantly de-emphasized and the latter radically expanded.
Slashdot Mirror
You are joking, right?
Well slightly exaggerating, perhaps. But not much.
The internet started sucking when it became big business, when it became "serious," when it was somehow important to trust it.
This.
Commercialization of the internet transformed internet culture into something very different, and worse.
And it also made the Internet much more useful, because there's so much of it. Those things go hand in hand. It's like the difference between quirky coffee shops and bookstores in SOHO, or Mall of America. The former is going to be much more interesting, but you can't find most of what you need. The latter is big and sanitized and commercialized, but there's very little you can't find.
You don't get scale and breadth without commercialization, because scale and breadth are expensive.
Of course, the Internet does still have the obscure, quirky and interesting, you just need to look for it.
It looks like having had contact with PHP comes at more of a cost than I thought.
Makes sense to me. I think I've mostly succeeded at scrubbing the PHP stains from my brain, but it's tough to be sure you've got them all.
All information about a consumer is also a liability.
Tell that to Equifax.
Well, in their case information about consumers is their entire business. Which means they should be crazy paranoid about security, because it literally is their entire reason for existence, to securely gather and disseminate -- but only when and where it's proper -- highly-personal information.
Dollars to donuts in 2 years it'll be business as usual.
Yeah...
I'm generally pretty laissez-faire, but this is an area that I think we need regulation. There should be specific, and severe, penalties for data breaches. And even more severe penalties for hiding data breaches. Keeping large amounts of data about individuals needs to be recognized as a dangerous thing to do, something to be done only when absolutely necessary, and only with extreme attention to security.
It is just an excuse to harvest your phonenumber.
For what purpose?
To sell it to Rachel from Cardholder Services, I expect.
What organizations have 2FA that might do this? I'm not saying there aren't any, but I can't think of any.
I don't know where Rachel from Cardholder Services got my cell phone number, but she certainly got it from somewhere.
What makes you think it's from some 2FA? Seriously, what organizations do you give your number to for 2FA? Your bank. Your email provider (e.g. Google). Can you think of one that not suffer more by being discovered to sell those numbers than they would gain?
The historical record does not back you up on this.
Red herring. Those links are about data breaches, not sales. The claim here is that organizations offering 2FA ask for your number specifically to misuse it.
Or move to a job where there are no boring parts.
This is probably how it went...
Chrome vs Safari and Firefox: Chrome is 1.27% better. Chrome vs the retarded Duo (Internet Explorer and Edge): Chrome is 45.9% better.
"Let's use the 45.9% one."
Well, if you look at vulnerabilities and hacking competitions, FF is perhaps a bit better than Edge, but Safari is far worse. I think the choice was mostly made based on what enterprises are likely to use, since enterprise security is the main focus. That means the relevant OS is Windows, and enterprises typically either (a) use what comes with the OS (IE/Edge) or (b) use Chrome. Enterprise use of FF is rare AFAICS.
My opinion on the research itself: A quick scan on the document doesn't have mention of "Punycode", which was a semi-recent vulnerability which is rather important.
This isn't that type of security analysis. It doesn't assess known vulnerabilities, but instead analyzes organizational and architectural characteristics to determine how likely the browsers are to resist future vulnerabilities. Both sorts of analyses are useful and informative. Rapid and effective correction of vulnerabilities discovered is an important tool for security, but so is designing for defense in depth.
It is just an excuse to harvest your phonenumber.
For what purpose?
To sell it to Rachel from Cardholder Services, I expect.
What organizations have 2FA that might do this? I'm not saying there aren't any, but I can't think of any.
Personally, I think you're nuts. I've been around the security business for the last 20 years, working for and consulting with many organizations that have set up 2FA for their users... and I have never, once, heard anyone suggest that it is useful for phone number harvesting. Moreover, knowing peoples' phone numbers really isn't all that useful.
All information about a consumer is useful information, if you have enough of it. You may not know yet when it will be useful, or what it will be useful for, but if you're a big info corporation harvesting info, you want to harvest all the info you can: it will be useful someday, and once people understand how giving that info to you was a bad bad idea, they will stop giving it to you-- so you want to get it now, before they realize it.
All information about a consumer is also a liability. Lots of organizations haven't figured this out yet, but I think pretty much all of them savvy enough to be implementing 2FA understand it.
It is just an excuse to harvest your phonenumber.
For what purpose?
Personally, I think you're nuts. I've been around the security business for the last 20 years, working for and consulting with many organizations that have set up 2FA for their users... and I have never, once, heard anyone suggest that it is useful for phone number harvesting. Moreover, knowing peoples' phone numbers really isn't all that useful. I suppose there may be some rare situation in which it could be used to correlate information from various sources to create a more comprehensive dossier, but I can't think of a single such scenario where there wouldn't be other data elements that could be more easily and reliably used for the correlation. I guess there may be some organization out there who would sell your phone number to telemarketers, etc., but none of the organizations I deal with that use 2FA would do that. Do you have any examples of some that would?
From a security perspective I've been uncomfortable with SMS-based 2FA for a long time. I still have it enabled on a few accounts either because no other option is offered (none of the banks I use have anything other than SMS), or because I want to have SMS as a backup option, even though it's not the one I use most of the time. This research makes me think that I should stop using it as a backup, and just make sure I'm sufficiently covered in other ways.
There's an important paragraph in the introduction:
You can read the paper yourself to determine whether they succeeded at avoiding biasing their results. One up-front question is why they didn't include Firefox. Based on public vulnerabilities and Pwn2Own and similar competitions, FF is less secure than Chrome, but often better than Edge. Safari tends to trail by a large margin, so its exclusion doesn't surprise me, nor does the exclusion of Opera and other browsers with very small market share.
to the newbies
That's a weird name for code libraries.
Even with good libraries, and tooling, there's still some manual work to be done.
It's an interesting exercise to try to solve these problems, no doubt. However, we actually have a couple of decades of serious academic research into these problems, and they're pretty well solved. You should read the Scantegrity paper: http://www.usenix.org/event/ev.... It's not the last word, I'm sure, but it's extremely good, and eminently practical.
If you've been around long enough, you need to take a little time to show the newbies how to do a CRUD screen instead of letting them reinvent the wheel and come up with Method #39 on their own. Proper coaching or even code reviews in IT seem to be rare.
Depends where you are, obviously. Where I work, every new hire is assigned a mentor, and no code can be submitted without first being reviewed and signed off both by an "owner" of the relevant codebase and by someone who focuses on code readability. But, yeah, if you're a senior developer at some place that doesn't do those things, you should exercise some leadership and start those practices. Of course, that also requires learning to play the political game, but such is life.
I like the analysis part, especially the trickier screens or flows, but want to keep a foot in the code side. Although perhaps I should let go of that final connection. It's kind of like cutting the umbilical cord to youth: I'm hesitant to admit my coding days may be finally over.
I don't mean stop coding, just stop coding the boring, repetitive stuff. Of course, that depends on what your employer builds, but changing employers is an option as well.
The guy did something illegal and is now going to jail. To my mind, the system worked as it’s supposed to in this case.
Does it have to be a problem for it to be interesting?
HTTPS everywhere has the side effect of locking us all into an upgrade cycle that I thought slashdotters in general, were against.
Not security-focused slashdotters.
I've seen several dozens of way to do plain old CRUD screens over the years. Do we really need 38 ways to do the same thing and throw out #1 thru #37 to get 38?
Seems like the thing to do is to reach for bigger and more interesting problems and leave the CRUD screens to the newbies. If you've been around long enough to see so many variations, you have too much experience to be wasted on such things. At most you should be doing the code reviews.
Web browsers require HTTPS server operators to obtain a fully-qualified domain name and a certificate from a certificate authority trusted by the browser publisher. Though Let's Encrypt makes certificates available without charge to domain owners, the domain itself still requires a recurring payment to a third party. The requirement to own a domain and keep it renewed imposes an extra $15 per year (source: Gandi.net) tax on running a server inside a home LAN.
In a home LAN you can just use a self-signed certificate and add the cert to your browsers' trust stores. Or just use plain HTTP, since you don't have any concern about malware injection. If you want a domain name you can use for free locally, you can use the .invalid or .localhost TLDs, though that's orthogonal to the question of TLS.
But your issue is really unrelated to whatever WaffleMonster was talking about, because the discussion was about a context in which ISPs, et al, could do injection attacks, not a home LAN.
I get that we're talking about security here, and trust, but I personally see a high cost. Plain HTTP is great. HTTPS is a moving target, and seems like it will remain so.
Web security is a moving target, and will remain so, and that applies to plain HTTP as much as to HTTPS. Your computer with eight year-old chrome is a security breach waiting to happen. You could browse some site with malware that compromises your browser, compromises the machine, then attacks everything else in your home network that is accessible from that machine.
Using unpatched (and unpatchable!) software is just a bad idea. If HTTPS changes forces you to keep things closer to current, that's a feature, not a bug.
Many sites don't need https since there's not much to protect in the communication when people just look at memes and pictures of cats.
You're making the common error of believing that the purpose of TLS is to protect the secrecy of the content stream, but that's only one half of it, and in most cases the less important half. The other goal is to ensure the integrity of the content stream, not because your cat pictures are important but because browsers are too big and too complex to secure effectively. TLS ensures that no one can inject anything malicious (or even anything annoying) into your stream of cat pictures. Of course, the site you're getting the pictures from could be malicious (and/or annoying), but with TLS you only have to worry about the origin site, not every network hop between it and you.
Oh, you also have to worry about entities capable of and willing to create bogus site certificates. That's an inherently self-limiting problem, though, because unless it's kept very rare, use of bogus certs will be noticed and the compromised root certs stripped from browsers. Entities who do those sorts of attacks have to limit their use to specific, important cases.
Encryption requires PERMISSION
How so? Outside of North Korea, I mean.
What's the point of laboring like a slave through your life, when you can coast through it with just enough minimal effort?
The point is that putting in more effort will probably give you a better life, in at least two ways. One, you'll be rewarded in terms of career position, giving you more flexibility in what you do during your working hours, including opportunities to do work that is more intellectually and emotionally satisfying. Two, you'll be rewarded financially, giving you more flexibility in what you during your non-working hours, including the opportunity to spend less of your life working, if that's what you want.
A third point is that coasting with minimal effort also tends to be pretty stressful, since it usually means that you're always on the edge of disaster, not having worked hard enough to build a cushion. That's not necessarily the case, but it's usually the case.
Or so the NSA would have you believe...
I've worked closely with people from both organizations. They're real, though in the post-9/11 NSA the former was significantly de-emphasized and the latter radically expanded.
Sorry, I can only read what you write, not what you mean.