Getting close to the classic Monty Python line: "Those responsible for sacking the people who have just been sacked, have been sacked."
Jokes aside, stuff like this sucks because I suspect many employers will take from it the most extreme, dehumanizing lessons, e.g.: (a) make firings [edit: including lay-offs] as abrupt as possible including terminating all access immediately, (b) never give second chances to anyone with any sort of criminal record (even say decades old marijuana posession or something).
I'd prefer a more balanced version: limit unilateral access to sensitive systems in general (not just of recently-fired employees), when someone is fired immediately shut off particularly sensitive credentials if they do exist (but not their general-purpose login/email account), avoid hiring people convicted of wire fraud as sysadmins, hash your @!#$ing passwords, etc.
Where people are laid off here (Norway), they're still employed by law for 3 months. Most companies don't force you to work all that time, but it's pretty common to finish up your tasks, do offboarding etc for a few weeks. Never considered it an issue. Maybe it's a high trust society thing?
The color the director turned when he found out!! Oh man.
Sounds like he's getting paid to work on the same thing by a slightly different stakeholder.
I'd happily pay $$$$$$ to hire someone with commit access to Cloudflare, AWS or Google's codebase who could fix the goddamn bugs, let alone add new features.
This honestly sounds like the sort of thing I'd sit down with the employee, their new employer, and various "Compliance Team" members, and firm up a bit.
Sounds good for everyone.
We get our bugs fixed, $vendor gets to say "Well we have this thing that was developed in-house for BoshNet, that might solve your problem too, it's going to cost you <some comical amount>", and everyone's happy.
Who even owns the code the person is working on? Who is responsible when it goes wrong?
Haven’t laughed this hard in a long time.
Except not everything was properly documented, and it turned out the employee had given admin rights on some resources to a contractor which proceeded to wreak havoc on their behalf (the 'rm -rf' kind). Eh!
They even send the “you’re being fired” email to their personal email they have on file. Didn’t even schedule a meeting.
yeah, shit like what we're reading here is precisely why y'all need unions.
Until someone starts providing examples of software companies where the employees are unioned and clear $400k+ annum, the bar is still “no unions”.
I'm not sure there's any good way to lay off large amounts of staff (besides not getting yourself into the situation in the first place where you have to)
Someone on HN once wrote that after the dot.com bust, Yahoo! HR had 1-1 meetings with every single employee that was part of the mass layoffs back then, and they did this for hundreds of workers. Boy what I wouldn't give to go back to such state of affairs, even though I wasn't yet part of the workforce back then.
An older family friend of mine who started working in tech around 2003-2005, told me "back in my day, to get a job, you'd just send your CV to HR@corpo.com, and in 2-3 days you'd get a call asking you when you're free to come over for an interview". Now today you're lucky you get an automated reply back from 50 CVs sent, just for the opportunity to do an impersonal take home assessment as part of the seven stage interview process. It's like screaming into the void of AI bots and automated CV screening systems, while you spin the barrel of the revolver to play the next round of Russian roulette.
And the crazy part is, that when people talk about "the good old days", we're talking about events from recent history, just 10-25 years ago, that a lot of current workers experienced in their lifetime, not stuff from when boomers were kids.
The massive sudden shift in the commoditization of human workers and turning them into faceless labor resources that can be inhumanely disposed of with a keystroke, is real and noticeable to everyone, that I'm envious for you guys who are set to retire soon out of this shitshow.
What comes after this? Have we reached rock bottom, or will it get even worse?
Things can be easy or difficult at different parts of the hiring funnel.
Towards the end of covid, it was easy to convert a resume into interviews, and successful interviews into a job.
But in the 1990s the tech industry hadn't yet invented the five-interview, live-coding, culture-fit, hiring-committee gauntlet. If a hiring manager liked your resume there'd be one interview, and it wouldn't involve any coding.
What I hear about today seems crazy hard.
2021-2022 was pretty good as well.
IDK, I'm not from the US/Bay-Area, nor does my country have any big-tech/FANG jobs to distort the market for what constitutes a "high wage" in tech, it's all the same.
>in the back-half of COVID.
Sure, but Covid was only a short blip, a temporary exception, not a baseline norm for wage/job growth, like the years prior which was a longer period of getting a job was easy, like 2012-2020.
For me where I live now, the career depression I saw came in 2023 already when jobs become less abundant and harder to get, and it only got worse later when mass layoff started. So we're already 3 years in the decline, longer than the Covid boom lasted and things aren't going better yet.
I entered the workforce in around 2012-2014 and it was significantly easier to get a callback from sending a resume than it is now where it's mostly automated rejections. When I say "easy" I also mean you didn't need 7 stages of interviews to get a job back then, you'd have 2 stages and those were pretty chill and get a call back from every 2-3 resumes sent. Now you need to send dozens. I guess "easy" is relative.
>Also pay was relatively decent but much less than what you saw even 5 years ago.
Inflation also happened in that time.
There was no leetcode and the resources weren't great. The introduction of leetcode made everything super painful.
Nobody ever seems happy about how the announcement part is done though. "Wait for everyone to have 1:1" and the problem is the mass panic that starts to roll through the workday as employees wonder if they are next. "Mass announce and then engage after" makes another group upset they were told by a generic mass email. I've been at places which have gone each way and I'd honestly rather hear from the mass email myself.
> The massive sudden shift in the commoditization of human workers and turning them into faceless labor resources that can be inhumanely disposed of with a keystroke
Look up the treatment of labor during the industrial revolution. Similarly then large competitive advantages in automation lead to concentration of power in the hands of those that (not to spill the beans on where I'm going with this) controlled the machinery and means of production by way of access to capital. Collective bargaining of some form by labor was (and I would maintain, still is) a reasonable response, as is state regulation. Not to literally use the M-word* here but ... these problems aren't new, and solutions have been explored in the past (not that they were or are perfect!). As is typical in tech, we could stand to learn a bit from history when considering paths forward from the present. History may not repeat verbatim but it sure as hell rhymes.
idk, just my two cents as someone in the technical trenches who happened to fall in love with an historian. :)
* Marxist/ism. The communists certainly had/have their problems, as did Marx's analysis itself, but he wasn't wrong about there being some society-scale Problems with unfettered capitalism.
The reason they fired the whole dept. was that they were going to centralize development, as they had 200 other developers. After 5 years, they still hadn't developed a new product. Then they bought a competitor and rebranded it. The old product had to be kept running for years after. I guess they finally switched all their clients, because the web sites now open with <!--eslint-disable @angular-eslint/template/prefer-self-closing-tags-->. Who puts that in their HTML?
> Muneeb had been assembling usernames and passwords—5,400 of them taken from his own company’s network data.
https://www.usenix.org/legacy/event/lisa99/full_papers/ringe...
I worked for a Big Tech company that actually did this, and it made the transition a lot easier. You could still access corporate resources necessary for the transition (HR, benefits, internal job postings, training offerings, expense reporting, etc), check-in with colleagues 1:1 (who would be warned this person was no longer part of the org, attachments could be blocked to prevent exfil, etc), and still send/receive email internally (though external was blocked by default and required justification).
You can safeguard your corporate infrastructure without actually cutting everything off entirely and sending someone home to stew angrily about it. In fact, there might be (as yet undocumented) advantages to letting folks exist in that transition period on that segmented infrastructure, so as to identify potentially bad actors before they can do harm and see about mending bridges.
Of course all of that requires conscious investment in projects with no clear quarterly/yearly KPIs to measure cost or success against, so most employers will never remotely consider it.
You're proving my point—employers take the most extreme lesson and it's considered expected practice. They absolutely should have immediately terminated the credentials that granted unilateral access to sensitive databases. (Ideally those would never exist in the first place—there are two-person schemes. A pair of bad actors...well apparently happens according to this article...but is far more unusual.) But employers regularly (but shouldn't) terminate all access including credentials that allow last email to colleagues exchanging personal contact info or something.
This especially includes creds like root or admin level access to AWS/GCP/whatever-cloud-or-hosting-service, and other critical creds like user/password management, domain name registrations, AppleStore and GooglePlay accounts, source code repos, documentation and internal tooling, external services like observability/analytics/crash-trcking. It also keeps a current(ish) list of all clients/projects where I've had any access at all, listing things like API keys, ssh keys and bastion hosts, project or platform admin creds, as well as systems like databases (SQL and KV caches), firewall rule specific to me.
I also try to list anything else I could, if I were a malicious disgruntled ex employee, use to cause grief to the employer or their clients.
I point out in this email that if I were to be rouge, I'd most likely have intentionally left something out or left behind backdoors or timebombs, and while I am not that kind of person and I have not done those things, they owe it to themselves and their clients to have someone else senior and experienced enough to carefully audit everything to ensure I cannot access anything.
I send this from a personal email account, so I still have timestamped records of having sent it. If an ex employer ever gets hacked shortly after I leave, I want evidence I did everything I reasonably could to remind them to lock me out.
(Writing this down reminds me it's been a while since I updated this - I guess thats something I'll ned to get on to soon.)
Isn't this an unrealistically black-and-white mode of thinking? Humans are complicated and have many values and perceived responsibilities. It's not healthy for them to throw them all out and act as if they only have one responsibility that needs to be maximally upheld at all costs. They should balance their actions thoughtfully.
Meh? Sure, stuff that would help assemble a credible phishing attack, but not customer SPII or huge amounts of intellectual property or anything. If the assumption is that employees' inboxes are full of dangerous things, I would focus on fixing that.
Looking at it from Europe - it is such a weird inhumane practice.
Someone decided your position is redundant. Okay, shit happens, economic downturn, etc. Then you have extra 3-6 months of work to pass your knowledge, train replacement and document everything.
Pretty standard practice in many technology(not just IT) and finance companies in Europe as well.
>If you don't trust your people so much, why to hire them in a first place?
It's not about trust, it's about risk, and most companies operate on liability and risk mitigation. If society ran on trust alone, we wouldn't need contracts, door locks, passwords, IDs, judges, security cameras, jails, police, etc.
You can verify someone's performance at the job interview, you can't verify their trustworthiness, especially once they've learned they lost their job, even trustworthy people react irrational once emotions hit making snap decisions they'll later regret without thinking of the consequences on the spot, and you see innocent people suddenly turn vengeful or violent and break the law (just look at relationship breakups and domestic violence).
You can't predict such reactions, so best to prevent them instead of chasing damages from them later through the court system.
Put yourself in a business owner's position for a minute. Nobody wants to be the "this former employee set my building on fire after I gave his notice, by leaving him in the flammable material warehouse unsupervised, because I wanted to show him that despite the layoff I still trust him".
For some businesses and jobs the trust alone is enough, for other jobs that involve access to sensitive data or money, it's straight to paid garden leave because nobody wants to risk it.
>Then you have extra 3-6 months of work to pass your knowledge, train replacement and document everything.
Yeah, that happens sometimes like for CxO's, managers, execs who get generous golden parachutes/severance packages, but for rank and file workers in the trenches, having to show up to a workplace you know you'll soon loose, for several more months of work till it's finally over, feels like torture unless you're getting a crazy severance package. That's like your wife telling you "honey, I'm divorcing you, but I still want you to live with me for 3-6 more months, and perform your regular duties".
You can be dismissed when you have done something wrong, in which case there's no notice period but the employer has to be able to show they've followed certain rules.
You can be dismissed when you haven't done anything wrong, in which case you either get several months notice or several months pay ('in lieu of notice') or a 'voluntary settlement agreement' (more pay, negotiable terms) all subject to slightly different rules.
So a US employer can cut a UK employee's computer system access the same day, it just costs a bit.
It's just one of these rules that unfortunately in Europe allow people to view life purely as the time between jobs. I'd never tell that to someone's face but it's simply a fact that the world stops of people don't work and no matter what the ideal world looks like in your dreams, working is the only real way forward for anything. It's part of the reason why Europe is falling behind on everything.
The increased growth in USA the last decade have largely been created by means that one day will be quite costly for you (debt).
The USA under MAGA is falling apart. EU and others are actively minimizing risk by selecting non-US IT providers. EU and others are actively selecting non-US defence aystems.
I say that it is very positive to protect your citizens. Russia (sending their citizens en masse to a certain death on the front lines) and USA have more in common politically than USA and EU.
I read a news article that Orange Telecom in France was being sued by a woman they had on payroll for the last 20 years doing nothing, because due to a medical condition she suffered, she became unable to do her job, and since they couldn't fire her due to France unions and labor laws, nor did they have any available job that could fit her current condition, they just kept paying her for 20 years to do nothing at work, and now she's suing them for the depression she got to get paid for no work.
It felt like reading a Monty Python skit.
But Europe is failing due to a myriad of compounding issues and structural deficits, not just because firing workers can be a Kafkaesque nightmare in some countries. European workers' unions and labor protections were even stronger 20-25 years ago and in 2004 the Euro stock market was worth more than the US stock market, while now it's worth half the US one. But that's whole different discussion where pages have to be written to encompass the whole context and cover all aspects of European economic decline. Boiling it down to crazy labor protections would be reductionist and incorrect.
They couldn't find anything for her to do? Hard to believe, but if there's a reason not to fire her then then pay her the money she's owed and stop demanding she show up. Making someone come in with no tasks assigned is fun for a week and quickly turns into punishment detail. Putting someone on punishment detail because you're not allowed to fire them is Bad.
Unless she was allowed to stay home, in which case I take most of that back and it falls on her to go outside and find something to do. I can't find any articles with enough detail. But I'm still skeptical they actually couldn't find a job for her to do. It was 'just' paralysis on one side.
If a person's now disabled, what can a company give them to do profitably, that isn't already optimized away or automated?
There's plenty of civil servants whose jobs are just moving one paper from one room to the next just, to keep them employed. This doesn't really exist in the private sector.
It's called "mise au placard" and it's illegal. It's a technique to get people to quit by themselves, so companies don't have deal with the hassle of firing them. The lawsuit is 100% justified.
It's also very common in Japan.
If she had been hired after, it would have taken time but she would have been found unfit for work (she had epilepsy and hemiplegia), her contract terminated, and she would have most likely received a handicap pension instead.
Like there's so many other attack vectors besides an upset ex-employee.. Like all those articles about NK employees who presumably are trying very hard not to be fired. Or employees using company provided insecure email software leaving them vulnerable to ransomware et al.
It makes sense to terminate someone's high-risk credentials immediately when they're fired. But it's extremely worrying if every credential held by every employee is considered high-risk. It suggests a bigger failure. "Unilateral access to a database filled with plain-text passwords" shouldn't ever exist. "Email account filled with dangerous stuff" should at least be unusual.
Someone with an interest in scuttling your company could just as easily maintain a low profile and do it at any time. Termination forces execution into a more-predictable timeframe. Once notified, the malevolent only have opportunity to exfiltrate or sabotage whatever they can reach in the time it takes to walk them out the door.
European laws require us to give people something like two months' notice. Even then we don't trust them; we pay them their salary and tell them to stay home.
Escorting them to the door, and revoking access for the remainder of contract yet paying wages for that period seems very descent. Off course, you don't do that when the termination was triggered by employee's misbehaviour.
But, yeah - the point I was trying to make is that there is only so much you can do as an employer to protect the company while there's an infinite number of reasons for anyone to be traumatized or otherwise act erratic. Admins are always entrusted with huge power and while wariness is probably warranted, distrustfulness is IMO counterproductive and often harmful.
This seems like a self inflicted problem where the solution to the problem also made the problem worse when it happens.
If you know that you have X months of pay if you behave, then why misbehave? You'll lose out on money and get a criminal record. Meanwhile if the employer wants you gone it's free money. Everyone is happy.
You've been given enough time to find a new job. It's enough time to sit back and relax at work since you're getting paid either way.
The primary reason why people want to get revenge is because of how inhumane the entire process is.
The mass layoffs are random and impersonal, so you inherently think it is unfair and you will never agree with the reason of the layoff.
The immediate access block and security escort is a reaction and extension of the inhuame treatment.
Sadly, behaviors and expectations converge toward one another.
Eventually I tried to log into one of my old cloud accounts, to find it was only disabled since 9 days after my layoff. Pretty sloppy.
In the US, they'll terminate your access while you're on the Teams Meeting behind the scenes and if you have any gaps, issues, blips, or smudges in your resume it gets thrown into the recycle bin by some AI agent.
The most fool proof way is just to nuke the computer in its entirety.
The employee is always the last to know. This is standard fare.
Too complicated and subjective, stinks of more risk.
Also, I don't think it's dehumanizing it all (having been on the receiving end of it way back when during a layoff, and involved in the process more times than I care to count). It's standard practice for involuntary terms at all companies we work with, whether employee is IT or not. If a company is not doing this already, I'd encourage them to.
I actually think there's less risk, because it's not as narrowly focused on what a just-fired employee can do. That's not the only scenario of concern.
> Also, I don't think it's dehumanizing it all (having been on the receiving end of it way back when during a layoff, and involved in the process more times than I care to count).
Interesting. Thanks for the perspective. I've been fortunate enough to not be on the receiving end of a lay-off, knock on wood. It's happened to my teammates/reports though. Wasn't my decision. :-(
Leaving no one to say anything anymore on their behalf.
For god's sake, don't commit crimes while you're committing crimes.
Nobody should have a personal armory.
In my region of the world a crackdown on street racing started a few years ago. It continued because each night the police stopped someone, there was at least one DUI and suspended license.
Unsurprisingly those who disregard traffic rules tend to equally disregard other rules.
This article is hilarious. The two bickering brothers remind me of the guys in the Oceans movies played by Casey Affleck and Scott Caan. It’s amazing they got this close to sensitive data.
So many red flags, I can't even.
Maybe whoever runs infosec at that place should also be fired?
Which MAGAts applaud. Emptying the swamp!
> "How do I clear chat logs from LLM?"
I guess?
Windows Server has 5 years of mainstream support, 5 years of extended support, and then an extra 3 years paid Extended Security Updates (ESU) support. For 2012 and 2012 R2 that ends in October 2026.
The three years of ESU exists only for organisations like government departments that would rather pay Microsoft millions of dollars for patches than pay a competitive wage and hire competent IT staff that can complete upgrade projects on time.
I'm not going to say the wages are fine but the issue is likely not to be the competence of the IT staff, but rather the overbearing IT management processes the U.S. Federal government uses. "Enterprise change management" processes separate from the already-long cybersecurity review processes can add weeks or even months to system updates.
In that kind of construct, you optimize for fewer but larger changes and then it's no surprise to see that there's no time in the project update schedule to update the OS in addition to making all the other long-overdue library / middleware / application changes that also are pending once a change finally can be made.
It's a good time to be kind to your neighbors. No matter their background, they're almost certainly not the ones to be upset at.
That said, they should have migrated it years ago.
The fact that they didn't already know how to do it is the crazy part.
This is a clear example, but I don't believe any tools are neutral. Your immediate fallback was to a hammer, not a mouse, with the obvious corrollary being to bludgeon, but the same line applies. Tools are not neutral, and that's why when you looked for something that causes harm, you grabbed something that's objectively been serving a dual-purpose for hundreds of years. Nobody's using a computer mouse to bludgeon someone to death; it makes a shitty bludgeon, and the design of the tool reflects that.
That's also why these comparisons always fall back to knives, or hammers, or the AK-47: they are dangerous tools that are designed to make killing easier. Nobody is making these comparisons to more benign tools, like desk lamps, coffee cups, or car stereos, and it's because tools are not neutral, and none of my examples are designed to make direct, bodily harm, easier.
Murder by ethernet cable: https://www.gainesvilletimes.com/news/dead-woman-found-in-pa...
Murder by laptop: https://www.riverfronttimes.com/william-lynn-gunter-sentence...
Murder by cellphone charger: https://lawandcrime.com/crime/pennsylvania-man-admits-to-str...
Murder by desk lamp: https://www.pressdemocrat.com/2009/01/08/man-beaten-to-death...
Stabbing by coffee mug: https://www.muscalaw.com/blog/north-port-two-women-attack-co...
https://en.wikipedia.org/wiki/List_of_countries_by_firearm-r...
https://en.wikipedia.org/wiki/Lists_of_mass_shootings_in_the...
There are more mass shootings in the US per year than there are days in a year. It’s so bad they need pages for each individual year.
https://en.wikipedia.org/wiki/List_of_mass_shootings_in_the_...
Meanwhile, pages of deaths perpetrated by household items are curiosities. You parent comment stands: tools are designed for specific purposes and are used for those purposes.
If the design of tools are neutral, one tool should do as well as another in this common comparison. But the useful application of tools is inherent in their design.
If tools were neutral, as so many on this site claim, why is AI only ever compared to knives and hammers?
Parent has lots of links to other common objects causing harm, why are they never used as the example when tools are allegedly neutral? That would be a stronger argument opposing AI regulation - ethernet has less regulations that knives, but can still be used as a murder weapon
> doesn't mean you ban hammers
They didn’t suggest banning anything.
> You can kill with hammer
Not if you don’t have a hammer available. Which is the point. Ready access to a tool makes misusing the tool easy. And some tools are more conductive to misuse than others. You can kill maybe a couple of people in a crowd with a hammer, a few more with a handgun, a ton more with a machine gun or a bomb. The tool itself matters, and you should regulate each accordingly to their capacity and likelihood of harm. For example, plenty of countries restrict gun use significantly more than the US. Those countries have much fewer gun-related deaths and violence. This isn’t (shouldn’t be, in an honest discussion) hard to understand.
No need to knee jerk react to an argument that hasn't been made.
I was sort of admiring the devastation a malignant actor can cause with a good tool.
It’s usually used for morally neutral neutral or good work.
starting with Windows Server _2012_ :O
Yes, 19.
Are you alive?
Yes, 18!
Evel Knievel.
—
They also come off as a little bit rosencrantz and guildenstern imo
At 4:58 pm, he wiped out a Department of Homeland Security database using the command “DROP DATABASE dhsproddb.”
At 4:59 pm, he asked an AI tool, “How do i clear system logs from SQL servers after deleting databases?” He later asked, “How do you clear all event and application logs from Microsoft windows server 2012?”
In the space of a single hour, Muneeb deleted around 96 databases with US government information.https://www.somdnews.com/archive/news/19-year-old-twins-high...
1. Obliviousness to local laws and oversight (and the combination of severity of punishment + likelihood of getting caught); most Americans of their intelligence would be aware, and would not engage in the sort of hijinks they did.
2. Working with sibling (anecdotal, but seems slightly more common among immigrant families than locals, which would make sense since, on average, immigrants have fewer local connections than locals so the likelihood of working with siblings increases)
3. Loyalty to family (evidenced through the brazenness in the way they helped each other in criminal acts without a second thought). Americans, on average, are more individualist and hesitate more when asked by family to do something criminal
4. A lot of immigrants eventually adopt anglicised names, which neither of these two did
If a detective looked at these facts, they'd keep an open mind as there's nothing definitive above, but it would be equally ignorant to ignore the circumstantial evidence.
Having said all this, do we care where they're from? (unless it's a potential case of foreign interference or theft from an untouchable overseas company, which doesn't seem to be the case here)
that would still leave up to 49% Americans not being aware. so how did you conclude that they were not Americans? Also, how did you measure their intelligence?
> "slightly more common among immigrant families than locals"
even if true, how did you conclude that these were not Americans?
> "Americans, on average, are more individualist and hesitate more when asked by family to do something criminal"
even if on average Americans are more so, how did you conclude that these were not Americans?
> "A lot of immigrants eventually adopt anglicised names"
from your sentence it seems a lot of them don't. so how did you conclude that these were not Americans?
It would be a disaster for immigrants in your area if you were ever hired into some kind of investigative/law enforcement role.
This fundamentally misunderstands how predictive models work. A parameter is a potentially useful predictor if it's better than excluding it 50.000001% of the time (high frequency trading is good evidence of this).
> conclude
Conclusions? Absolutely not. Higher statistical probability? Yes. Based on evidence. To state your point, which is bleeding obvious, of course you cannot know how recently someone or their family came to America based only on their behaviour with regard to the law. But their behaviour with regard to the law absolutely can be a useful predictor.
(in fact, it's precisely this rationale that justifies in some cases giving foreigners lighter sentences where 'their culture' allowed for xyz but the local jurisdiction doesn't - roadrules in the UK is a pretty good example: local truck drivers get the full penalty; those from continental Europe often do not, since road rules are less likely to be known by them)
Alternate example: ask a Western drug smuggler busted in Indonesia or Vietnam how long they expected their jail sentence to be if caught (spoiler - it's a trick question: they'll say 3-5 years and instead are met with the death penalty; whereas most locals are well aware of this) - ignorance to local laws and customs does correlate with how long someone (or their family) has lived in the area, if at all.
I too am shocked at the level of federal access that was afforded to these non-Americans that clearly also hold a disdain for the country.
> After their stints in jail, the brothers worked their way back into the tech world. In 2023, Muneeb got a job with a Washington, DC, firm that sold software and services to 45 federal clients; Sohaib got a job at the same company a year later.
How were they able to to easily work their way back into somewhat sensitive job, considering how much US companies make a big deal out of employing people with a criminal past?
> The plaintext password of an individual who submitted a complaint to the Equal Employment Opportunity Commission’s Public Portal, which was maintained by the Akhters’ employer...Sohaib Akhter conducted a database query on the EEOC database and then provided the password to Muneeb Akhter.
Why were the passwords being kept in plain text??
The fired DBA however, stayed behind and finished backing up the databases he was assigned to backup.
Once the job was done, he packed and left.
True story!
I know several stories of people who got fired (or contracts not prolonged) who finished their task at hand, did some handover to colleagues, and then left.
I think this story has been sanitized to mask some details which is ok I guess but I ain’t buying the back story.
No, employees that can wipe 96 databases are a security risk, even when they're employed. But of course it's easier to go the inhumane route of cutting everything off at employment end rather than fix it properly
The second part I'm unclear about is how you could pass SOC2 when you aren't terminating account access simultaneously with the employment termination.
> On Feb. 1, 2025, Muneeb Akhter asked Sohaib Akhter for the plaintext password of an individual who submitted a complaint to the Equal Employment Opportunity Commission’s Public Portal, which was maintained by the Akhters’ employer. Sohaib Akhter conducted a database query on the EEOC database and then provided the password to Muneeb Akhter. That password was subsequently used to access that individual’s email account without authorization.
This is why so much of vetting & compliance is toothless. You can have robust change management, physical security, network security, identity management, etc. policies but absolutely nobody wants to spend enough on audit & enforcement to make them meaningful.
The gov't will make you _claim_ that you do all of these things before awarding a contract, but they won't ever check.
Good actors will do the right thing regardless because they know the consequences of cutting corners.
It's not just information security, either. I've seen vault doors propped open because the people working inside didn't want to do all the sign-in/sign-out paperwork to take a leak.
First of all, it is viral, and it is almost never adopted based on its own technical merit.
Second, it has lots of levels. The first level is “we wrote down a plan explaining how we’re going to secure stuff”.
The second level is when you start implementation or maybe tracking or something.
The key thing is that first level: When your SOC2 dept says you have to do something idiotic for SOC2 compliance, it is because someone at your company invented the idiocy, and should be fired. However, you still need to follow their dumb plan because that’s the process.
In this case, the “how do we fire people” process, and “how do we prevent one llm from dropping 96 prod DBs in a single session” very well could have had answers in the plan, the plan could have been implemented, and therefore the company is still soc2 compliant, and this is exactly what a working soc2 process is supposed to look like.
The only solution is correct access segregation and a bastion
To confirm a user supplied password matches you run input into the same hash function again with the salt+pepper and compare it to the value in the database.
That way if the database is stolen, the attacker cannot recover the contents of the passwords without brute forcing them. Encrypting passwords is not recommended because too often attackers are able to recover the encryption keys during the same attack where the password data is extracted.
[0] https://en.wikipedia.org/wiki/Bcrypt
[1] https://en.wikipedia.org/wiki/Scrypt
[2] https://en.wikipedia.org/wiki/PBKDF2
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
Hashing passwords has been a thing for at least 50 years now. V3 unix had /etc/passwd which hashed all user passwords. Notably, these hashed passwords in early unix have been cracked: https://arstechnica.com/information-technology/2019/10/forum...
I guess you got your answer.
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies.
While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites.
Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts.
I didn't see if that's the hole the brothers exploited but it very well could have been.
The client-side encryption may have been all that was missing in this case.
Of course performing an additional server side hash on top of the client side one is good defense in depth because there's at least some chance that it might make things more difficult for a rogue insider and doing so costs approximately nothing. But it certainly isn't critical because by the time you're dealing with a rogue insider things are already looking quite bad.
Hashing client-side is a good idea. You must also hash server-side, for storage/comparison.
Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db.
They can then try the credentials on other, perhaps more lucrative sites. That's what the brothers are accused of doing here, so client-side hashing (or just simple encryption) may have been the missing piece of security that would have thwarted the credential stealing.
This seems to mostly prevent accidental logging and is thus a matter of defense in depth, stopping malicious actors from exploiting it later — but an actively malicious IT person would not be deterred.
Yes, and that's not uncommon, IME. There's generally a lot of logging that's at least potentially available, and it gets turned on, and the logs shared when there's a problem that needs to be fixed (especially when it needs to be fixed quickly, which is usual).
This is going to make more sense for "enterprise"-type deployments, where there's a significant distinction between the people who might have access to request logs at times, and the people who can push code to production.
I am talking about not logging them ever, using internal TLS and strong hashing in general, and wondering what exact value is added on top with client side hashing.
Hashing client side minimizes the risk of any blast radius exceeding the bounds of your own service. There's obviously no way to prevent an adversary who achieves full MITM from gradually harvesting credentials over time. The only solution there is to use keys instead of passwords.
In your enumeration, what is breached for this to be meaningfully impactful for other services where customers might be reusing credentials?
I already answered you that if you assume full MITM of the frontend then it is physically impossible to prevent gradual credential harvesting. Did you have a different scenario in mind?
> how is client side hashing really helping
Compared to what? Server side hashing? It prevents the plaintext from ever hitting your infra which minimizes to the greatest extent possible an insider or intruder gaining access to the plaintext. Since preventing access to the plaintext is the primary purpose of hashing it's the sensible option if you're forced to pick only one.
Of course there's really no good reason to pick only one of the two. You might as well elect for defense in depth against rogue insiders with full db access even though it's difficult to imagine what use they would have for a password based login at that point.
If you are never logging a clear-text secret and storing a hashes version to validate against, and using TLS between client and server, client-side hashing does not bring much benefit other than protecting customers' reused passwords against people who have sufficient access to the infrastructure to MITM the client but no ability to modify the client side code where they could extract the password directly.
When IT has write access to code, client side hashing protects only against accidental log leakage and similar.
That is not a property of server side hashing but rather hashing in general.
> If you are never logging a clear-text secret
Yeah good luck with that. /s
It's better not to need to worry about logging plaintext. The less of your infra that falls within any given security boundary the easier it will be to properly secure. The difference between server and client side hashing is how much of your infra touches the plaintext. Less is always better.
Sure, an insider could make direct use of hashes pulled from the logs. However if the attacker already has access to your systems then they are already inside the security boundary (or at least most of them) and likely have many other (probably better) options available to them.
It's important to keep in mind that the primary purpose behind hashing credentials is to minimize the degree to which your systems come into contact with the plaintext. The goal here is to contain the blast radius of any intrusion to only your own systems and only the immediate intrusion (ie to prevent future abuse after you've cleaned everything up) given the unfortunate reality that end users will frequently reuse credentials.
It's also important to keep in mind that hashing is cheap enough that you should probably be doing both. Hash it on the client so that you don't need to worry about logs (or snooping the LAN or whatever other way an employee might come up with to obtain plaintext passwords) and then hash it again before it enters the db so that you don't need to worry about the logs that contain hashes leaking.
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
You store safely crafted hashes.
The minimum one can do is have a different randomized password for every service on a possibly completely offline password manager.
Yes, you will depend on a password manager at all times, but at least the blast radius is minimized to the affected service.
But how do you pick up the stuff from your desk? I once lost a nice pair of headphones this way.
I'm in my early 40s, and I've never had a job where we've "hot-desked" like that, even when a company was out-growing an office.
Every job I had before COVID back to when I started back in the early/mid 90s had dedicated desks.
Some people simply have no regard for others and will mess with or jack your shit. Don't give them the chance.
Still a net positive in my experience.
My workplaces have not had gyms, but I bought equipment for my home that maintains the streamline. I haven't been perfect at my routine because my work schedule isn't consistent which is annoying, but I do still get some exercise in at least twice per week with it. I doubt I'd be getting at least that otherwise.
Go ahead and leave a coffee mug, who cares if you lose a coffee mug?
Many humans like to decorate their desks, keep personal stuff there. It's normal.
I spend in the office more time than at home so I want a nice environment.
Ever tried to login with two factor and justify a maxed out company card while high as a kite and drunk?
It’s stressful.
I know of one case where this was totaly unintentional, and a machinest at a local pulp and paper plant had self delegated to write the software that controlled tension on the giant machines in the mill, but as it was his only real forey into sofware, nobody else could operate it, and they fired him after a manegment reshuffle, and then after the next scheduled shut down, nothing worked right, greasy dusty ancient screen with a blinking cursor was what they had, plugged into the important bits of a half sqare mile plant. still funny to think about!
What you really need is one that chirps once every (multiple of) 20-28 hours (with weighting towards 23-25 to keep it roughly around the time you set it going and an infrequent skipping of a day.) Also with different volumes and, ideally, different chirps. Occasionally a double chirp just for extra insanity causing.
(A Michael Jackson "hee heee" would be another good option.)
Outside of the US it's almost never done like that and a person fired is expected to be cooperative and probably even continue working for another two weeks. And not only expected - this is what actually happens.
In 2011, university systems like George Mason’s were significantly more vulnerable to the exact type of SQL injection and credential theft they were using in their early criminal years.
After their stints in jail, the brothers worked their way back into the tech world. In 2023, Muneeb got a job with a Washington, DC, firm that sold software and services to 45 federal clients; Sohaib got a job at the same company a year later.
What in the actual fuck. I'm all for giving people second chances. But maybe some ringfencing?
Like... I think ex drugs dealer deserve a chance of legitimate employment, but perhaps doling out prescription drugs is best left to someone that doesn't need a "second chance" to demonstrate they're unusually trustworthy and unlikely to be tempted by the possible side incomes.
This is no different. If one day you can answer why and how to solve that I am pretty sure we would all be happy to know!
storing passwords in plaintext should be persecuted & having unlimited access to customer databases.
WTF?
The "after they were fired" sounds catchy, but isn't even the biggest failure.
This organization shouldn't be permitted anywhere near government, or any non-public, data/information.
> “Smart idea,” said Muneeb.
Seems obvious they weren't destroying databases just out of malice (i.e. retribution for being fired), but in order to cover up something/s..
In fact I’d guess they’re not, since they’ve been employed on government projects since a young age.
This does not mean they are from another country.
It’s OK to acknowledge that economic migrants are a thing, and that they likely have only transactional interest in where they live, such as a Bengali construction worker in Dubai, for example. That’s just part and parcel of labor mobility. For better or worse, shareholders, or middleman representing shareholders, have decided this sort of thing is a really good idea in the US, and now around half the population falls in that bucket. It’s a free country, and freedom means being free to choose short term interests. That also means you’re free to support such policies because they are good for Blue-team redistricting so we can provide free healthcare to all 8 billion people in the world somehow.
But please, nobody becomes a Yankee by the mere fact of standing on the ground. If you want that pejorative title, then you need to earn it.
As opposed to...
Hilarious in the context of this administration.
He can be fired too, but the current shitheads in charge would never do that.
> When the company discovered Sohaib Akhter’s felony conviction, it terminated both brothers’ employment during an online remote meeting on Feb. 18, 2025
from https://www.justice.gov/opa/pr/federal-jury-convicts-virgina... which is a better source on this.
That prompts the question of why background checks are so lax that they were hired before this was discovered.
> However, an employer may ask about criminal conviction(s) after extending a conditional offer of employment (the employer can never ask about arrests or criminal acusations that aren't pending). An employer who properly asks about a criminal conviction can only withdraw the offer or take adverse action against the applicant for a legitimate business reason that is reasonable under the six factors* listed in the Act.
One of the six factors is "Fitness or ability of the person to perform one or more job duties or responsibilities given the offense"[1], which they probably could have invoked after asking (though they never checked or didn't check thoroughly enough, so I guess it's moot).
[0]https://ohr.dc.gov/page/returning-citizens-and-employment
[1]https://ohr.dc.gov/sites/default/files/dc/sites/ohr/publicat...
It should be a federal crime with prison time to make a DB for a federal agency and not hash and salt passwords or other auth credentials.
When I advised them that it was a bad idea to store password in clear, they answered that they keep it in clear so that they can send it when someone forget.
Defeated by such argument, I deleted my account.
Something bad did end up happening due to that lax security and there were oh so many meetings about it.
This is the sort of thing that makes me want to check out of the whole circus. Here I am, telling you ahead of time, and you ignored me
So how there's a circus that we could have avoided and not only do I get zero recognition for identifying the threat ahead of time, the people who ignored me keep their jobs and turn it into a zoo where everyone is scrambling in endless meetings
And I've seen it play out a few times. After a point, why bother...
I'd bet your account wasn't actually deleted, just marked as deleted or inactive.
Explain to me how we can have a transcript of a conversation without knowing whether it was in person or not. I'm baffled by this sentence.
Meatbags: hold my beer...
They still can install traps that detonates if they are fired. A simple cron job is enough to break havok.
It's ridiculous that companies don't seem to care about ethics. They never seem to select candidates based on proven ethics. They don't even ask any such questions.
For example, I've been in at least 2 situations where I had the ability to inflict major damage to companies which had treated me very poorly and I could have legally gotten away completely whilst doing variants of 'the wrong thing' and profiting but I didn't do it because I have principles. Unfortunately it seems that few people do nowadays. Leaders are fooling themselves if they think they can completely factor out ethics and make it all about aligning incentives. Incentive alignment creates its own problems as this alignment requires constant maintenance and it's both expensive and detrimental in the long run. These people will tend to sabotage every aspect of their responsibilities which isn't directly measured... In order to gain leverage. It's not clever. It's crooked. Should not be rewarded.
My experience as a software developer is that managers alway have lots of blind spots and the wrong people will take advantage of all of them, even when it negatively impacts the company.
I wonder how many government dbs store passwords in plaintext…
Also, these guys sound like sociopaths. I bet some of their peers felt constant discomfort and threat just being near them.
all with pardons waiting so they can't be convicted
they might not even wait a few years
still pretty gross of you though
People are weird. Their government is strongarming half the world at the moment and they do not pause and go "wait, does this mean that if we unionize we can threaten to wipe all the databases unless?"