See, these government guys are different from those government guys, who have an entirely different agenda from that government branch, because it's really coming from the authority of this government office, rather than that government office, and has an entirely different chain of command with entirely different officials from an entirely different Congressional committee.
Nobody wakes up in the morning and says "Today, I'm going to oppress my fellow citizens and make their lives worse!". Instead, all the government employees work toward the common goal of "advance America's interests", according to their specific areas of expertise. One group says build a thing because it helps America, and another group says to break it because it helps America's enemies.
Apart from paranoia, there is no reason to believe that either side isn't doing their best. If you trust that the Tor researchers (stemming from DARPA and the U.S. Navy) could possibly create a secure network, and trust that the Tor project could possibly create a secure browser, then you can trust that this browser is secure. That the government who funded it is now also trying to break it has little effect on how trustworthy the software itself actually is.
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
Every signed petition form and written letter is following the same legal channel as a lobbyist. A lobbyist just opens the discussion by saying "I represent this many people associated with this organization, and they have this concern". A Washington Post op-ed piece says it well:
How many remember that, in addition, the First Amendment protects a fifth freedom -- to lobby?
Of course it doesn't use the word lobby. It calls it the right "to petition the Government for a redress of grievances." Lobbyists are people hired to do that for you, so that you can actually stay home with the kids and remain gainfully employed rather than spend your life in the corridors of Washington.
Oh, shush. Your rationality and insight is interrupting the Two Minutes Hate.
Clearly, it is the responsibility of manufacturers to ensure that every design they ever produce is conducive to users performing any conceivable repair or replacement operation, regardless of hazard, liability, functionality, or reason. Never mind that the manufacturer's system is only functional with the manufacturer's parts, or that there are other contracts (including service agreements) on other parts of the system... We could repair our electronics in 1985, and nothing should change since then!
Slashdot says this would have been good for good for consumers, so it must be good!
The hivemind couldn't be wrong, could it?
No, it must be a conspiracy of "Big Tech" lobbyists and corrupt politicians working to oppress the common man!
Please never use Microsoft as a recommended licensing model. It's never the lesser evil, but I digress...
The situation is simple. The health provider is using software without a license, and the software developer refuses to issue a license. To draw an analogy, this is really little different (legally) from a book author who contracted to allow a movie studio to use his work, but now that contract is expired. The raised questions are a little more difficult, calling into question the very nature of software as a copyrightable work.
It has long been held that executing software necessarily involves copying (from disk to memory) and often modifying (in memory) the program code, and usually produces derivative works (the output). Those actions are restricted by copyright laws, and that's what you get a license for. Open-source licenses don't really change that legal standard; they just offer perpetual licenses as the norm. Without the license, it is perfectly reasonable (from a legal perspective) that the health provider would need to stop using the software. However, it may be possible that even migrating off of the platform requires those rights, so to require the health care provider to entirely cease using the copyrighted code may be unconscionable, as it causes an inordinate expense to move to something else. On the other hand, the choice to not upgrade earlier was the health care provider's, so it wasn't an act of bad faith on the software vendor's part, and wasn't unfair when the contract was written.
From the perspective of legal precedent, forcing the vendor to provide ongoing licenses would imply that license contracts no longer necessarily expire at the end of declared terms. That would mean that creation of a copyrightable asset also becomes a liability, as licensing a piece of intellectual property may make one beholden to the customer without knowing the contract balance up front. As an alternative, allowing a legal classification for "abandonware", as so many Slashdotters are calling for, is a legal minefield.To use the earlier literary analogy, should an author's characters and stories be open for anyone to use, just because the original stories are no longer being actively published at a particular moment?
Despite Slashdot's knee-jerk reaction, the answers are subtle and nuanced. Whatever happens needs to fairly balance the needs of a high-risk consumer who made poor decisions, with a high-risk producer who is refusing to accommodate a customer. I look forward to a court's decision, and fully expect that Slashdot will fail to report on it.
I've worked in infosec. You couldn't be more wrong, but I'm quite happy that you are.
Infosec is one of those fields where, if you do everything right, nobody knows you're doing anything. You write the GPOs, balance user needs and security guidelines, and provide secure alternatives to user-developed horrors.
The infosec team brought you your corporate WPA2-protected wireless network, without requiring you to do anything other than connect to it. The infosec team has selected encrypted USB drives for corporate IT to hand out, rather than asking you to find your own. The infosec team rolled out the new filtering policy that blocked an emailed ransomware attack.
Those are the blue teams.
Then there are the red teams. Those are the penetration testers, who do everything that would be illegal... except the relevant laws all have a clause that says "without authorization", and they have authorizations. Nobody likes to talk about the pre-testing meeting where the boundaries are discussed and targets are defined. Saying you discuss attack vectors and target environments isn't as awesome as saying you hack into highly-secured top-secret government computers and get paid for it. That's also a part of the infosec field, though.
There are rock stars in any field. There are some folks who want to get their name out there, thinking that's the best way to a lucrative consulting job, just like there are software developers who think that writing a shiny new smartphone game will get them a job at Google. Maybe it works, and maybe it doesn't, but for those of us who would rather have a steady job doing boring information security, where every day you can actually see the mitigations working and the attacks getting blocked, infosec is still a great career choice.
It should be noted that vulnerability reporting is almost always without fear of prosecution, unless you actually committed a crime.
Testing the vulnerability is usually a crime.
Exploiting the vulnerability just to show how it works? Also a crime.
Breaking other unrelated laws to figure out the vulnerability? Also a crime.
Using social engineering to get access to a system where you think there's a vulnerability? Probably also a crime.
I'm not saying it's right, but it's the reality. What's not a crime is figuring out (through lawful means) what platform a service runs on, and setting up your own similar configuration or otherwise conducting hands-off research, then using that to determine candidate vulnerabilities, then reporting those for validation.
I can't see any possible way that legally prescribed and obtained drugs can be used to prosecute someone, and I don't care if they are abusing them.
"Legally prescribed" and "legally obtained" are not necessarily the same. If you have four doctors in four states prescribing you the same medication because you're reselling them, that's illegal (being obtained under false pretenses), even though each individual prescription might be legal within its state (good faith by the doctors). As for a fishing expedition, the government is actually only explicitly prevented from "unreasonable searches". If law enforcement has can lawfully see something (like for instance, if you openly dispose of a suspiciously large number of prescription bottles), they can use that evidence against you.
Similarly, they are now asking for lawful access to the databases to find suspicious prescriptions. Even if the database access is legal, it would not be direct evidence of a crime. Rather, it would be probable cause, usable to get a warrant to do more thorough searches.
We're sure that a high number of picture messages translates to a high probability of nude selfies.
...but that's not likely probable cause. You'll need to do better than that to convince a judge.
Let's just grant ourselves the ability to access everyone's phone GPS data all the time just in case someone might be ignoring the speed limits. Too bad if Speedy wasn't the one operating the vehicle at the time you saw his GPS showing 75 in a 70 zone.
This one's closer, but to actually accuse someone of a crime, all of the crime's condition must be proven to the court. Proving that Speedy was operating the vehicle will turn out to be rather difficult, and the case would be dropped.
See where your argument starts to fall apart? If you turn a blind eye to government over-reach because you find the crime they're chasing to be abhorrent then soon they are granting themselves permission to do all sorts of other things.
I'm not suggesting any blind eyes. I'm suggesting that the justice system is actually fairly robust, and can stop most abuses, as it has for the last 250 years or so. It is, of course, constantly improving, and I am not suggesting it is perfect.
The slippery slope argument isn't trotted out so frequently because it's untrue.
Yes, actually, the Slippery Slope Fallacy is very much untrue. It is only valid in cases where a positive feedback mechanism is well-defined and with no interruption mechanism, but that's very rare in practice. In all of the examples you've given here, there are existing mechanisms in place to make abuse difficult, and prevent punishing an innocent person. That's the interruption mechanism. There's also no reason to assume that allowing the government to pursue one crime will result in bypassing the debate for their power to pursue other crimes, so there's no positive feedback.
Well, yes. Those regulations are important, and regulatory compliance is part of what must be considered when finding an appropriate implementation.
As with all regulations, get a lawyer to determine exactly what is or is not necessary. I'm not an expert on the EU laws, but I wouldn't be surprised to find that they specifically exempt lawful searches by law enforcement personnel having jurisdiction, which would permit the US government to see your US-hosted data.
Those regulations may also be a reason to segregate your data. If it's cheaper to use a US-based cloud provider, you may be able to host only your private data in the EU in compliance with privacy laws, while hosting other assets with the cheaper American provider, reducing overall expenses.
Then again, maybe the simplicity of having everything in one place is the cost-effective option, with the labor savings outweighing the expense of having unnecessary protection.
I never said the analysis would be easy. I said it must be done. Nobody else can make your decisions for you and your data.
Option 1 would be legal, and I dare to say desirable.
Option 2 would be illegal and require several failures of due process (opening up the law enforcement agency to rather large lawsuits) to actually occur, and it would likely render inadmissible any evidence obtained while you "played ball".
Without defining the boundaries of what is "secure", you can't say something is "insecure". You have to determine what level of risk is acceptable to be "secure" before you start deciding that certain implementation options are "insecure".
To hijack your particular example, I could argue (with a suitable amount of paranoia) that Google, Microsoft, and DropBox could all inject malware into their client software to harvest encryption keys from your computer. You could put the keys on another server, but that would only add a layer of protection that a well-compensated mole could bypass.
Of course, that's rather ridiculous. We generally assume that Google, Microsoft, and DropBox are extremely unlikely to embed key-harvesting malware in their software, so we accept that remote risk and say their services are secure. By extension, then, any service that isn't compatible with client-side encryption is "insecure" in comparison.
Reining in the paranoia further, we must consider the sensitivity of the data being protected. For example, what is the actual risk that Google, Microsoft, or DropBox will be compromised (internally or externally) to access our data? Perhaps we're storing prototype designs. If stolen, there would be a business impact, but no regulatory or legal impact, and customers wouldn't be affected. In that case, it may not be worth the expense and hassle to require end-to-end encryption. While the risk is indeed higher than the fully-encrypted scenario, the risk is low enough that we can still consider the implementation to be "secure" against reasonable threats.
Leaving paranoia behind entirely, I'll reuse the example from my earlier post: a company's archive of already-released press releases. In this application, having information available to the public is a good thing, as surely you would want your company's legacy to be available for any positive public relations. Obviously, if the data is released (again), there is no negative impact to investors, customers, or your business. A cheap hosting provider may be the best option, even if their security only goes so far as a contract promising that if your repository is hacked, they'll pay for damages.
The problems with outsourcing come from a failure in properly assessing risk, or applying an existing implementation to something with different impact. For example, dropping medical records on a preexisting public-facing FTP site would be grossly insecure, but it's secure enough to use that public FTP site to host blank forms for patients and other agencies to download (and return via secure channels).
Oh, no! As a financial institution, the government might get my customers' financial data! You know, that same data that we send to the IRS every year...
It doesn't matter what your data is or who you want to protect it from. You always need to do a critical risk analysis, and make conscious decisions about the cost of paranoia and the impact to your business. Just because a celebrity fugitive says that the government can read your data does not mean that you actually have a security problem.
What this means is that the "cloud" is inherently insecure and that it cannot be secured. Something I have suspected since the "cloud" first became a thing.
What it really means is that IT managers need to do their jobs.
A "cloud" isn't inherently insecure any more than it's inherently insecure to host your own servers, or to have them colocated at a datacenter, or to pay an outsourced company to just handle all the computer stuff. They all have their risks, and those risks must be understood and considered before you start implementing any solutions.
It is extraordinarily lazy to simply discard an option with the excuse that "it cannot be secured", when what you really should be saying is that "it cannot be secured to meet my acceptable level of risk using the techniques of which I am aware". The latter description highlights the resolution to your problem: Do some research and learn about the risks and mitigation techniques available to you. Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release, and providing adequate recourse if they don't. Datacenters will often provide isolated space for your servers, with access restricted to only certain personnel, or even only your own employees. A cheap outsourced service provider may not provide any assurances of privacy... but you might not even need any such protection for your company's archive of already-released press releases.
In IT, this is your job. You must be aware of the risks inherent in every solution, and understand how they can be avoided, mitigated, or accepted. This analysis must happen not just for hosting consideration, but for every choice. Do you block a certain website in your firewall, or ban a particular application? How will the users respond? Will they be likely to work around the restriction in a riskier way? Will the new policy impact the business in a positive or negative way?
Know all of your options, and list all of your assets. Gather all of the information you can before you have to make a decision. That's the only way to improve your security.
First they came for the Vietnamese, and I did not speak out—
Because I was not a Vietnamese.
Then they came for the Filipino, and I did not speak out—
Because I was not a Filipino.
Then they came for the Malaysians, and I did not speak out—
Because I was not a Malaysian.
Then they came for me—and there was no one left to speak for me.
Poetry aside, there is a good reason to be concerned about territorial expansion, especially when it's projecting military power uncomfortably close to neighbors. If it continues unchecked, then if or when a war does break out, the first fighting will be to capture that nearby territory in a powerful first strike. That eliminates potential allies for opponents, and concentrates the first counterattacks on liberating the conquered territory.
That's how it worked in previous wars, at least. In a long-range modern war between superpowers, territorial expansion primarily serves as yet another target. It's another place for satellites to watch, another suspicious building, and another place that might hide another missile. Once the big powers break out their big weapons, it won't matter whose sons or daughters are in uniform. What will matter is who can keep their weapons operational long enough to fire at the enemy, and I doubt very much that anyone will care about "dignity".
I don't know about "recent", but you can see Google's latest here.
I may be mistaken (and please tell me if so) but that sure looks like a couple of dredge ships and floating pipes to build a new pile of dry land. Other Chinese-claimed islands show large piles of dirt and earth-moving equipment. One island does not appear quite so dry or quite so developed in older pictures.
Any country, or any company, or any kid with spare time can set up their own root servers, their own TLDs, and their own domains. Then with the authority of laws, policies, or a note passed around the local high school, users can be convinced to point their resolving to that custom DNS, bypassing anything the US government wants to do.
The whole notion of maintaining control of the internet is somewhat asinine.
I'll use a long passphrase comprised of multiple almost-random words (randomly generated until I get something I expect I can spell reliably).
That passphrase is stored in my password manager, where I can see it and memorize it long enough to switch to the field and type it, usually accompanied by vocal curses aimed at the programmer and his family.
You're not really wrong. In fact you're technically correct, which I have on good authority to be the best kind of correct.
TL;DR: Using passphrases is an easy way to get a secure password, but the benefit is mostly for the human user. As long as the service doesn't require words, a word-based brute-force attack isn't really more feasible. Use a password manager, and life is easy.
For consistency and clarity, let's first define the problem space: a fast (but not infinitely fast) offline brute-force attack against a password hash with no known lookup table. In essence, an attacker has managed to steal the password database from a service, and now wants to obtain your plaintext password with the goal of using it on that service. The site in question does not require the use of words in passwords, but does restrict passwords to the character set [a-zA-Z0-9], because I'm too lazy (and it's too late at night) to properly calculate larger sets (and I make no promises about the calculations I have done). For the sake of the example, let's also limit ourselves to the Second Edition of the Oxford English Dictionary, containing 200,000 words.
To be certain of breaking the password, the attacker must try every possible password to produce a matching hash. Since this takes some time (not infinitely fast), a more-secure password is one that takes more guesses before finding a possible password. That means it's a problem of combinatorics.
For the limited character set in the problem definition, we have only 62 possible characters. That means three random characters (62^3 possibilities, or 238,328) provides roughly the same security as one randomly-selected word. The example password you gave is 36 characters (and I'll ignore the difference in character set), which corresponds to 12 random words. Your random password would be roughly equivalent to a twelve-word string, requiring 3*10^64 guesses to exhaust the search space. At one quintillion guesses per second, which I believe is the current rate of Bitcoin miners, that search will take roughly 10^39 years to execute.
However, this analysis so far has glossed over one detail of the attack definition: the attacker doesn't know that the password is words. To reliably break a word-based passphrase, the attacker has to guess everything as though it were random characters. Even though a 36-character passphrase may only contain 6 words (4*10^29 possibilities of just words, broken in 10^11 years), it would still take the same 3*10^64 guesses to be certain of breaking the password. This is why it is important that a system allows complex passwords, but does not require it. If we required the password to be words, the search space would be greatly reduced, without any change to the password itself. Similarly, this is the basis for my earlier comment regarding requiring numbers. If an attacker knows that there must be a number in a password, he only needs to guess passwords that have numbers.
In a pure mathematics sense, it boils down to entropy. The more entropy a password has, the more patterns a brute-force attacker needs to try, and the more guesses it will need. Actually computing entropy is hard, but the simple rules of thumb are that requirements reduce entropy, while options increase it. The possibility that a password is a long string of words is an option, just like it's an option to have a string of random characters one third as long. As long as both are options, the brute-force attack cannot be optimized.
Now we come to the more difficult part of the analysis: reality. If we expand outside the earlier problem scope, we find that all passwords currently discussed have one common flaw. They're all used by humans. A string of six random words is pretty easy to memorize, but 36 random characters is not. That leads to people writing down passwords, or storing them insecurely electronically. If the attack can include a physical breach or malware on the user's computer, the brute-force attack can be avoided completely.
In an offline cracking scenario, the number of possibilities is what counts, not which possibility you used. That means users should have the option of simple or short passwords, but should use long ones. For ease of use (more on this later), a passphrase of several words and punctuation is appropriate. Don't mandate the use or exclusion of any particular symbols, because that reduces the search space, and similarly reduces the time to break the password. In a famous example, "correct horse battery staple" is far more resistant to brute-force attacks than something complex like "Tr0ub4dor&3".
In an online cracking scenario, uniqueness is what counts. If an attacker has harvested your password from one location, they will try to use it to access another. Make sure every password you use is unique. Dumb tricks like appending the site name to a common password are easily caught by attackers, so they don't improve security much. The best way to mitigate the risk of an online attack, then, is use a trusted password manager to create and store your passwords, so every location has a long unique password. This is the approach I use, and most of my passwords are 24+ characters, randomly generated, and all unique.
For universal access, I keep my password manager's encrypted database files in a cloud storage service that my phone can access. Even if that storage is compromised and my file is stolen, it's useless without my master password, which is of course different from every other password for any other purpose.
If you're ever designing a system to handle authentication, the best solution is to not do it. Thanks to standards like OpenID and OAuth, you can connect your services to someone else's authentication, because they're far more likely to handle it correctly.
If you must do your own authentication, use sane policies. Require long (10+ characters) passwords, but don't force numbers or symbols. Requiring a number in a password cuts the password's resistance to brute-forcing by about half (very roughly speaking, and noted in TFS). Make sure nothing in your application interferes with the use of password managers, which often use the system clipboard to copy/paste passwords. To improve user experience, avoid asking for the password at all, instead using an expiring authentication token to reinstate a previous session. The less often a user has to type their password, the less averse they'll be to having a long and secure one.
On the back end, if you must store passwords, make sure they are hashed using a modern secure algorithm (AES-256, SHA-2 or SHA-3) and salted, and do that as soon as possible in your back-end processes. No, your users do not need a way to recover their old passwords. They need a way to reset their password to a new value, and that should only happen by using two separate forms of ID (like a phone call to customer support verbally confirming security questions and an email to the address on file). Those security questions should also be as unrestricted as passwords. Allowing the user to enter open-ended prompts allow the user to use prompts that are only meaningful to them, and are thus much more difficult to find an answer on social media.
Above all else, do not take advice from others, including me and this post, without understanding the reasoning behind it. Computer security is steeped in several decades of little more than superstition, relying on "common knowledge" that often turns out to be incorrect. It may start out well-intentioned, but the implementation is usually missing a key detail, undermining the security of the whole system.
It is not for the base software functionality. It's for the optional upgrade check, which connects to the website and downloads a signed binary. If you're concerned about the integrity of the binary, compare the hashes yourself.
There are a few specific codified laws that relate, but I have yet to find a credible report of simply "carrying too much money" being a crime. Notably, it is a crime to evade financial reporting requirements (which usually start at $10,000), and that's where a lot of the confusion originates. To an unaware citizen who doesn't understand the reporting requirements, making one $15,000 transaction at a bank is the same as making two $7,500 transactions. However, the single transaction will definitely prompt the bank to ensure the correct reports are filed, while the two separate transactions may not be immediately noticed, but when the accounts are settled, the lack of a report will trigger a notice to authorities. A savvy individual who is aware of the reporting requirements (usually notified via a posting in the bank lobby) would know to make the report with the second transaction.
Similarly, having a large amount of cash on one's person is not in itself a crime, but it may serve as evidence of a crime, especially the sale of illegal goods. This leads to the sticky issue for civil forfeiture, which is that of precisely how much additional evidence is needed to determine that a crime occurred. Following the last few hundred years of precedent, an officer's "reasonable suspicion" has been held to be all that is needed, but in the wake of recent abuse and public dissatisfaction with that standard, courts are now trying to determine how to balance the need for immediate action with the need for due process.
In the United States, at least, crime rates (violent and total) have dropped steadily since a peak in 1990, and most studies on the subject indicate that reporting rates are improving. This means that even though the crime rate figures match what was seen in the mid-1970s, it's actually likely that the 1970s were worse than the data shows, but we'll never really know for certain.
The idea that "crime doesn't seem to go away and terrorism only seems to increase" is the result of a few insidious biases. First is the availability heuristic, by which we rely more on recent and emotionally-charged events more than events farther in the past or less emotional. Perhaps you've forgotten the Weather Underground, or the Unabomber? We also have confirmation bias, which is why despite actual measurements showing otherwise, crime doesn't seem to go away and terrorism seems to increase. Once you have formed the opinion that the government is either evil or stupid, you'll continue to notice and accept any report of the government's failings, while rejecting any report of successes.
With that in mind, it appears that new security measures (including reducing cash transactions) are working to reduce crime, but they are not perfect or infallible... just like every security measure ever devised.
We'll disregard the ancient rules supposedly written by deities, mostly because they're not sufficient to cover the needs of any society within the past two thousand years.
In more recent ancient history, there has been the divine right of kings. Under such a system, kings are exempt from laws because their authority is absolute, generally held to be originally granted by a deity and passed down through a bloodline (unless the ruling family fell out of favor and a new military victor gained the deity's favor, which was obvious due to that victor's victory).
There have also previously been separate rule sets for peasants and nobles, and to an extent those are still in effect in places where a society's caste system has entered its legal structure.
The term I use, "rule of man" is a more general term for a system where an individual (or group) use their sense of justice to override written rules, effectively turning every case into a battle of celebrity. That's effectively the case in rural India now, where old village councils hand out arbitrary judgments based on their whims and local politics, often resulting in harsh sexism. The core problem with any "rule of man" system is that a human lifespan is usually too short and too narrow a perspective to apply a widespread fair justice. There are a few exceptions, but it is not a reliable system.
In contrast, "rule of law" means that the law is written to be the rule. Before someone acts (as in this case, before accessing a system without authorization), they can go read the laws and find out what's legal. They can ask a lawyer for advice if needed. At no point is their fate ever left up to whether someone else thinks they're guilty or not. They can decide their own fate.
The downside to rule of law is that most laws aren't written perfectly. They don't cover every situation perfectly, and society's values change. To resolve that, the court has the ability to interpret the laws to a certain degree of freedom, but the vast majority of the law is still already written specifically, and case histories are usually public, so a judge does not need to rely on his own narrow perspective unless the dispute is an entirely new situation. Even then, parallels are drawn to previous similar situations, so we are relying as little as possible on the judgement of one person.
Ah, yes. I oppose your particular flavor of freedom, so I must be a Communist!
Why, he should have known better than...
First, he should have not been screwing around with anybody else's system without finding out exactly what the boundaries are. For instance, it might be perfectly legal to receive TETRA signals passively, but any transmission (even announcing that you're only listening) might be illegal. Seeking a lawyer's advice is recommended.
After determining exactly what is and is not legal, then he has to make a conscious choice as to whether he will break the law or not. I won't advocate either approach, but if the outlaw's path is chosen, everything else must be done under an assumed identity, completely dissociated from one's real identity. It is not easy to establish such an identity, but that's the price for flouting laws.
After that, investigation of the vulnerability may proceed. Every step should be documented, including the ones that don't lead to any desired outcome. If it's legal, you're building evidence to strengthen your upcoming presentation of your case. If it's illegal, you're building a procedure that authorized personnel can use to harden the system.
Then you go to the authorities. An outlaw would only be able to dump information to the applicable agencies, and hope they care enough to fix it on their own. With less concern for ethics, the outlaw can also disclose his research publicly, opening up the vulnerability to others' use, including the FSB and Russian army, as you mentioned. A lawful researcher, on the other hand, can have an active dialog with the agencies, including presenting the detailed description of how he did not commit any crimes. Again, a lawyer's involvement is recommended.
After that initial disclosure, one can offer to help fix the problem. The outlaw can try appearing as just an innocent bystander who read the disclosure, but it's risky. The lawful researcher can openly offer his past work as a reference. Once authorization has been obtained, the improvement process can begin. It's possible, of course, that the agency will reject the offer to help. Perhaps they like having broken systems, or perhaps it's an issue they'd rather handle internally. Regardless of why, that ends the research.
Slashdot Mirror
Yeah, that pretty much sums it up.
Why, is that a problem?
See, these government guys are different from those government guys, who have an entirely different agenda from that government branch, because it's really coming from the authority of this government office, rather than that government office, and has an entirely different chain of command with entirely different officials from an entirely different Congressional committee.
Nobody wakes up in the morning and says "Today, I'm going to oppress my fellow citizens and make their lives worse!". Instead, all the government employees work toward the common goal of "advance America's interests", according to their specific areas of expertise. One group says build a thing because it helps America, and another group says to break it because it helps America's enemies.
Apart from paranoia, there is no reason to believe that either side isn't doing their best. If you trust that the Tor researchers (stemming from DARPA and the U.S. Navy) could possibly create a secure network, and trust that the Tor project could possibly create a secure browser, then you can trust that this browser is secure. That the government who funded it is now also trying to break it has little effect on how trustworthy the software itself actually is.
Actually, it's right there in the Constitution:
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
Every signed petition form and written letter is following the same legal channel as a lobbyist. A lobbyist just opens the discussion by saying "I represent this many people associated with this organization, and they have this concern". A Washington Post op-ed piece says it well:
How many remember that, in addition, the First Amendment protects a fifth freedom -- to lobby?
Of course it doesn't use the word lobby. It calls it the right "to petition the Government for a redress of grievances." Lobbyists are people hired to do that for you, so that you can actually stay home with the kids and remain gainfully employed rather than spend your life in the corridors of Washington.
Oh, shush. Your rationality and insight is interrupting the Two Minutes Hate.
Clearly, it is the responsibility of manufacturers to ensure that every design they ever produce is conducive to users performing any conceivable repair or replacement operation, regardless of hazard, liability, functionality, or reason. Never mind that the manufacturer's system is only functional with the manufacturer's parts, or that there are other contracts (including service agreements) on other parts of the system... We could repair our electronics in 1985, and nothing should change since then!
Slashdot says this would have been good for good for consumers, so it must be good!
The hivemind couldn't be wrong, could it?
No, it must be a conspiracy of "Big Tech" lobbyists and corrupt politicians working to oppress the common man!
Please never use Microsoft as a recommended licensing model. It's never the lesser evil, but I digress...
The situation is simple. The health provider is using software without a license, and the software developer refuses to issue a license. To draw an analogy, this is really little different (legally) from a book author who contracted to allow a movie studio to use his work, but now that contract is expired. The raised questions are a little more difficult, calling into question the very nature of software as a copyrightable work.
It has long been held that executing software necessarily involves copying (from disk to memory) and often modifying (in memory) the program code, and usually produces derivative works (the output). Those actions are restricted by copyright laws, and that's what you get a license for. Open-source licenses don't really change that legal standard; they just offer perpetual licenses as the norm. Without the license, it is perfectly reasonable (from a legal perspective) that the health provider would need to stop using the software. However, it may be possible that even migrating off of the platform requires those rights, so to require the health care provider to entirely cease using the copyrighted code may be unconscionable, as it causes an inordinate expense to move to something else. On the other hand, the choice to not upgrade earlier was the health care provider's, so it wasn't an act of bad faith on the software vendor's part, and wasn't unfair when the contract was written.
From the perspective of legal precedent, forcing the vendor to provide ongoing licenses would imply that license contracts no longer necessarily expire at the end of declared terms. That would mean that creation of a copyrightable asset also becomes a liability, as licensing a piece of intellectual property may make one beholden to the customer without knowing the contract balance up front. As an alternative, allowing a legal classification for "abandonware", as so many Slashdotters are calling for, is a legal minefield.To use the earlier literary analogy, should an author's characters and stories be open for anyone to use, just because the original stories are no longer being actively published at a particular moment?
Despite Slashdot's knee-jerk reaction, the answers are subtle and nuanced. Whatever happens needs to fairly balance the needs of a high-risk consumer who made poor decisions, with a high-risk producer who is refusing to accommodate a customer. I look forward to a court's decision, and fully expect that Slashdot will fail to report on it.
I've worked in infosec. You couldn't be more wrong, but I'm quite happy that you are.
Infosec is one of those fields where, if you do everything right, nobody knows you're doing anything. You write the GPOs, balance user needs and security guidelines, and provide secure alternatives to user-developed horrors.
The infosec team brought you your corporate WPA2-protected wireless network, without requiring you to do anything other than connect to it. The infosec team has selected encrypted USB drives for corporate IT to hand out, rather than asking you to find your own. The infosec team rolled out the new filtering policy that blocked an emailed ransomware attack.
Those are the blue teams.
Then there are the red teams. Those are the penetration testers, who do everything that would be illegal... except the relevant laws all have a clause that says "without authorization", and they have authorizations. Nobody likes to talk about the pre-testing meeting where the boundaries are discussed and targets are defined. Saying you discuss attack vectors and target environments isn't as awesome as saying you hack into highly-secured top-secret government computers and get paid for it. That's also a part of the infosec field, though.
There are rock stars in any field. There are some folks who want to get their name out there, thinking that's the best way to a lucrative consulting job, just like there are software developers who think that writing a shiny new smartphone game will get them a job at Google. Maybe it works, and maybe it doesn't, but for those of us who would rather have a steady job doing boring information security, where every day you can actually see the mitigations working and the attacks getting blocked, infosec is still a great career choice.
It should be noted that vulnerability reporting is almost always without fear of prosecution, unless you actually committed a crime.
Testing the vulnerability is usually a crime.
Exploiting the vulnerability just to show how it works? Also a crime.
Breaking other unrelated laws to figure out the vulnerability? Also a crime.
Using social engineering to get access to a system where you think there's a vulnerability? Probably also a crime.
I'm not saying it's right, but it's the reality. What's not a crime is figuring out (through lawful means) what platform a service runs on, and setting up your own similar configuration or otherwise conducting hands-off research, then using that to determine candidate vulnerabilities, then reporting those for validation.
I can't see any possible way that legally prescribed and obtained drugs can be used to prosecute someone, and I don't care if they are abusing them.
"Legally prescribed" and "legally obtained" are not necessarily the same. If you have four doctors in four states prescribing you the same medication because you're reselling them, that's illegal (being obtained under false pretenses), even though each individual prescription might be legal within its state (good faith by the doctors). As for a fishing expedition, the government is actually only explicitly prevented from "unreasonable searches". If law enforcement has can lawfully see something (like for instance, if you openly dispose of a suspiciously large number of prescription bottles), they can use that evidence against you.
Similarly, they are now asking for lawful access to the databases to find suspicious prescriptions. Even if the database access is legal, it would not be direct evidence of a crime. Rather, it would be probable cause, usable to get a warrant to do more thorough searches.
We're sure that a high number of picture messages translates to a high probability of nude selfies.
...but that's not likely probable cause. You'll need to do better than that to convince a judge.
Let's just grant ourselves the ability to access everyone's phone GPS data all the time just in case someone might be ignoring the speed limits. Too bad if Speedy wasn't the one operating the vehicle at the time you saw his GPS showing 75 in a 70 zone.
This one's closer, but to actually accuse someone of a crime, all of the crime's condition must be proven to the court. Proving that Speedy was operating the vehicle will turn out to be rather difficult, and the case would be dropped.
See where your argument starts to fall apart? If you turn a blind eye to government over-reach because you find the crime they're chasing to be abhorrent then soon they are granting themselves permission to do all sorts of other things.
I'm not suggesting any blind eyes. I'm suggesting that the justice system is actually fairly robust, and can stop most abuses, as it has for the last 250 years or so. It is, of course, constantly improving, and I am not suggesting it is perfect.
The slippery slope argument isn't trotted out so frequently because it's untrue.
Yes, actually, the Slippery Slope Fallacy is very much untrue. It is only valid in cases where a positive feedback mechanism is well-defined and with no interruption mechanism, but that's very rare in practice. In all of the examples you've given here, there are existing mechanisms in place to make abuse difficult, and prevent punishing an innocent person. That's the interruption mechanism. There's also no reason to assume that allowing the government to pursue one crime will result in bypassing the debate for their power to pursue other crimes, so there's no positive feedback.
Well, yes. Those regulations are important, and regulatory compliance is part of what must be considered when finding an appropriate implementation.
As with all regulations, get a lawyer to determine exactly what is or is not necessary. I'm not an expert on the EU laws, but I wouldn't be surprised to find that they specifically exempt lawful searches by law enforcement personnel having jurisdiction, which would permit the US government to see your US-hosted data.
Those regulations may also be a reason to segregate your data. If it's cheaper to use a US-based cloud provider, you may be able to host only your private data in the EU in compliance with privacy laws, while hosting other assets with the cheaper American provider, reducing overall expenses.
Then again, maybe the simplicity of having everything in one place is the cost-effective option, with the labor savings outweighing the expense of having unnecessary protection.
I never said the analysis would be easy. I said it must be done. Nobody else can make your decisions for you and your data.
Option 1 would be legal, and I dare to say desirable.
Option 2 would be illegal and require several failures of due process (opening up the law enforcement agency to rather large lawsuits) to actually occur, and it would likely render inadmissible any evidence obtained while you "played ball".
I think you've missed the point.
Without defining the boundaries of what is "secure", you can't say something is "insecure". You have to determine what level of risk is acceptable to be "secure" before you start deciding that certain implementation options are "insecure".
To hijack your particular example, I could argue (with a suitable amount of paranoia) that Google, Microsoft, and DropBox could all inject malware into their client software to harvest encryption keys from your computer. You could put the keys on another server, but that would only add a layer of protection that a well-compensated mole could bypass.
Of course, that's rather ridiculous. We generally assume that Google, Microsoft, and DropBox are extremely unlikely to embed key-harvesting malware in their software, so we accept that remote risk and say their services are secure. By extension, then, any service that isn't compatible with client-side encryption is "insecure" in comparison.
Reining in the paranoia further, we must consider the sensitivity of the data being protected. For example, what is the actual risk that Google, Microsoft, or DropBox will be compromised (internally or externally) to access our data? Perhaps we're storing prototype designs. If stolen, there would be a business impact, but no regulatory or legal impact, and customers wouldn't be affected. In that case, it may not be worth the expense and hassle to require end-to-end encryption. While the risk is indeed higher than the fully-encrypted scenario, the risk is low enough that we can still consider the implementation to be "secure" against reasonable threats.
Leaving paranoia behind entirely, I'll reuse the example from my earlier post: a company's archive of already-released press releases. In this application, having information available to the public is a good thing, as surely you would want your company's legacy to be available for any positive public relations. Obviously, if the data is released (again), there is no negative impact to investors, customers, or your business. A cheap hosting provider may be the best option, even if their security only goes so far as a contract promising that if your repository is hacked, they'll pay for damages.
The problems with outsourcing come from a failure in properly assessing risk, or applying an existing implementation to something with different impact. For example, dropping medical records on a preexisting public-facing FTP site would be grossly insecure, but it's secure enough to use that public FTP site to host blank forms for patients and other agencies to download (and return via secure channels).
Oh, no! As a financial institution, the government might get my customers' financial data! You know, that same data that we send to the IRS every year...
It doesn't matter what your data is or who you want to protect it from. You always need to do a critical risk analysis, and make conscious decisions about the cost of paranoia and the impact to your business. Just because a celebrity fugitive says that the government can read your data does not mean that you actually have a security problem.
What this means is that the "cloud" is inherently insecure and that it cannot be secured. Something I have suspected since the "cloud" first became a thing.
What it really means is that IT managers need to do their jobs.
A "cloud" isn't inherently insecure any more than it's inherently insecure to host your own servers, or to have them colocated at a datacenter, or to pay an outsourced company to just handle all the computer stuff. They all have their risks, and those risks must be understood and considered before you start implementing any solutions.
It is extraordinarily lazy to simply discard an option with the excuse that "it cannot be secured", when what you really should be saying is that "it cannot be secured to meet my acceptable level of risk using the techniques of which I am aware". The latter description highlights the resolution to your problem: Do some research and learn about the risks and mitigation techniques available to you. Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release, and providing adequate recourse if they don't. Datacenters will often provide isolated space for your servers, with access restricted to only certain personnel, or even only your own employees. A cheap outsourced service provider may not provide any assurances of privacy... but you might not even need any such protection for your company's archive of already-released press releases.
In IT, this is your job. You must be aware of the risks inherent in every solution, and understand how they can be avoided, mitigated, or accepted. This analysis must happen not just for hosting consideration, but for every choice. Do you block a certain website in your firewall, or ban a particular application? How will the users respond? Will they be likely to work around the restriction in a riskier way? Will the new policy impact the business in a positive or negative way?
Know all of your options, and list all of your assets. Gather all of the information you can before you have to make a decision. That's the only way to improve your security.
First they came for the Vietnamese, and I did not speak out— Because I was not a Vietnamese.
Then they came for the Filipino, and I did not speak out— Because I was not a Filipino.
Then they came for the Malaysians, and I did not speak out— Because I was not a Malaysian.
Then they came for me—and there was no one left to speak for me.
Poetry aside, there is a good reason to be concerned about territorial expansion, especially when it's projecting military power uncomfortably close to neighbors. If it continues unchecked, then if or when a war does break out, the first fighting will be to capture that nearby territory in a powerful first strike. That eliminates potential allies for opponents, and concentrates the first counterattacks on liberating the conquered territory.
That's how it worked in previous wars, at least. In a long-range modern war between superpowers, territorial expansion primarily serves as yet another target. It's another place for satellites to watch, another suspicious building, and another place that might hide another missile. Once the big powers break out their big weapons, it won't matter whose sons or daughters are in uniform. What will matter is who can keep their weapons operational long enough to fire at the enemy, and I doubt very much that anyone will care about "dignity".
I don't know about "recent", but you can see Google's latest here.
I may be mistaken (and please tell me if so) but that sure looks like a couple of dredge ships and floating pipes to build a new pile of dry land. Other Chinese-claimed islands show large piles of dirt and earth-moving equipment. One island does not appear quite so dry or quite so developed in older pictures.
Any country, or any company, or any kid with spare time can set up their own root servers, their own TLDs, and their own domains. Then with the authority of laws, policies, or a note passed around the local high school, users can be convinced to point their resolving to that custom DNS, bypassing anything the US government wants to do.
The whole notion of maintaining control of the internet is somewhat asinine.
I'll use a long passphrase comprised of multiple almost-random words (randomly generated until I get something I expect I can spell reliably).
That passphrase is stored in my password manager, where I can see it and memorize it long enough to switch to the field and type it, usually accompanied by vocal curses aimed at the programmer and his family.
You're not really wrong. In fact you're technically correct, which I have on good authority to be the best kind of correct.
TL;DR: Using passphrases is an easy way to get a secure password, but the benefit is mostly for the human user. As long as the service doesn't require words, a word-based brute-force attack isn't really more feasible. Use a password manager, and life is easy.
For consistency and clarity, let's first define the problem space: a fast (but not infinitely fast) offline brute-force attack against a password hash with no known lookup table. In essence, an attacker has managed to steal the password database from a service, and now wants to obtain your plaintext password with the goal of using it on that service. The site in question does not require the use of words in passwords, but does restrict passwords to the character set [a-zA-Z0-9], because I'm too lazy (and it's too late at night) to properly calculate larger sets (and I make no promises about the calculations I have done). For the sake of the example, let's also limit ourselves to the Second Edition of the Oxford English Dictionary, containing 200,000 words.
To be certain of breaking the password, the attacker must try every possible password to produce a matching hash. Since this takes some time (not infinitely fast), a more-secure password is one that takes more guesses before finding a possible password. That means it's a problem of combinatorics.
For the limited character set in the problem definition, we have only 62 possible characters. That means three random characters (62^3 possibilities, or 238,328) provides roughly the same security as one randomly-selected word. The example password you gave is 36 characters (and I'll ignore the difference in character set), which corresponds to 12 random words. Your random password would be roughly equivalent to a twelve-word string, requiring 3*10^64 guesses to exhaust the search space. At one quintillion guesses per second, which I believe is the current rate of Bitcoin miners, that search will take roughly 10^39 years to execute.
However, this analysis so far has glossed over one detail of the attack definition: the attacker doesn't know that the password is words. To reliably break a word-based passphrase, the attacker has to guess everything as though it were random characters. Even though a 36-character passphrase may only contain 6 words (4*10^29 possibilities of just words, broken in 10^11 years), it would still take the same 3*10^64 guesses to be certain of breaking the password. This is why it is important that a system allows complex passwords, but does not require it. If we required the password to be words, the search space would be greatly reduced, without any change to the password itself. Similarly, this is the basis for my earlier comment regarding requiring numbers. If an attacker knows that there must be a number in a password, he only needs to guess passwords that have numbers.
In a pure mathematics sense, it boils down to entropy. The more entropy a password has, the more patterns a brute-force attacker needs to try, and the more guesses it will need. Actually computing entropy is hard, but the simple rules of thumb are that requirements reduce entropy, while options increase it. The possibility that a password is a long string of words is an option, just like it's an option to have a string of random characters one third as long. As long as both are options, the brute-force attack cannot be optimized.
Now we come to the more difficult part of the analysis: reality. If we expand outside the earlier problem scope, we find that all passwords currently discussed have one common flaw. They're all used by humans. A string of six random words is pretty easy to memorize, but 36 random characters is not. That leads to people writing down passwords, or storing them insecurely electronically. If the attack can include a physical breach or malware on the user's computer, the brute-force attack can be avoided completely.
In an offline cracking scenario, the number of possibilities is what counts, not which possibility you used. That means users should have the option of simple or short passwords, but should use long ones. For ease of use (more on this later), a passphrase of several words and punctuation is appropriate. Don't mandate the use or exclusion of any particular symbols, because that reduces the search space, and similarly reduces the time to break the password. In a famous example, "correct horse battery staple" is far more resistant to brute-force attacks than something complex like "Tr0ub4dor&3".
In an online cracking scenario, uniqueness is what counts. If an attacker has harvested your password from one location, they will try to use it to access another. Make sure every password you use is unique. Dumb tricks like appending the site name to a common password are easily caught by attackers, so they don't improve security much. The best way to mitigate the risk of an online attack, then, is use a trusted password manager to create and store your passwords, so every location has a long unique password. This is the approach I use, and most of my passwords are 24+ characters, randomly generated, and all unique.
For universal access, I keep my password manager's encrypted database files in a cloud storage service that my phone can access. Even if that storage is compromised and my file is stolen, it's useless without my master password, which is of course different from every other password for any other purpose.
If you're ever designing a system to handle authentication, the best solution is to not do it. Thanks to standards like OpenID and OAuth, you can connect your services to someone else's authentication, because they're far more likely to handle it correctly.
If you must do your own authentication, use sane policies. Require long (10+ characters) passwords, but don't force numbers or symbols. Requiring a number in a password cuts the password's resistance to brute-forcing by about half (very roughly speaking, and noted in TFS). Make sure nothing in your application interferes with the use of password managers, which often use the system clipboard to copy/paste passwords. To improve user experience, avoid asking for the password at all, instead using an expiring authentication token to reinstate a previous session. The less often a user has to type their password, the less averse they'll be to having a long and secure one.
On the back end, if you must store passwords, make sure they are hashed using a modern secure algorithm (AES-256, SHA-2 or SHA-3) and salted, and do that as soon as possible in your back-end processes. No, your users do not need a way to recover their old passwords. They need a way to reset their password to a new value, and that should only happen by using two separate forms of ID (like a phone call to customer support verbally confirming security questions and an email to the address on file). Those security questions should also be as unrestricted as passwords. Allowing the user to enter open-ended prompts allow the user to use prompts that are only meaningful to them, and are thus much more difficult to find an answer on social media.
Above all else, do not take advice from others, including me and this post, without understanding the reasoning behind it. Computer security is steeped in several decades of little more than superstition, relying on "common knowledge" that often turns out to be incorrect. It may start out well-intentioned, but the implementation is usually missing a key detail, undermining the security of the whole system.
I'm sorry, sir, but this is the Internet. Your facts and reasonable analysis are unwelcome here.
It is not for the base software functionality. It's for the optional upgrade check, which connects to the website and downloads a signed binary. If you're concerned about the integrity of the binary, compare the hashes yourself.
[citation needed]
There are a few specific codified laws that relate, but I have yet to find a credible report of simply "carrying too much money" being a crime. Notably, it is a crime to evade financial reporting requirements (which usually start at $10,000), and that's where a lot of the confusion originates. To an unaware citizen who doesn't understand the reporting requirements, making one $15,000 transaction at a bank is the same as making two $7,500 transactions. However, the single transaction will definitely prompt the bank to ensure the correct reports are filed, while the two separate transactions may not be immediately noticed, but when the accounts are settled, the lack of a report will trigger a notice to authorities. A savvy individual who is aware of the reporting requirements (usually notified via a posting in the bank lobby) would know to make the report with the second transaction.
Similarly, having a large amount of cash on one's person is not in itself a crime, but it may serve as evidence of a crime, especially the sale of illegal goods. This leads to the sticky issue for civil forfeiture, which is that of precisely how much additional evidence is needed to determine that a crime occurred. Following the last few hundred years of precedent, an officer's "reasonable suspicion" has been held to be all that is needed, but in the wake of recent abuse and public dissatisfaction with that standard, courts are now trying to determine how to balance the need for immediate action with the need for due process.
Or c) you have no idea what's actually happening.
In the United States, at least, crime rates (violent and total) have dropped steadily since a peak in 1990, and most studies on the subject indicate that reporting rates are improving. This means that even though the crime rate figures match what was seen in the mid-1970s, it's actually likely that the 1970s were worse than the data shows, but we'll never really know for certain.
The idea that "crime doesn't seem to go away and terrorism only seems to increase" is the result of a few insidious biases. First is the availability heuristic, by which we rely more on recent and emotionally-charged events more than events farther in the past or less emotional. Perhaps you've forgotten the Weather Underground, or the Unabomber? We also have confirmation bias, which is why despite actual measurements showing otherwise, crime doesn't seem to go away and terrorism seems to increase. Once you have formed the opinion that the government is either evil or stupid, you'll continue to notice and accept any report of the government's failings, while rejecting any report of successes.
With that in mind, it appears that new security measures (including reducing cash transactions) are working to reduce crime, but they are not perfect or infallible... just like every security measure ever devised.
Uh... there actually are.
We'll disregard the ancient rules supposedly written by deities, mostly because they're not sufficient to cover the needs of any society within the past two thousand years.
In more recent ancient history, there has been the divine right of kings. Under such a system, kings are exempt from laws because their authority is absolute, generally held to be originally granted by a deity and passed down through a bloodline (unless the ruling family fell out of favor and a new military victor gained the deity's favor, which was obvious due to that victor's victory).
There have also previously been separate rule sets for peasants and nobles, and to an extent those are still in effect in places where a society's caste system has entered its legal structure.
The term I use, "rule of man" is a more general term for a system where an individual (or group) use their sense of justice to override written rules, effectively turning every case into a battle of celebrity. That's effectively the case in rural India now, where old village councils hand out arbitrary judgments based on their whims and local politics, often resulting in harsh sexism. The core problem with any "rule of man" system is that a human lifespan is usually too short and too narrow a perspective to apply a widespread fair justice. There are a few exceptions, but it is not a reliable system.
In contrast, "rule of law" means that the law is written to be the rule. Before someone acts (as in this case, before accessing a system without authorization), they can go read the laws and find out what's legal. They can ask a lawyer for advice if needed. At no point is their fate ever left up to whether someone else thinks they're guilty or not. They can decide their own fate.
The downside to rule of law is that most laws aren't written perfectly. They don't cover every situation perfectly, and society's values change. To resolve that, the court has the ability to interpret the laws to a certain degree of freedom, but the vast majority of the law is still already written specifically, and case histories are usually public, so a judge does not need to rely on his own narrow perspective unless the dispute is an entirely new situation. Even then, parallels are drawn to previous similar situations, so we are relying as little as possible on the judgement of one person.
I am suggesting that we be wary of replacing rule of law with rule of man, regardless of how noble that man claims to be.
Spoken like a true apparatchik
Ah, yes. I oppose your particular flavor of freedom, so I must be a Communist!
Why, he should have known better than...
First, he should have not been screwing around with anybody else's system without finding out exactly what the boundaries are. For instance, it might be perfectly legal to receive TETRA signals passively, but any transmission (even announcing that you're only listening) might be illegal. Seeking a lawyer's advice is recommended.
After determining exactly what is and is not legal, then he has to make a conscious choice as to whether he will break the law or not. I won't advocate either approach, but if the outlaw's path is chosen, everything else must be done under an assumed identity, completely dissociated from one's real identity. It is not easy to establish such an identity, but that's the price for flouting laws.
After that, investigation of the vulnerability may proceed. Every step should be documented, including the ones that don't lead to any desired outcome. If it's legal, you're building evidence to strengthen your upcoming presentation of your case. If it's illegal, you're building a procedure that authorized personnel can use to harden the system.
Then you go to the authorities. An outlaw would only be able to dump information to the applicable agencies, and hope they care enough to fix it on their own. With less concern for ethics, the outlaw can also disclose his research publicly, opening up the vulnerability to others' use, including the FSB and Russian army, as you mentioned. A lawful researcher, on the other hand, can have an active dialog with the agencies, including presenting the detailed description of how he did not commit any crimes. Again, a lawyer's involvement is recommended.
After that initial disclosure, one can offer to help fix the problem. The outlaw can try appearing as just an innocent bystander who read the disclosure, but it's risky. The lawful researcher can openly offer his past work as a reference. Once authorization has been obtained, the improvement process can begin. It's possible, of course, that the agency will reject the offer to help. Perhaps they like having broken systems, or perhaps it's an issue they'd rather handle internally. Regardless of why, that ends the research.