From the 'segment of a realistic episode of a crime program':
> “So it’s an inside job?!”
> “No, the hacker got in by guessing one of the clerks’ passwords.”
> “That’s not possible, we have a password security policy in place. Brute forcing that kind of thing would take hundreds of thousands of attempts.”
> “Well, normally, yes, but the clerk was using the same password for her email, and that server got hacked, and a file with all the usernames and plaintext passwords got dumped.”
> “But everyone knows user passwords need to be stored as one-way hashes so that getting the plaintext back out of them is impossible.”
> “They were hashed, but only md5! The hackers just used a rainbow table to do the lookups.”
A password security policy could have prevented that. ;p
About half the Epic (electronic medical records) terminals I see have the password posted on the front of the terminal. Often in a nice, professional PTouch label (so presumably by IT).
I think you are saying with a password security policy you couldn't rainbow table the md5 of the password following the policy?
I'm not sure that's true anymore.
Without salts (which the third party didn't have) I'd assume many passwords the human mind can remember within workable policy rules have been compromised.
If the 3rd party had salted them, even with a common salt, the password policy probably would have worked though.
A rainbow table approach is easily defeated by length.
Whether you can remember a password depends mostly on how often you use it. If you have to type it in every day, 30 random letters aren't difficult to remember.
I can still tell you my first library card number just from the messages the library would leave when a book came in. 1000102772901.
10 billion MD5s a second should be easy. So the XKCD pass phrase goes from 550 years -> to one hour, on a normal GPU, for one person. Rainbow tables mean after that one hour on their gaming PC no one else has to do it.
Start adding in other requirements to the pass phrase the hour goes up, and perhaps you have to rent some cloud time, but only one person once has to do it once.
But, if you assume it's likely other sites use seeds, then rainbow tables are out, and length can matter again. And that's reasonable. You need to wreck as many points in the attackers chain as possible. That's the game.
> But, if you assume it's likely other sites use seeds, then rainbow tables are out, and length can matter again.
I'm not sure what you're saying here. If by seeds you mean "salts", they're not relevant -- the whole point of a rainbow table is that you precalculate the hash of every possible password. If it's salted, you'll see the salt in the plaintext and just remove it.
But a rainbow table for long passwords will develop pretty extreme storage requirements, and take a long time to compute.
> If it's salted, you'll see the salt in the plaintext and just remove it.
No. You can't use rainbow tables on salted data. Maybe when a framework has a default common salt that people forget to change.
> rainbow table for long passwords will develop pretty extreme storage requirements,
Not really, that's the point of rainbow tables. They can be reasonable, they are not lookup tables. If you are looking at large ones, they can be compacted at the expense of time.
For "CorrectHorseBatteryStaple" the rainbow table will not contain "sdfgnWlgiuwreFrglrkemnmZflgh". You map the chain to your search space. So after CorrectHorseBatteryStaple might be SimpleFineChairBook or S1mpleFineChairB00k or SimpleFine@ChairBook depending on your space.
> No. You can't use rainbow tables on salted data.
There's something about this that you're failing to understand, but I'm not sure what it is.
A rainbow table is a collection of key-value pairs. The key is a hash, and the value is input that produces that hash.
Suppose my password on a website is "password". The MD5 hash associated with that password is 5f4dcc3b5aa765d61d8327deb882cf99 . If you dump the user database and see this:
You can look up that hashed value by any number of means (it's well known) and learn that the plaintext input to the hash was "password".
If you salt the password, nothing changes. When you dump the database, you'll see this instead:
+--------------+----------------------------------+-------+
| user | password | salt |
+--------------+----------------------------------+-------+
| thaumasiotes | 9caa7f6693553ed9129bb0c7a0c8aa50 | bEanx |
+--------------+----------------------------------+-------+
Then, when you reverse the hash, you'll learn that the plaintext input was "passwordbEanx". You also know that the suffix "bEanx" is the salt, so you can log in as me using the password "password", which is "passwordbEanx" with the salt removed.
A rainbow table can tell you that 9caa7f6693553ed9129bb0c7a0c8aa50 came from "passwordbEanx" just as easily as it can tell you that 5f4dcc3b5aa765d61d8327deb882cf99 came from "password". That's what rainbow tables do.
> they are not lookup tables
This is flat wrong; that's exactly what a rainbow table is.
> For "CorrectHorseBatteryStaple" the rainbow table will not contain "sdfgnWlgiuwreFrglrkemnmZflgh". You map the chain to your search space.
This is a possibility, but it's also an admission that making a rainbow table at the desired length is infeasible. You trim the space of passwords you can look up down to something that you hope contains your target's password. Now you don't have a rainbow table up to 30 characters, you have a rainbow table for a list of common passwords.
But once you've done that, you are vulnerable to password security policies. You can no longer crack uncommon passwords, and uncommon passwords are the problem rainbow tables are meant to solve. Common passwords you can often just guess.
> Check out this [...] It explains Rainbow Tables != Lookup Tables
It explains that rainbow tables are lookup tables which use a clever method to reduce their enormous storage requirements by increasing the lookup time. That doesn't make them any less lookup tables.
> Salts might be 100 characters in length.
Absolutely. But in that case, the rainbow table would be having trouble with the length of the (salted) password, not with the fact that a salt exists. I will stipulate that a salt will automatically add extra resistance to rainbow tables (compared to no salt) while not adding any inconvenience to the user who has to enter their password. But in the context of a password security policy, what you're getting there is added convenience, not added security.
> It could be a book.
Probably not; the salt has to be stored on a per-user basis.
> bEanx actually works pretty as a fine salt, it wrecks Rainbow tables.
Only to the extent that it makes the password longer. There is no theoretical difficulty that salts cause for rainbow tables.
Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table that is full of dictionary words and previously hacked passwords with different salts.
> Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table
This is true if you're using a table, which password-cracking attacks don't do. It's not true if you use the actual password-cracking approach of guessing what the password is and then checking whether you were right. The salt doesn't impede that in any way.
'bEanx' in practice destroys every rainbow table in existence.
It's on the line probabilisticly, so I can't make a harder statement, but 20 characters (which takes the programmer 2 more seconds to smash in) takes us to computers the size of the earth conversation which ok you win, it is possible :)
> the salt has to be stored on a per-user basis.
That's of no use to stop Rainbow tables. One salt across the site is fine to destroy or not destroy Rainbow tables. Either 'bEanx' or “For Sale: Baby shoes, never worn.” will work fine commonly used on all passwords. A common salt is not great for brute force though, but that's a different topic.
> 'bEanx' in practice destroys every rainbow table in existence.
Yes, as your link (well, part 2) notes, publicly available rainbow tables are available up to 8 mixed-case characters or 10 lowercase characters. Salting with "2" is sufficient to avoid them. That is because rainbow tables cannot practically attack long passwords.
>> the salt has to be stored on a per-user basis.
> That's of no use to stop Rainbow tables.
I didn't say it was. It's a requirement of salting. Salting is unrelated to rainbow tables. Instead, it defends against comparing one user's hashed password to a second user's hashed password, which I assume is what you're referring to when you say "not great for brute force". All I said here was that the salt is unlikely to be a book, because that imposes a very large per-user storage burden.
> That is because rainbow tables cannot practically attack long passwords.
It's trivial to create a rainbow table that attacks passphrases. This statement is wrong. You example 1000102772901 is easily within rainbow tables. Trivially so, it's worse than a passphrase.
> it defends against comparing one user's hashed password to a second user's hashed password,
This has zero value.
I can only suggest you do a course on hash functions on Coursera, the mathematics is somewhat easy and interesting to know. It's fun to follow up with a Blockchain course also has very interesting mathematics around hash functions, I really enjoyed this.
I can't suggest which, the one I did isn't available, but check Google reviews there's a few out there.
>> it defends against comparing one user's hashed password to a second user's hashed password,
> This has zero value.
I find it disturbing that you would say this. The purpose of salting passwords is to block this attack. Please familiarize yourself with the field before opining on what its goals are.
Yep. I am terrified for the people who are running open-source medical devices via community-based code and reversed-engineered medical devices. Something bad is bound to happen.
I used to be terrified of that as well, until meeting many former medical device engineers in the Denver area who got out for moral reasons. However shit you think the community code is, the official code is probably worse. Like kills people and hide behind lawyers already worse.
It's not uncommon for these engineers to have a 'if I am incapacitated, do not hook me up to these devices' card in their wallet like you'd normally see for alllergies for products they've worked on.
Also, these projects were designed on purpose to circumvent or in some cases break the law, which is the wrong approach to medical device design. It's dangerous and designs kill, as you know.
See this stipulation (and control/command + f = "commercial" in paper):
27) ‘making available on the market’ means any supply of a device, other than an investigational device, for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;
Also:
46) ‘investigational device’ means a device that is assessed in a clinical investigation
Also:
1) ‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
— diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
Also:
(19) It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device. The qualification of software, either as a device or an accessory, is independent of the software's location or the type of interconnection between the software and a device.
Did people start sentences with 'Sad' like this before Trump's presidency? I don't know if it's a (an American) colloquialism I simply hadn't noticed prior to that, or a more personal quirk that caught on?
I don't mean to single out you specifically, I keep noticing it now.
Thanks, it was an honest question, something I've noticed a few times and wondered about.
I was going to say (did type) that I can't think of another word that's used in the same sort of declaratory way - but actually, as I wrote, it occurred to me that 'funny' is too.
'Funny, I just never noticed it with 'sad' until a few years ago.'
Sure, I just have inside information into some of these systems (and enough inside knowledge to be scared of their lawyers enough to not name specifics). Therac style systemic implementation issues aren't uncommon. Think handle every failure mode by panicking the OS, and the hardware fails in the wrong direction for the patient without software control.
IMO, yeah, community approaches might not be the ideal solution, but when it comes to my health it's the better of the two options I have (community that I can actually look at the implementation of vs. proprietary that I know has systemic regulatory issues and is a crap shoot on if it is actively killing people and the engineers who worked on it don't ever want it used on them). If it comes down to it I'm going to choose my health over legality every time.
In case you're wondering why you're being downvoted, a block diagram isn't a standard safety design, nor really a safety design at all per se. It is simply a connection graph of subcomponents.
Fascinating. Want to know another secret about code quality? Custom software for banks generally sucks as well. That's your money it's messing with. am: "Let's try it in production" pm: We are going to need you to write a script to put everything back where it was.
Yeah, I think the nature of the medical device development process is that with competent engineers and managers it makes it possible to develop a safe device. It does not make it guaranteed to be safe regardless of the competency of the organisation.
Openaps is a shining example of why open source medical device control is effective and necessary. Talk to the developers. Talk to the users. For every fear that "something bad is bound to happen" there are dozens of stories where bad things actually did happen because these tools did not exist.
The key to safety is that hardware itself a) shows the real state of things and b) has safety mechanisms in place such that even the most malignant control software would be no worse than poorly timed manual dosing.
It's pretty crazy. One thing that people don't realise about type 1 diabetes is that your effectiveness at blood sugar regulation basically translates into years of lifespan: the damaging effects of high blood sugar are cumulative and complications are inevitable, you can only hope to delay them as long as possible (low blood sugar is more immediately life threatening). Insulin pumps were already a huge step change in the level of regulation you could achieve, and openaps is yet another level again, which you can't get anywhere else. I don't fault anyone who uses or develops it, even in the face of the risks or legal penalties.
I doubt it's much worse than trusting your life to proprietary code written behind closed doors. Something bad usually happens every now and again.
Of course, those insulin pumps are running insecure firmware allowing for adjustments to be made remotely by an sbc (Raspberry Pi) where the OpenAPS software lives and takes measurements from a GCM. Without the insecure remote interface on those insulin pumps, OpenAPS might not exist.
I'm not sure it's moral to attack such a project built and maintained by diabetics who simply want to provide for themselves a better quality of life.
> Of course, those insulin pumps are running insecure firmware allowing for adjustments to be made remotely by an sbc (Raspberry Pi) where the OpenAPS software lives and takes measurements from a GCM. Without the insecure remote interface on those insulin pumps, OpenAPS might not exist.
This is the issue here, with a cyber to physical attack, which is bound to happen at some point, with some medical device, and this project is a huge target for something like that. This project was specifically mentioned in the book "Click Here to Kill Everybody" by renowned cybersecurity expert Bruce Schriener, too.
OpenAPS was also designed to circumvent government laws, and is not-as-legal as the creators portray it to be. For example, one of the main "advocates" calls OpenAPS an "off-label qualification" for use (in the USA), when in order for that to apply, the specific device intended to be used must be FDA approved. As you know, OpenAPS cannot be FDA approved at this point of time. This individual also illegally markets unapproved medical devices across the United States, Europe, Australia, and New Zealand, plus online, with various gatherings for it. If you look at the specific laws of those lands, it is pretty clear cut what is going on is illegal. Plus, the new EU Medical Devices Regulation applies now.
Yes, it is illegal. I am astonished that this individual has not gotten in trouble with the FDA yet.
We are sitting ducks if you think about it. If a couple university researchers can get malicious code into the Linux kernel, just imagine what well funded state actors are doing?
Part of me wishes this test had gone on for longer, and had used several bugs of varying subtlety. I'm more interested in how long a supply chain bug can live than whether you can introduce one (because I've never questioned that possibility).
The problem I've always found is the people who want to be the arbiters of trust (managers) are usually do technically incompetent or disinterested that they effectively aren't.
I've held superuser root keys I shouldn't actually have so many times because the little who technically decide if I can use them refuse to learn how to grant and remove that permission.
I notice a giant trend of new, throwaway, accounts quipping on here and on reddit about inflation. First order botting/targeting, or second order side-effects of shills hit by first order on another site?
Because you think you noticed a trend it means the first abstraction that pops into your head.
Sure, that’s how it works.
I’ve noticed a trend of people good at abstraction believing they know the state of all particles that ever were and ever will be, use emotional language to make routine cognitive moments giant feeling.
We have fostered a culture where it's not safe to hold controversial opinions under your own name. I don't think the inflation issue is sensitive enough where I am so I can come out and say that current US inflation policy is dreadful and will come to roost, but I would never give an opinion that I think could be used against me on my main account anywhere anymore.
Not everyone who disagrees with you is a paid shill. No, I will go further and say very few people are actually paid shills, and I don't like this boogeyman (though sadly shills of course also exist).
Indeed. Our superior intellect of the fifth order to ninth power above tribal humans of course obliges us annihilate them along with the stable human environment.
It’s terrible what China is doing to ethnic groups. They should chase extinction of the species itself! As if that doesn’t have old school biblical vibes. People were promised hell on Earth!
Play video games. Collect social points. Write code. Superior. Intellect echoes to fade out
This feels like a GPT3 comment, or something you'd find scrawled on the side of a van in a walrmart parking lot. Please stop lowering the overall comment quality of HN.
I don’t bother with Bitcoin; you think I have any faith in cellar dwelling computer nerds? I gots a masters, I know elastic structures. What do I need other math nerds for?
In the end they’d turn to the same old nation state for a bailout.
Y’all want to work on your art projects, fine. I see no reason to industrialize confirming mathematics operators still work.
Proper security is ensured by a validation process from a third party audit. That is expensive. For strictly internal scrutiny security is primarily the result of a proper risk analysis. Normally that means keep guessing until the software works enough and then refactor as necessary in response to some security apparatus far away from you. Same with accessibility, performance testing, and just about everything else beyond merely pushing content to screen.
Honestly. I miss the old days. I worked in intelligence at the tail end of the Cold War. We kept all our shit on paper, in a safe, and planted a couple of nice young Marines with guns in front of it. It worked well as a system - so well in fact that when the OPM got hacked and a bunch or people’s security clearance documents got leaked I was like “Well, thankfully my information couldn’t have gotten leaked, it’s on microfiche in a safe somewhere and I really doubt anyone would be stupid enough to scan all that shit into a computer.” Of course about eight months later I get a letter in the mail, lol. Yep, they put it in a computer after all, ha ha.
At the fall of the iron curtain we learned that the system you are nostalgically venerating was so thoroughly and systemically compromised by the soviets as to make those marines little more than little girls wielding daisies. The Roderick James Ramsay conviction is a good example where the breadth and depth of the penetration was so bad that we didn't even try to really get to the bottom of any of it to avoid embarrassment and political fallout.
By way of example, Rod was able to facilitate hardware level duplication (and could have easily performed neutralization though he did not) of the Permissive Action Link nuclear keys in the active german theatre which were also in locked safes on one of the largest US bases in the world behind many, many layers of armed soldiers.
Three minutes to doomsday. There are many fabrications in it (it was written by an FBI agent after all) but most can be corrected by reviewing contemporary documentation connected with the trials.
> breadth and depth of the penetration was so bad that we didn't even try to really get to the bottom of any of it
Correction: we didn't do that in the unclassified literature. PERSEREC did a deep dive and that deep dive remains behind the Green Door (same with Hanssen's, Boyce's, and Ames's, among others).
Lol, the good old "the real answers are in the classified docs". If there was any meat there it would have been leaked ages ago. Literally no one wanted to know what really happened, the answers would end too many important peoples careers.
Imagine if they were given up by a human source. That kind of thing doesn't leak until everyone is dead and buried, and even then it doesn't always get out because it gives foreign counterintelligence services some ability to assess the damage done by the source.
Imagine if they were given up by a technical collection program. Same thing.
Off topic but relevant, I wonder how many medium writers watched their readership decline and don't know that it is because medium now requires an account to read articles.
A couple of months ago I was in a Walmart...I think it was on a holiday, perhaps July 4...and I was having trouble getting help for something that was in a locked cabinet. I walked allll around the store looking for anybody to help me, and...I couldn't! So I went up to the self-checkout, where there are always at least two employees, and asked them if I could get some help. They went off for a minute and came back to tell me someone would meet me over there. Fine.
When I got my item I told the employee, "you know, there's only like 5 people working here today, everybody in this store could just up and walk out with whatever they wanted. The 73 year old guy marking ppls receipts ain't gonna tackle anybody, and I wouldn't be surprised if the company tells you not to try to stop shoplifters anyway."
She was not impressed by my powers of observation and ideas of economic self-interest.
I like self checkouts. But I also think there should be a law that all these huge stores must staff every checkout line that they build, every hour they are open for business. That would be a job-creation bill.
Years ago, I used to work a late shift, and go to a supermarket in the middle of the night that was open 24-hours. There wouldn't be a lot of customers, but there would predictably be a few, of which a couple would be buying a month's worth of groceries. And there would always be exactly one register open, and all the self-checkouts inactive.
I'm sure management didn't care if people had to wait half an hour, because they figure if you're going to go to the store in the middle of the night, you'll put up with the wait, and they don't want to pay people extra for the night shift.
> But I also think there should be a law that all these huge stores must staff every checkout line that they build, every hour they are open for business. That would be a job-creation bill.
It would also mean higher prices, because the store would have to pay for the extra payroll.
You can already choose to use a higher priced store that is better staffed if you want. If such stores don't exist, that's because people are voting with their wallets, and you are in the minority in preferring a higher price for that benefit.
More likely, those people are actually just ordering online and paying for delivery.
This is the free market economy in action. Your proposal would turn that on its head, while denying the poor the opportunity to get more for their money in return for their time.
Prices are not set based on costs. Nobody buying stuff at retail has signed a contract to pay cost plus X%. Nobody with a store has to make the same margin on every product whether essential, luxury, or junk, either.
>If such stores don't exist, that's because people are voting with their wallets
There is no voting against what doesn't exist.
>denying the poor the opportunity to get more for their money
Spending more on people with lower wages doesn't cause general price increases in the long run, precisely because a great deal of the inputs aren't coming from those people. This is HN, think of all the high paid software and other engineers who indirectly enable a modern store.
It's impossible to improve things only in the case where everyone is already equal.
In a competitive market, prices follow costs. Businesses that raise price above cost lose business to businesses that do not. And obviously businesses that price below cost fail. Margins might vary per-item because of market dynamics. But ultimately this is what is going on. This is Economics 101. If you want to claim otherwise, I think you need some extraordinary evidence here.
Whether you want to say that means prices are "set" on costs or not is semantics.
> There is no voting against what doesn't exist.
In a competitive market, what doesn't exist doesn't exist because it's not economically viable. It's not economically viable because the market doesn't want it. If you think otherwise, then maybe you should start up a business that does this - since according to you, you'll make a killing.
So, you think the gas stations are charging you the cost of gas? Fast food joints charge you according to the cost of a hamburger or a soda?
>In a competitive market, what doesn't exist doesn't exist because it's not economically viable. It's not economically viable because the market doesn't want it. If you think otherwise, then maybe you should start up a business that does this - since according to you, you'll make a killing.
This is sophistry. "The market" isn't one particular thing that exists or can exist without constraints. I suggested one more, different, better, out of thousands. That could change what is economically viable. That's the point.
Nothing is privileged about the exact situation that exists today, that will change tomorrow anyway. Except if you insist on an absurd Panglossianism.
> So, you think the gas stations are charging you the cost of gas? Fast food joints charge you according to the cost of a hamburger or a soda?
It costs more than the cost of the goods to run a business. There's also the cost of payroll (if you remember, that's the cost I said would go up leading to higher prices). And rent, or the capex for the land and building. Maintenance. Utility bills. Taxes. Regulatory compliance. The list goes on. There's also the cost of risk, such as staff illness and any adverse business conditions (a temporary downturn caused by a pandemic included, but also seasonal variations, changes in fashion, and so on).
All of that gets factored into "costs". Once it's all factored in, then yes - if the gas station is in a competitive market, then it's pricing will be approximately the same as its costs.
Again, this is Economics 101. If you really thought that these weren't included in "cost", then perhaps you need to study the subject before making absurd claims.
> The 73 year old guy marking ppls receipts ain't gonna tackle anybody, and I wouldn't be surprised if the company tells you not to try to stop shoplifters anyway.
You don't have to stop and show them your receipt.
The Honor System hasn't broken down. The problem is poorly applied technology that allows a small number of security breakdowns to be amplified. The occasional bad apple has always existed, but current technology allows a miscreant to reign havoc on a global population.
In a previous age, human activity was siloed out of necessity. The affects of a security breakdown were thus localized to a small population.
Technology allows business and government to save a few pennies by aggregating all the little silos into a few gigantic pools. One break in, and millions pay the price.
Huh. Never heard it put this way but of course you are right.
Phrased this way the solution seems pretty clear -- we need to decentralize personal information out of these 3rd party databases. No amount of security is ever going to prevent a leak at some point so it's insane to keep creating these massive databases; and every time we ratchet up the security we're actually handing power over to the State and multi-national corporations.
And how would you link these ‘decentralized databases’ together without recreating a “massive database’ ? Or do you mean destroying the current ‘massive databases’ permanently?
Data aggregation is similar to the encryption backdoor problem in computer science. This is sometimes referred to as the 'exceptional access system' problem. It is impossible to build such a system and then to ensure it is not abused or misused.
The best example of this is trying to build a system that allows law enforcement to read private data. There's no way to ensure that only law enforcement (and none other) does that.
Safety is also largely on the honor system. Not much to stop idiocy on the roads.
Now, you have legal recourse against local actors. That keeps a lot of folks acting well. But "trusting trust" is a chain that ultimately perpetuates itself.
> “Yes, well, I’m not positive on this, but one of the employees might have had too many devices and brought in a wireless hub from home, which wasn’t secured. The range of the hub reached across the street.”
> “Why didn’t anyone remove that device?!”
The correct answer is - "why didn't anyone fix this issue for the employee?"
It's also not, a wireless toaster is not required, because complex as computers are, humans are worse, it's you that's wrong if you want to second guess every employee. Cost it up and give the $ figure to the manager if it's too hard to help them within current policy.
This part of the breach was the IT departments fault if you want to assign blame. But just like people reuse emails and passwords because life is already too hard, IT departments also have hard jobs to do.
I had a really hard time getting past this in the article:
> Not so, as the average programmer is trained not as an operator of simple input-output machines but as a Computer Scientist. And Computer Scientists are very clever. They’ve spent a lot of time and effort in figuring out how to successfully design complex applications.
> They also have to justify the forty hours a week they sit at their desks. It simply wouldn’t be feasible for a team of four programmers to finish a six-month project in two weeks. The entire management schedule would be thrown off.
> So, we have people specializing in complex systems with a vested interest in taking a large amount of time to create something. They’re faced with a simple problem. Clearly, the goal is to fit the problem into the system and time available, which necessitates taking the simple problem and making it more complex
I almost don't even know what to say in response to this. It is such an incorrect, uncharitable, foolish view of the situation that I can't take anything else in this essay seriously.
Not to say that these tendencies don't exist, but to take that as your assumption for the whole industry? If it's so simple, start a company, do it right, and put the rest of us out of business.
89 comments
[ 3.4 ms ] story [ 139 ms ] thread> “So it’s an inside job?!”
> “No, the hacker got in by guessing one of the clerks’ passwords.”
> “That’s not possible, we have a password security policy in place. Brute forcing that kind of thing would take hundreds of thousands of attempts.”
> “Well, normally, yes, but the clerk was using the same password for her email, and that server got hacked, and a file with all the usernames and plaintext passwords got dumped.”
> “But everyone knows user passwords need to be stored as one-way hashes so that getting the plaintext back out of them is impossible.”
> “They were hashed, but only md5! The hackers just used a rainbow table to do the lookups.”
A password security policy could have prevented that. ;p
I'm not sure that's true anymore.
Without salts (which the third party didn't have) I'd assume many passwords the human mind can remember within workable policy rules have been compromised.
If the 3rd party had salted them, even with a common salt, the password policy probably would have worked though.
Whether you can remember a password depends mostly on how often you use it. If you have to type it in every day, 30 random letters aren't difficult to remember.
I can still tell you my first library card number just from the messages the library would leave when a book came in. 1000102772901.
Only somewhat true.
This XKCD is absolutely wrong - https://xkcd.com/936/
10 billion MD5s a second should be easy. So the XKCD pass phrase goes from 550 years -> to one hour, on a normal GPU, for one person. Rainbow tables mean after that one hour on their gaming PC no one else has to do it.
Start adding in other requirements to the pass phrase the hour goes up, and perhaps you have to rent some cloud time, but only one person once has to do it once.
But, if you assume it's likely other sites use seeds, then rainbow tables are out, and length can matter again. And that's reasonable. You need to wreck as many points in the attackers chain as possible. That's the game.
I'm not sure what you're saying here. If by seeds you mean "salts", they're not relevant -- the whole point of a rainbow table is that you precalculate the hash of every possible password. If it's salted, you'll see the salt in the plaintext and just remove it.
But a rainbow table for long passwords will develop pretty extreme storage requirements, and take a long time to compute.
Yep
> If it's salted, you'll see the salt in the plaintext and just remove it.
No. You can't use rainbow tables on salted data. Maybe when a framework has a default common salt that people forget to change.
> rainbow table for long passwords will develop pretty extreme storage requirements,
Not really, that's the point of rainbow tables. They can be reasonable, they are not lookup tables. If you are looking at large ones, they can be compacted at the expense of time.
For "CorrectHorseBatteryStaple" the rainbow table will not contain "sdfgnWlgiuwreFrglrkemnmZflgh". You map the chain to your search space. So after CorrectHorseBatteryStaple might be SimpleFineChairBook or S1mpleFineChairB00k or SimpleFine@ChairBook depending on your space.
There's something about this that you're failing to understand, but I'm not sure what it is.
A rainbow table is a collection of key-value pairs. The key is a hash, and the value is input that produces that hash.
Suppose my password on a website is "password". The MD5 hash associated with that password is 5f4dcc3b5aa765d61d8327deb882cf99 . If you dump the user database and see this:
You can look up that hashed value by any number of means (it's well known) and learn that the plaintext input to the hash was "password".If you salt the password, nothing changes. When you dump the database, you'll see this instead:
Then, when you reverse the hash, you'll learn that the plaintext input was "passwordbEanx". You also know that the suffix "bEanx" is the salt, so you can log in as me using the password "password", which is "passwordbEanx" with the salt removed.A rainbow table can tell you that 9caa7f6693553ed9129bb0c7a0c8aa50 came from "passwordbEanx" just as easily as it can tell you that 5f4dcc3b5aa765d61d8327deb882cf99 came from "password". That's what rainbow tables do.
> they are not lookup tables
This is flat wrong; that's exactly what a rainbow table is.
> For "CorrectHorseBatteryStaple" the rainbow table will not contain "sdfgnWlgiuwreFrglrkemnmZflgh". You map the chain to your search space.
This is a possibility, but it's also an admission that making a rainbow table at the desired length is infeasible. You trim the space of passwords you can look up down to something that you hope contains your target's password. Now you don't have a rainbow table up to 30 characters, you have a rainbow table for a list of common passwords.
But once you've done that, you are vulnerable to password security policies. You can no longer crack uncommon passwords, and uncommon passwords are the problem rainbow tables are meant to solve. Common passwords you can often just guess.
Examples - https://api.wordpress.org/secret-key/1.1/salt/ No rainbow table will contain those.
bEanx actually works pretty as a fine salt, it wrecks Rainbow tables. But just like comments people understand salts more if they look complicated.
Check out this https://rsheasby.medium.com/rainbow-tables-probably-arent-wh... It explains Rainbow Tables != Lookup Tables
It explains that rainbow tables are lookup tables which use a clever method to reduce their enormous storage requirements by increasing the lookup time. That doesn't make them any less lookup tables.
> Salts might be 100 characters in length.
Absolutely. But in that case, the rainbow table would be having trouble with the length of the (salted) password, not with the fact that a salt exists. I will stipulate that a salt will automatically add extra resistance to rainbow tables (compared to no salt) while not adding any inconvenience to the user who has to enter their password. But in the context of a password security policy, what you're getting there is added convenience, not added security.
> It could be a book.
Probably not; the salt has to be stored on a per-user basis.
> bEanx actually works pretty as a fine salt, it wrecks Rainbow tables.
Only to the extent that it makes the password longer. There is no theoretical difficulty that salts cause for rainbow tables.
Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table that is full of dictionary words and previously hacked passwords with different salts.
This is true if you're using a table, which password-cracking attacks don't do. It's not true if you use the actual password-cracking approach of guessing what the password is and then checking whether you were right. The salt doesn't impede that in any way.
It's on the line probabilisticly, so I can't make a harder statement, but 20 characters (which takes the programmer 2 more seconds to smash in) takes us to computers the size of the earth conversation which ok you win, it is possible :)
> the salt has to be stored on a per-user basis.
That's of no use to stop Rainbow tables. One salt across the site is fine to destroy or not destroy Rainbow tables. Either 'bEanx' or “For Sale: Baby shoes, never worn.” will work fine commonly used on all passwords. A common salt is not great for brute force though, but that's a different topic.
Yes, as your link (well, part 2) notes, publicly available rainbow tables are available up to 8 mixed-case characters or 10 lowercase characters. Salting with "2" is sufficient to avoid them. That is because rainbow tables cannot practically attack long passwords.
>> the salt has to be stored on a per-user basis.
> That's of no use to stop Rainbow tables.
I didn't say it was. It's a requirement of salting. Salting is unrelated to rainbow tables. Instead, it defends against comparing one user's hashed password to a second user's hashed password, which I assume is what you're referring to when you say "not great for brute force". All I said here was that the salt is unlikely to be a book, because that imposes a very large per-user storage burden.
It's trivial to create a rainbow table that attacks passphrases. This statement is wrong. You example 1000102772901 is easily within rainbow tables. Trivially so, it's worse than a passphrase.
> it defends against comparing one user's hashed password to a second user's hashed password,
This has zero value.
I can only suggest you do a course on hash functions on Coursera, the mathematics is somewhat easy and interesting to know. It's fun to follow up with a Blockchain course also has very interesting mathematics around hash functions, I really enjoyed this.
I can't suggest which, the one I did isn't available, but check Google reviews there's a few out there.
> This has zero value.
I find it disturbing that you would say this. The purpose of salting passwords is to block this attack. Please familiarize yourself with the field before opining on what its goals are.
Specifications and details here: https://openaps.readthedocs.io/en/latest/
The code is hosted on GitHub, and is against Microsoft's Terms and Conditions, for obvious reasons. Still, nothing is done about it.
It's not uncommon for these engineers to have a 'if I am incapacitated, do not hook me up to these devices' card in their wallet like you'd normally see for alllergies for products they've worked on.
Also, these projects were designed on purpose to circumvent or in some cases break the law, which is the wrong approach to medical device design. It's dangerous and designs kill, as you know.
See this stipulation (and control/command + f = "commercial" in paper):
27) ‘making available on the market’ means any supply of a device, other than an investigational device, for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;
Also:
46) ‘investigational device’ means a device that is assessed in a clinical investigation
Also:
1) ‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
— diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
Also:
(19) It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device. The qualification of software, either as a device or an accessory, is independent of the software's location or the type of interconnection between the software and a device.
I don't mean to single out you specifically, I keep noticing it now.
I was going to say (did type) that I can't think of another word that's used in the same sort of declaratory way - but actually, as I wrote, it occurred to me that 'funny' is too.
'Funny, I just never noticed it with 'sad' until a few years ago.'
IMO, yeah, community approaches might not be the ideal solution, but when it comes to my health it's the better of the two options I have (community that I can actually look at the implementation of vs. proprietary that I know has systemic regulatory issues and is a crap shoot on if it is actively killing people and the engineers who worked on it don't ever want it used on them). If it comes down to it I'm going to choose my health over legality every time.
This could be done to keep the professionals on their toes without resorting to relying on random unvetted software.
They could even take pull requests, as long as the company takes responsibility for them.
Thanks, I am aware of this. It's called a block diagram, and is standard safety design. See page 3: https://pdfserv.maximintegrated.com/en/an/AN4675.pdf
The key to safety is that hardware itself a) shows the real state of things and b) has safety mechanisms in place such that even the most malignant control software would be no worse than poorly timed manual dosing.
Of course, those insulin pumps are running insecure firmware allowing for adjustments to be made remotely by an sbc (Raspberry Pi) where the OpenAPS software lives and takes measurements from a GCM. Without the insecure remote interface on those insulin pumps, OpenAPS might not exist.
I'm not sure it's moral to attack such a project built and maintained by diabetics who simply want to provide for themselves a better quality of life.
This is the issue here, with a cyber to physical attack, which is bound to happen at some point, with some medical device, and this project is a huge target for something like that. This project was specifically mentioned in the book "Click Here to Kill Everybody" by renowned cybersecurity expert Bruce Schriener, too.
OpenAPS was also designed to circumvent government laws, and is not-as-legal as the creators portray it to be. For example, one of the main "advocates" calls OpenAPS an "off-label qualification" for use (in the USA), when in order for that to apply, the specific device intended to be used must be FDA approved. As you know, OpenAPS cannot be FDA approved at this point of time. This individual also illegally markets unapproved medical devices across the United States, Europe, Australia, and New Zealand, plus online, with various gatherings for it. If you look at the specific laws of those lands, it is pretty clear cut what is going on is illegal. Plus, the new EU Medical Devices Regulation applies now.
Yes, it is illegal. I am astonished that this individual has not gotten in trouble with the FDA yet.
What are the obvious reasons?
https://www.theverge.com/2021/4/22/22398156/university-minne...
I've held superuser root keys I shouldn't actually have so many times because the little who technically decide if I can use them refuse to learn how to grant and remove that permission.
We look away to “live our life” and tacitly believe others are behaving honorably.
And they all do.
Economists teach us inflation is good because if we increase worker buying power they might own more than the current landlords.
Hedge funds short stocks 200% to crater companies and make a profit.
Social media manipulates our biochemistry (arguably wasteful consumerism is built around this altogether.)
We’re undermining the security of our habitat for future people through all of this.
Everyone is acting honorably given our detailed history of being honorable people.
Sure, that’s how it works.
I’ve noticed a trend of people good at abstraction believing they know the state of all particles that ever were and ever will be, use emotional language to make routine cognitive moments giant feeling.
Like that’s just how it is for all time, man.
Not everyone who disagrees with you is a paid shill. No, I will go further and say very few people are actually paid shills, and I don't like this boogeyman (though sadly shills of course also exist).
It’s terrible what China is doing to ethnic groups. They should chase extinction of the species itself! As if that doesn’t have old school biblical vibes. People were promised hell on Earth!
Play video games. Collect social points. Write code. Superior. Intellect echoes to fade out
As a mathematician, I’m often dismayed by the fantasy and fallacy the tech crowd buys into.
Tech hype isn’t high quality content, since most software is math that was already figured out years ago.
And finding yet another math object that abides the well known order of operations is a bit quaint at this point.
None of this is bending laws of physics.
Being accurately meta about reality is redundant and repetitive.
Edit: pretty great when a FB employee complains about the state of online discourse, btw. When a paycheck depends on ones obliviousness and all that.
In the end they’d turn to the same old nation state for a bailout.
Y’all want to work on your art projects, fine. I see no reason to industrialize confirming mathematics operators still work.
By way of example, Rod was able to facilitate hardware level duplication (and could have easily performed neutralization though he did not) of the Permissive Action Link nuclear keys in the active german theatre which were also in locked safes on one of the largest US bases in the world behind many, many layers of armed soldiers.
Correction: we didn't do that in the unclassified literature. PERSEREC did a deep dive and that deep dive remains behind the Green Door (same with Hanssen's, Boyce's, and Ames's, among others).
Imagine if they were given up by a human source. That kind of thing doesn't leak until everyone is dead and buried, and even then it doesn't always get out because it gives foreign counterintelligence services some ability to assess the damage done by the source.
Imagine if they were given up by a technical collection program. Same thing.
When I got my item I told the employee, "you know, there's only like 5 people working here today, everybody in this store could just up and walk out with whatever they wanted. The 73 year old guy marking ppls receipts ain't gonna tackle anybody, and I wouldn't be surprised if the company tells you not to try to stop shoplifters anyway."
She was not impressed by my powers of observation and ideas of economic self-interest.
‘Yeah, go ahead and take it all’
Years ago, I used to work a late shift, and go to a supermarket in the middle of the night that was open 24-hours. There wouldn't be a lot of customers, but there would predictably be a few, of which a couple would be buying a month's worth of groceries. And there would always be exactly one register open, and all the self-checkouts inactive.
I'm sure management didn't care if people had to wait half an hour, because they figure if you're going to go to the store in the middle of the night, you'll put up with the wait, and they don't want to pay people extra for the night shift.
It would also mean higher prices, because the store would have to pay for the extra payroll.
You can already choose to use a higher priced store that is better staffed if you want. If such stores don't exist, that's because people are voting with their wallets, and you are in the minority in preferring a higher price for that benefit.
More likely, those people are actually just ordering online and paying for delivery.
This is the free market economy in action. Your proposal would turn that on its head, while denying the poor the opportunity to get more for their money in return for their time.
Prices are not set based on costs. Nobody buying stuff at retail has signed a contract to pay cost plus X%. Nobody with a store has to make the same margin on every product whether essential, luxury, or junk, either.
>If such stores don't exist, that's because people are voting with their wallets
There is no voting against what doesn't exist.
>denying the poor the opportunity to get more for their money
Spending more on people with lower wages doesn't cause general price increases in the long run, precisely because a great deal of the inputs aren't coming from those people. This is HN, think of all the high paid software and other engineers who indirectly enable a modern store.
It's impossible to improve things only in the case where everyone is already equal.
In a competitive market, prices follow costs. Businesses that raise price above cost lose business to businesses that do not. And obviously businesses that price below cost fail. Margins might vary per-item because of market dynamics. But ultimately this is what is going on. This is Economics 101. If you want to claim otherwise, I think you need some extraordinary evidence here.
Whether you want to say that means prices are "set" on costs or not is semantics.
> There is no voting against what doesn't exist.
In a competitive market, what doesn't exist doesn't exist because it's not economically viable. It's not economically viable because the market doesn't want it. If you think otherwise, then maybe you should start up a business that does this - since according to you, you'll make a killing.
So, you think the gas stations are charging you the cost of gas? Fast food joints charge you according to the cost of a hamburger or a soda?
>In a competitive market, what doesn't exist doesn't exist because it's not economically viable. It's not economically viable because the market doesn't want it. If you think otherwise, then maybe you should start up a business that does this - since according to you, you'll make a killing.
This is sophistry. "The market" isn't one particular thing that exists or can exist without constraints. I suggested one more, different, better, out of thousands. That could change what is economically viable. That's the point.
Nothing is privileged about the exact situation that exists today, that will change tomorrow anyway. Except if you insist on an absurd Panglossianism.
It costs more than the cost of the goods to run a business. There's also the cost of payroll (if you remember, that's the cost I said would go up leading to higher prices). And rent, or the capex for the land and building. Maintenance. Utility bills. Taxes. Regulatory compliance. The list goes on. There's also the cost of risk, such as staff illness and any adverse business conditions (a temporary downturn caused by a pandemic included, but also seasonal variations, changes in fashion, and so on).
All of that gets factored into "costs". Once it's all factored in, then yes - if the gas station is in a competitive market, then it's pricing will be approximately the same as its costs.
Again, this is Economics 101. If you really thought that these weren't included in "cost", then perhaps you need to study the subject before making absurd claims.
You don't have to stop and show them your receipt.
In a previous age, human activity was siloed out of necessity. The affects of a security breakdown were thus localized to a small population.
Technology allows business and government to save a few pennies by aggregating all the little silos into a few gigantic pools. One break in, and millions pay the price.
Phrased this way the solution seems pretty clear -- we need to decentralize personal information out of these 3rd party databases. No amount of security is ever going to prevent a leak at some point so it's insane to keep creating these massive databases; and every time we ratchet up the security we're actually handing power over to the State and multi-national corporations.
The best example of this is trying to build a system that allows law enforcement to read private data. There's no way to ensure that only law enforcement (and none other) does that.
Keys Under Doormats - https://www.schneier.com/wp-content/uploads/2016/09/paper-ke...
Now, you have legal recourse against local actors. That keeps a lot of folks acting well. But "trusting trust" is a chain that ultimately perpetuates itself.
I'd argue that the real "honor system" is that executables will do what you expect, and nothing more, on behalf of a user.
> “Why didn’t anyone remove that device?!”
The correct answer is - "why didn't anyone fix this issue for the employee?"
It's also not, a wireless toaster is not required, because complex as computers are, humans are worse, it's you that's wrong if you want to second guess every employee. Cost it up and give the $ figure to the manager if it's too hard to help them within current policy.
This part of the breach was the IT departments fault if you want to assign blame. But just like people reuse emails and passwords because life is already too hard, IT departments also have hard jobs to do.
I wouldn't call it a 'Honor System' as such.
> Not so, as the average programmer is trained not as an operator of simple input-output machines but as a Computer Scientist. And Computer Scientists are very clever. They’ve spent a lot of time and effort in figuring out how to successfully design complex applications.
> They also have to justify the forty hours a week they sit at their desks. It simply wouldn’t be feasible for a team of four programmers to finish a six-month project in two weeks. The entire management schedule would be thrown off.
> So, we have people specializing in complex systems with a vested interest in taking a large amount of time to create something. They’re faced with a simple problem. Clearly, the goal is to fit the problem into the system and time available, which necessitates taking the simple problem and making it more complex
I almost don't even know what to say in response to this. It is such an incorrect, uncharitable, foolish view of the situation that I can't take anything else in this essay seriously.
Not to say that these tendencies don't exist, but to take that as your assumption for the whole industry? If it's so simple, start a company, do it right, and put the rest of us out of business.
[1] https://dl.acm.org/doi/10.1145/358198.358210