> [Opexus] said that “the individuals responsible for hiring the twins are no longer employed by Opexus.”
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.
Terminating access and rotating passwords (if needed) while the person is in the meeting but has not yet found out they are being let go has been SOP for at least the last 20 years
Is this specific to US culture? And what about your work environment makes it such a risk?
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?
Heh, a place where I worked some guy who left kept committing code for months (he went to work for a company we were a vendor for). Some of my teammates knew and just thought it was no big deal, he was fixing bugs and adding features.
The color the director turned when he found out!! Oh man.
he went to work for a company we were a vendor for
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.
> Sounds like he's getting paid to work on the same thing by a slightly different stakeholder.
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.
Never happy is a bit of an exaggeration. SYSV UNIX had all of these risks
and various legal departments went through them as they do regularly for more typical types of research.
I have door codes and passwords for a major organisation that I last worked for somewhere in the region of 20 years ago. They haven't rotated a damn thing. I still know people who work there, and I guess technically I still support things for them in an informal question-over-a-pint kind of way, but damn me, put in some effort guys.
My first task at my last job was removing access to an employee being let go. I had just gone through onboarding so I knew every (documented) service we needed to handle. We live tested it on my own accounts, measured the time before I noticed, and then proceeded to successfully go through the checklist.
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!
Amateurs. My employer does mass layoffs by terminating access to everything except their email account at 3am, and then sending an email to the victim saying “you were let go at 3am”. Managers get to figure out who’s left on their team by pinging everyone when they learn about it at work.
Google powerwashes your corp Chromebook when they let you go. A friend was composing an email on the train when their screen went black and the device reset itself to factory settings.
They even send the “you’re being fired” email to their personal email they have on file. Didn’t even schedule a meeting.
Most of the employer behaviour described in such gleeful terms here would be outright illegal in most of Europe and open up the employer to risk of being sued for wrongful dismissal, etc.
Eh, there are ways around that. I've worked for multiple Finnish companies that do layoffs via "lomautus" whereby they put the laid-off employees on a forced, unpaid, indefinite leave. After multiple months of not receiving a paycheck, the employees inevitably "resign".
We’re talking about a Google employee that makes 5x or more of what a European counterpart would. Lack of termination notice and other at will employment is easy to plan for when you make so much money.
Until someone starts providing examples of software companies where the employees are unioned and clear $400k+ annum, the bar is still “no unions”.
If you're talking about Oracle, the large round previous to that they did had individual meetings with employee, manager, and HR. With so many layoffs it took a week+ to do, effectively torturing an entire set of employees who had no idea if they'd have a job by the end of the hour, let alone week.
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)
>I'm not sure there's any good way to lay off large amounts of staff
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?
Either your dates or experiences are off, because I've been working in software since 1999 and the easiest time to get a job was quite recent, in the back-half of COVID. The early 2000's were decent, but I didn't experience - or know anyone who did - any sort of "free jobs' period. Also pay was relatively decent but much less than what you saw even 5 years ago. It's only the in the past year or so that the world has appeared to be ending for developers, and I think that pronouncement is premature.
> the easiest time to get a job was quite recent, in the back-half of COVID
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.
During the dot.com bubble, so many folks went to work for startups that old-fashioned corporate IT (in insurance, industry, banks) was struggling to hire. The saying goes that they hired you if you could spell "C++".
In 1996-1998+ they had something called the Brass Ring job fair in the Santa Clara convention center in the heart of Silicon Valley. Employers would set up booths and some would hire people on the spot.
>Also pay was relatively decent but much less than what you saw even 5 years ago.
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.
You should have tried to create a business or fulfill G-ds hopes for you when you had the chance… but you sold out and took the easy pay check. Now
You’re fucked
I know enough people who tried, to be able to tell you that it's not all roses over there. Some had to go back to being a corporate slave and some just continue grinding a barely viable business earning much less than they could at a large company
The 2010s were not that easy to get a job in. It took quite a lot to actually get a job. It didn't take 6+ interviews and takehomes. But you could use a recruiter, go through the interview etc.
There was no leetcode and the resources weren't great. The introduction of leetcode made everything super painful.
How you handle employees after the layoff announcement is a much easier conversation: Give them a lot of dedicated resources to navigate it and give them a good parting offer.
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.
I mean, not to snarkpoast on main, but all of this has happened before re:
> 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.
I experienced that once. The parent and the parent's parent company were from the USA. The top CEO and CTO came over and fired everyone. My laptop was controlling a job that had to run pretty long on a 16 core server, but I did as asked: I shut down the laptop and left it on my desk. That was at least $50k down the drain.
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?
Though you'd want to make sure there's no essential information that only this employee knows, because that action might terminate that employee's desire to cooperate with the company.
When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence. This is absolutely a standard and has to be for these kinds of positions. I've never worked anywhere where it wasn't for the majority of IT staff. You meet with HR, someone clears your desk, and security walks you out.
There is a middleground, but it requires conscious effort to prop-up, support, and maintain over the long haul: off-boarding centers.
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.
Your last sentence sums it up. I was blown away by the system you described that would allow for such a humane transition through such a difficult time. At least process wise it seems like a good place to work.
> When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence.
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.
For most of my career (over 30 years now) where I've had sufficient access privileges to matter, I've fairly diligently maintained a "Important credentials and access" list, which I've sent to my employer when leaving, strongly advising them of the need for them to disable or rotate those credentials.
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.)
The first option is flipping one switch. The second option is flipping some switches now, and flipping the rest later. Of course the safest (first) option is the correct option from a liability standpoint, which is all a company should operate on since it's first responsibility is to protect the company for those that are still there. There's plenty of ways to communicate with ex-colleagues that don't involve company resources or opening the company up to liability.
Let’s not forget the third option: proper security practices and principle of least privilege. No one should have been able to do this in the first place. Why were they able to get plaintext passwords with a simple query? Why did they have delete permissions on production db tables? Why were they able to modify system logs and delete backups?
> Of course the safest (first) option is the correct option from a liability standpoint, which is all a company should operate on since it's first responsibility is to protect the company for those that are still there.
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.
System security is not a human value. Access key rotation effective immediately is a compliance requirement, and completely orthogonal to human decency, which is delivered trough garden leave or severance, not extended system access
I'd argue that failing to segregate things so that there's a switch for the sensitive stuff and a separate switch for the not-sensitive stuff is an operational failure. A rank and file employee having access to his email account should never pose a serious liability to the business.
Yeah I don't see why that's necessary. I'm sure you can always reach out to HR and ask (I have facilitated this in the past, pulling contact lists and phone numbers) but that also gives them ways to exfiltrate data. It's company data. Just think of all the info you have in your inbox. Unless you've managed offboarding for high level IT positions it seems harsh, but the risk is just too high to allow the user to do that stuff themselves.
> Just think of all the info you have in your inbox.
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.
No you don't get it, we have to take a harsh approach to firing people because we keep pallets of high explosive in the break room and management doesn't want to change that. /s
If you don't trust your people so much, why to hire them in a first place?
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.
sometimes you fire because you trusted them then they gave reasons to stop. At company I work at it happened, but the more common way is just getting info few weeks later then working normally till the end date
>Looking at it from Europe - it is such a weird inhumane practice.
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".
No this is labour law in the UK, I just had this last year. Its 3 months where you get paid and you can search for a job etc. Made our new American CEO livid that he could not just fire people.
More specifically in the UK there are a few ways employees can be dismissed.
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.
All the couples I know who are divorced did continue living together after one of them said it was over, I think the longest time actually was about 6 months.
Yeah but did they still keep banging and cuddling like before the divorce announcement? They probably weren't doing much of that anyway if they got divorced but you get my point.
Looking at it from Europe, this definitely also happens. It depends on the situation. I know of ppl who were kept bcs the parting was in good faith (which was less a firing and more an agreement that parting is in everyone's interest), but I also know of ppl who had their access revoked before firing bcs it wasn't. The latter had unilateral system access as well, which added to it. It's not about humane or inhumane, it's about risk. The 3-6 months being nice is also a fairytale that I have only ever heard in a positive light from employees who are not particularly ambitious or awake or in any way satisfied with their jobs or the prospect of a future job. On the other hand from the perspective of employers it's consistently hard to effectively restructure, it's expensice and awkward to have to pretend to want to keep someone around that you or they don't want around.
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.
Europe is not falling behind on anything that is not reasonable.
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.
> It's part of the reason why Europe is falling behind on everything.
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.
>They couldn't find anything for her to do? Hard to believe,
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.
>Ithey 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'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.
The anomaly there is that France Télécom was a public company at the time of the hiring, and through privatisation public servant benefits were upheld for existing employees, which blocked most unpythonesque solutions.
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.
Yeah but if you defense against somebody erasing a database is "we remove their access when they're fired" then your defense is garbage.
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.
But I'm talking about general day-to-day security as well as off-boarding. What stops a single disgruntled employee from doing this before being fired? And if you have a good story there, why do you need the most extreme approach to "off-boarding"?
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.
I suppose that's a very powerful way of preventing "accidents" on termination. But isn't that just theatre? I mean - as though termination is the one and only case where an employee with the power to destroy the company gets angry and might do something really stupid?!
It's not theater, it's defense against aggrievement. Termination is a traumatic event that threatens your ability to exist or provide for dependents. People [rightfully] don't handle exile well.
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.
> 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.
Ok but with the European laws the incentive to do something at the last minute doesn't really exist.
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.
You always have to be careful about overfitting to a specific scenario like "this but if they had also forgotten to lock out the other evil twin". I'd prefer a system that is robust to a malicious employee (more likely: compromise of an employee's credentials) but has a slight gap in the "evil twins" scenario over one that prevents all post-firing malicious access from twins but doesn't consider at all what happens if a current employee's credentials are compromised.
This takes the whole "you must mean my evil twin" to an actual example. Maybe this is more "you must mean my other evil twin". Part of me really wishes their names were Daryl
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 problem is that its so challenging to figure out what the person actually has access to. Have they ever done a export with sensitive information, that is now sitting on their local machine? Any important clients they still are in contact with over email that they may try to sabotage? Any other creative endeavors you haven't thought through?
The most fool proof way is just to nuke the computer in its entirety.
Privileged access should only be temporary in context of break glass with approval. People can go ballistic with core systems for reasons other than firing.
In an age of malicious agentic AI, this level of access is negligent. A lack of engineering controls preventing this from happening at all means that a simple phishing or supply chain attack could easily have resulted in the same outcome or worse.
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
The employee is always the last to know. This is standard fare.
> a more balanced version: <bunch of weedy ACLs, judgement calls, liability/>
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.
> Too complicated and subjective, stinks of more risk.
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. :-(
> On March 12, 2025, a search warrant was executed at Sohaib’s home in Alexandria. Agents grabbed plenty of tech gear but also turned up seven firearms and 370 rounds of .30 caliber ammunition. Given his former crimes, Sohaib should have had none of this.
For god's sake, don't commit crimes while you're committing crimes.
I was kind of hoping he sprinted out his back door which happened to be on a state line and then mailed his guns back to his house, just to try to cover everything.
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.
I'm not a big "lock them up" guy but seriously people don't seem to understand how hard it is to actually get the state to put and keep you in jail. You have to do really really bad things multiple times. The US prison population has been falling for over a decade now and part of that is everybody now faces pressure to not use incarceration as a first (or second or fifth) option
> At 4:58 pm, he wiped out a Department of Homeland Security database using the command “DROP DATABASE dhsproddb.”
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.
> 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. He downloaded 1,805 files belonging to the EEOC and stashed them on a USB drive, then grabbed federal tax information for at least 450 people.
Maybe whoever runs infosec at that place should also be fired?
I love how this leaks out the fact that the DHS is running production databases on operating systems that are months away from end of extended support.
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.
> 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.
The day-to-day operation of large government bureaucracies is surprisingly immune to elections. The same people stay in the same job for decades, the "churn" only happens at the highest levels, and even those positions tend to outlast changes in the current political party in charge.
Unfortunately this is a good example of kicking the can. Not to the next administration but to after the next elections. Some aspects are felt already but not all.
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.
The tools we use are not neutral. A sword can be made to work like an axe, but we use axes for chopping wood because a sword makes a shitty axe. A sword is designed to kill people. The handle, the mass, the weight distribution, and every other aspect I am not qualified to get in to, means swords are designed to kill. They are a tool, and their use is not neutral.
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.
The fact that you had to find an article from three decades ago for an instance of killing with a keyboard is telling. All the others aren’t exactly that recent and are mostly isolated cases. Meanwhile, on gun related deaths, there are entire Wikipedia pages for it:
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.
My larger point is that nobody - nobody - defaults to telling us the coffee mug is unregulated, as AI allegedly ought to be. They always compare it to something much more commonly used as a weapon; something that, when asked to name a household object likely to be used as a weapon, the average person would guess.
Instead of comparing AI to any other tool, especially one closer to "useful with a computer", the common comparison is always a weapon of some kind.
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
That’s a non-sequitur. You don’t need to defend AI, your parent comment isn’t attacking it, simply making an observation.
> 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.
One of my favorite lines "Peligroso es mi nombre medio" (which of course is not grammatically correct in Spanish) and then his short inspirational speech invoking general Zapata were great.
I'm just amused how these people were even hired to begin with ? They don't seem to be Americans? How were they even allowed to work on sensitive systems? Why was this even allowed? So many questions.
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.
They were born in Maryland, and apparently quite skilled (or at least skilled at cheating their way through their studies, if not genuinely technically skilled).
I would imagine they lied about having a felony conviction on their job applications, and that for whatever banal reason any background check service they used didn't flag it, or the contractor was so grossly incompetent they didn't even check.
A few other circumstantial things lightly hint at the twins not being typically American:
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)
> "most Americans of their intelligence would be aware"
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.
> that would still leave up to 49% .... how did you conclude?
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 take it you're not in HR at the CIA or FBI, which vet applicants' families for a reason. i.e. how long ago applicants and/or their families came to the US does help predict their loyalties... It might not be a strong nor fair predictor, but it's not zero either.
> 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.
About 25 years ago we had layoff at a company I worked for. One of the DBA's got fired along with others. Back in the day they didn't revoke access and you had your work computer available until the end of the day. Most, who were fired, just packed and went on their way.
The fired DBA however, stayed behind and finished backing up the databases he was assigned to backup.
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 don’t know where to start with this other than to point out that there is no way in hell these two clowns had the security clearance necessary to access a prod DB at DHS. I can only assume they stole creds from another employee who had that level of clearance. Also, tax records are not stored in a DHS domain .
I think this story has been sanitized to mask some details which is ok I guess but I ain’t buying the back story.
> it does follow from the simple fact that a fired employee with access to company systems is a security risk.
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
How did they get access to 5k passwords? Are they being sent/stored in cleartext? This is the most baffling part of the article for me.
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.
From the article, it sounds like the passwords are indeed stored in cleartext:
> 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.
I've been through a handful of SOC2 audits and they've never asked us to _prove_ that we aren't storing passwords in plaintext or with reversible encryption (we weren't).
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.
I'm pretty shocked as well. I thought every company stopped doing this like 20 years ago? Even for a legacy system that is a long time to continue storing credentials like that.
The tighter your security is, the more inconvenient it is for legitimate users, and the more you have to do audits because it's easy to justify going around security in the name of efficiency.
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.
SOC2 requires an audit. But one of the weaknesses of SOC2 is that the audit mostly checks to determine that you are following whatever your policy is. It doesn't verify that your policy is rigorous.
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.
And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored.
The only solution is correct access segregation and a bastion
You should never store passwords in plain-text, encrypted or not, you should always use a one-way cryptographic hash like bcrypt [0], scrypt [1], or PBKDF2 [2], combined with a single use salt [3] and optionally a pepper [4], and then store the output of the hash in the database.
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.
(I will be copy/paste this answer for the other comments)
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 :)
(I will be copy/paste this answer for the other comments)
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 :)
(I will be copy/paste this answer for the other comments)
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 :)
(I will be copy/paste this answer for the other comments)
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 :)
Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.
Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.
Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the client, and sent to the server the attacker doesn't need to reverse the hash, they can just send the hash in the request. Instead, you should send the password to the server (using TLS encryption) and do the hash and compare on the server.
You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison.
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.
Hashing client side is sufficient because the only service you can breach with the hash is the one you already had to breach in order to read the database.
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.
I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side?
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.
Yes limited protection against insiders is good defense in depth but not the primary purpose which is to protect end user accounts on other services in the event that you are breached.
My question still stands: how do you disallow cleartext password extraction if you are breached, assuming all your IT infrastructure and code is now accessible to an attacker?
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.
There are substantial differences between database access, snooping the logs, internal (no TLS) wiretap, and full MITM of the frontend.
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.
We are not disagreeing, but I am not getting my answer: how is client side hashing really helping, what are the circumstances it helps with if you do have the basics right?
In your enumeration, what is breached for this to be meaningfully impactful for other services where customers might be reusing credentials?
As opposed to what? Your question seems unclear to me.
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.
There is certainly good reason to do server-side hashing: you do not keep a persistent record of the customer's secret, yet keep the ability for them to authenticate with it.
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.
> There is certainly good reason to do server-side hashing: you do not keep a persistent record of the customer's secret, yet keep the ability for them to authenticate with it.
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.
(I will be copy/paste this answer for the other comments)
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 :)
I have no problem with my credentials being revoked everywhere before I know about a layoff. I don't really care how I learn about it, just please don't make me come in to the office.
I've never had a job with a permanent individual desk like this. The one in-person real job I had, it was only shared working space that different people used at different times of the day or on different days, and I think you were discouraged from leaving anything. The idea of there being "your desk" with a framed photo of your kids and favorite coffee mug seems like a nearly extinct piece of nostalgia. It must have been nice in a way, far preferable to the new style of open office at least.
Meh. Don't leave anything at work. Forgo the convenience and carry your things on your commute. Use a bag. If there's "too much stuff", that's a sign to pare back what you "need" at work.
God, if we're at the point where we're so paranoid about being laid off that we don't dare leave a single piece of personal property in the office then I think we're in a very dark place indeed. Can’t imagine the mental damage from considering losing your job every single day you wake up.
I never left anything valuable or personal at my desk when I worked in an office simply because I had a very nonzero number of colleagues who acted like animals. My fizzy waters, coffee, and snacks would be consumed without permission or replenishment. Chairs, monitors, and input peripherals would get swapped without asking. Desks surfaces would be sat on with chairs used as footstools. Corporate effluvia of all types would end up on my "unused desk" because I wasn't in at the exact moment some roving bandit walked by looking for a spot to dump their crates of paper and binders.
Some people simply have no regard for others and will mess with or jack your shit. Don't give them the chance.
I always thought it was weird that all of the equipment issued to me beyond the laptop was registered to me, such as the monitors and desk phone. Your comment enlightens me... That's wild to imagine folks just swiping things from other peoples desks. We even have storage rooms of office supplies where someone could drop off their crate of paper and binders if they had one for some reason.
well this did just happen to me. laid off while taking care of my father in laws estate and my personal belongings were thrown away. 7 years at the company as an EM ftr.
I had my gym stuff in a gym locker. The reason I was able to commit to a gym routine was being able to get off my desk, get down the elevator, enter the gym and change in gym clothes in literally 5 minutes. I would never be willing to commute with all that gear. And I never got that gear back.
Same, almost. When I was a student, I rented a locker near the showers so I could start my day at the school gym, shower, and go to my first class.
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.
I know this is not a good year on the job market, but if you are traveling to work with a "go bag" and not leaving coffee mugs on your desk to prepare for being laid off maybe it is time to carry that go bag to some other buildings...
The obvious middle ground is don’t leave anything valuable at your desk that you wouldn’t want to lose. You shouldn’t leave valuable stuff at your desk even if you don’t expect to be laid off. Unless you work in a very secure environment, you don’t really know who will be sniffing around your desk.
Go ahead and leave a coffee mug, who cares if you lose a coffee mug?
I'm really happy I live in a country and company sizes where you could leave your wallet on your desk and nothing happens. Glad I don't need to secure my mug to my desk.
I would be devastated if a few of my coffee mugs were eaten by a firing/layoff. (But I would also not bring those specific coffee mugs to the office, either.)
Yes, I will bag my two tree-sized plants, 4 paintings, 1 old map, 2 posters, drawings of my kids, figurines and a few more things. Ah yes, the ball I sit on.
I spend in the office more time than at home so I want a nice environment.
So this was why the FBI Director Kash Patel was in a panic when he couldn't log in one day. Revoking credentials before firing someone makes a lot of sense in security.
no, becaus the simple and pragmatic solution for ANYONE who is subject to arbitrary termination, is to litter everything they build with caltrops and dead man triggers
and then hint that they will go into "consulting" when fired.
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!
Or if you don't want to booby trap your code, buy one of those tiny devices that make a cricket noise randomly every 5-15 minutes, and hide it somewhere in the restroom.
These are too obvious - 5-15 minutes gives your victim way too many opportunities to narrow down the location.
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.)
I was always curious how come firing a person is a risk in the US culture.
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.
What a stupid move! way to make things worse for yourself! Some people have such low impulse control it is just unbelievable the sort of damage they can do to themselves and others.
I wonder if their stellar academic record is due to the same shenanigans? Given that they were caught manipulating logs and deleting evidence to cover their tracks in 2025, that they did the same to their academic records is technically plausible.
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.
> Muneeb and Sohaib Akhter, now both 34, had been in trouble before. Back in 2015, the brothers pled guilty in Virginia to a scheme involving wire fraud and computers. Muneeb was sentenced to three years in prison, while Sohaib got two.
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?
No, this is exactly what giving people second chances looks like. It means taking a risk that they're the sort of person who is likely to commit a crime and who will commit a crime again after being given the second chance. The only way to prevent this is to have a blanket policy against giving second chances to people convicted of crimes, which harms people who genuinely intend to reform and not commit crimes again, and who you cannot systematically distinguish from chronic criminals.
There are literally thousands of occupations a former computer based wire fraudster can be given a second chance in that aren't here's a computer full of sensitive government files, with CRUD privileges.
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.
The fraud conviction seems totally inappropriate for a government contractor and yet... somehow totally appropriate for someone appointed to work directly for the upper echelons of federal government. Hell, everyone else hacking government officials emails and tax returns and randomly deleting stuff for the lolz in February 2025 was being paid by DOGE.
In my company there were layoffs recently. People had access to production database due to support requests, as we're a young company, so no least-privilege rules were applied yet. Nobody did anything bad. People knew what was going to happen, but no retaliation happened. First, I guess, to not have any problem with law, to pursue the next job without burdens. Things are traceable. Second, why? Why should I destroy my colleagues' work?
Most criminals probably know they will get caught for their crimes and that there may be external or indirect casualties for their crime. Yet it doesn't stop them. Even in places and for crimes with death sentence.
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!
Look the us government (and I'm sure many others) is so inept at basic software construction I can only view this as a good thing. I presume thousands previous penetrations were simply not so trivially detected.
> 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.
I can understand wanting to be perceived as being on “the right team” but that comment is so silly that it undermines credibility. To put it otherwise, could you imagine a scenario where I had a labor, arbitrage opportunity that involved a higher paying job in Shanghai, China and that I had lived there for a few years to do that. Let’s also say that I was found guilty of some similar crime. Would you call me a good old fashioned red-blooded Chinese crook?
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.
Uhh... The guy in charge of the whole thing does things a foreign adversary would do. Has for years and he's back for round two. He even tried to overthrow the government once.
How on earth did someone previously convicted of what sounds like hacking get job access to so many prod government databases? Wild that it took them so long to get caught.
I had the same questions. Apparently discovery of the prior conviction is what lead to them being fired:
> When the company discovered Sohaib Akhter’s felony conviction, it terminated both brothers’ employment during an online remote meeting on Feb. 18, 2025
The company involved here is apparently based in Washington, DC, which has a "Ban the Box" ordinance that limits employment background checks for most kinds of jobs. And apparently DC's version of the law is particularly strict.
The prevents them from asking before extending an offer, but it seems they could (and should) have checked after.[0]
> 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).
Shouldn't this force companies that need to pass a SOC2 out of the district? Doesn't SOC2 require background investigation of personnel with access to sensitive systems?
And I recently couldn't get a job through a federal contractor for a federal position (requiring NO security clearance) because they didn't like something on my credit report.
> 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.
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.
It's probably some sort of crusty old application written before salt and hash was SOP. No agency is going to spend money on hardening something non-critical unless there's an incident or there's free money to do so. And that application was likely written by some contractor who's no longer around or has the source code available so any fixes would require an entire redo. And while you're redoing the whole thing, let's add in a bunch of features and scope creep to balloon the cost and schedule. Oops, the new contractor writing the app is overrun so let's bail and go back to the old version.
Not many people test their backups. I've encountered some situations where the backups didn't work. And one previous employer who was so lazy that he didn't rotate the backup tapes so that the one tape cartridge was used so long that the oxide layer was rubbed off of the tape - so it was no longer brown but was transparent instead (imagine adhesive tape with no adhesive).
Remind me of a forum a long time ago that sent me my password in clear when I used the "forgot password" link.
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.
In my free time, I help maintain the web presence for a small non-profit org with memberships. The original system when I started helping was a bespoke system that was smart in many ways (essentially a static site generator with membership control years before SSGs were cool, with regular automated tests), but the guy who wrote it absolutely insisted on storing passwords in plaintext and could not be convinced otherwise. Eventually he had to drop the volunteer position due to other things in life, and the first thing we did was correct this issue.
There was a screenshot of some website floating around a few years ago, where if you entered the correct password but a wrong username, it would helpfully tell you which user the password is really for.
I've got a better one. I once had the same argument mentioned to me by my manager at the time when I pointed out that passwords were being stored in clear text. That it needs to be this way so that it is read/sent when the users forget their passwords(which happened a lot). I tried to explain that typically a "reset password" flow is used for that but that fell on deaf ears. That system contained healthcare data.
Something bad did end up happening due to that lax security and there were oh so many meetings about it.
> 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...
Yeah, I can relate. It's a problem if you don't bother since you won't be doing your job to the best of your abilities and it's a problem if you do since you might get in trouble with the management for not being a "team player" or some other silliness. Without meaningful consequences, I don't see this situation changing.
Circa 2012 the San Francisco water bill pay was able to send me my password in plaintext when I forgot it. I was scandalized. But the alternative was to not pay the water bill, so I just made extra sure the password was very random and wasn't one that got re-used anywhere... I think they fixed this issue in the years since.
> While this was going on, the brothers held a running conversation. (The government is not clear about whether this took place over text, instant message, or in person.)
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.
<In the US, fired and laid-off workers often have their digital credentials deactivated before they learn about the loss of their jobs; indeed, the inability to log in to a corporate system may be the first an employee knows of the situation.
They still can install traps that detonates if they are fired. A simple cron job is enough to break havok.
Deleting data like that is a crime investigated by the FBI. In a very sad story, a brilliant former coworker made a mistake of deleting data after leaving employment and ended up in prison. Brilliant guy, momentary mistake. Overzealous employer.
These are the cases why I understand HR kicks people out immediately during a layoff. But then the employee cries inhumanity and desires that they have access for weeks, when they no longer need to. It’s a risk that’s proven unwise. Blame the layoff, not the access revocation
This makes sense but also an employee who is dishonest is also a security risk; fired or not.
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.
"Legal Eagle" has a new video about this. The administration's viewpoint is that the Presidential Records Act is unconstitutional, plus the President owns every document, so he can't be forced to return anything because it belongs to him.
My first thought. I was browsing comments to see if everyone from the US did their mandatory bootlicking and yes, they did. Of course they did.
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?"
> [Opexus] said that “the individuals responsible for hiring the twins are no longer employed by Opexus.”
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.
Terminating access and rotating passwords (if needed) while the person is in the meeting but has not yet found out they are being let go has been SOP for at least the last 20 years
Is this specific to US culture? And what about your work environment makes it such a risk?
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?
Heh, a place where I worked some guy who left kept committing code for months (he went to work for a company we were a vendor for). Some of my teammates knew and just thought it was no big deal, he was fixing bugs and adding features.
The color the director turned when he found out!! Oh man.
Was his name … Milton?
"We fixed the glitch"
so he was doing free labor for your company? What's he getting out of that?
he went to work for a company we were a vendor for
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.
> Sounds like he's getting paid to work on the same thing by a slightly different stakeholder.
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.
No company with a legal rep is going to be happy with that situation - ever.
Who even owns the code the person is working on? Who is responsible when it goes wrong?
Never happy is a bit of an exaggeration. SYSV UNIX had all of these risks and various legal departments went through them as they do regularly for more typical types of research.
When it was explicit, and part of the relationship, sure. Because those questions aren’t questions.
Which is why I said you'd sit everyone down and thrash it out.
https://www.nucalc.com/Story/
Just finished reading, love these kind of stories. Thanks for sharing
This story deserves a movie, or at least a long video essay!
Haven’t laughed this hard in a long time.
You might enjoy this story then. 2 guys at apple continue to finish and ship their product after being laid off ..
https://www.pacifict.com/story/
IIRC 50 Shades had a case of "remember me, the woman you fired? I talked to your boss' boss and I'm your boss now"
I have door codes and passwords for a major organisation that I last worked for somewhere in the region of 20 years ago. They haven't rotated a damn thing. I still know people who work there, and I guess technically I still support things for them in an informal question-over-a-pint kind of way, but damn me, put in some effort guys.
My first task at my last job was removing access to an employee being let go. I had just gone through onboarding so I knew every (documented) service we needed to handle. We live tested it on my own accounts, measured the time before I noticed, and then proceeded to successfully go through the checklist.
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!
Amateurs. My employer does mass layoffs by terminating access to everything except their email account at 3am, and then sending an email to the victim saying “you were let go at 3am”. Managers get to figure out who’s left on their team by pinging everyone when they learn about it at work.
Google powerwashes your corp Chromebook when they let you go. A friend was composing an email on the train when their screen went black and the device reset itself to factory settings.
They even send the “you’re being fired” email to their personal email they have on file. Didn’t even schedule a meeting.
Most of the employer behaviour described in such gleeful terms here would be outright illegal in most of Europe and open up the employer to risk of being sued for wrongful dismissal, etc.
Eh, there are ways around that. I've worked for multiple Finnish companies that do layoffs via "lomautus" whereby they put the laid-off employees on a forced, unpaid, indefinite leave. After multiple months of not receiving a paycheck, the employees inevitably "resign".
And then US tech has the arrogance of claiming "we don't need unions".
yeah, shit like what we're reading here is precisely why y'all need unions.
We’re talking about a Google employee that makes 5x or more of what a European counterpart would. Lack of termination notice and other at will employment is easy to plan for when you make so much money.
Until someone starts providing examples of software companies where the employees are unioned and clear $400k+ annum, the bar is still “no unions”.
A full email? We need a "you've been fired" emoji.
U+1FAF5 U+1F525
Man, that's cold.
I think at least on windows you can powercycle it quickly a few times until it gives up this behavior. Not sure about Chromebooks.
If you're talking about Oracle, the large round previous to that they did had individual meetings with employee, manager, and HR. With so many layoffs it took a week+ to do, effectively torturing an entire set of employees who had no idea if they'd have a job by the end of the hour, let alone week.
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)
>I'm not sure there's any good way to lay off large amounts of staff
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?
Either your dates or experiences are off, because I've been working in software since 1999 and the easiest time to get a job was quite recent, in the back-half of COVID. The early 2000's were decent, but I didn't experience - or know anyone who did - any sort of "free jobs' period. Also pay was relatively decent but much less than what you saw even 5 years ago. It's only the in the past year or so that the world has appeared to be ending for developers, and I think that pronouncement is premature.
> the easiest time to get a job was quite recent, in the back-half of COVID
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.
Annecdata: 1996-1999 was super easy, one round start next Monday. 2000-2003 difficult. Easy again until 2008. Hard till 2013. No data since then.
What I hear about today seems crazy hard.
Late '90s were crazy easy compared to anything since. If you could demonstrate any amount of technical skill you were in.
Shortly before the .com bust, I was offered a job if I was willing to drop out of college.
I got my first job by meeting someone on a train Thursday night and starting on Monday morning! (1998)
2004-2007 was hard for me in my experience.
During the dot.com bubble, so many folks went to work for startups that old-fashioned corporate IT (in insurance, industry, banks) was struggling to hire. The saying goes that they hired you if you could spell "C++".
In 1996-1998+ they had something called the Brass Ring job fair in the Santa Clara convention center in the heart of Silicon Valley. Employers would set up booths and some would hire people on the spot.
2021-2022 was pretty good as well.
>Also pay was relatively decent but much less than what you saw even 5 years ago.
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.
You should have tried to create a business or fulfill G-ds hopes for you when you had the chance… but you sold out and took the easy pay check. Now You’re fucked
I know enough people who tried, to be able to tell you that it's not all roses over there. Some had to go back to being a corporate slave and some just continue grinding a barely viable business earning much less than they could at a large company
most businesses are useless scams, few make it big, most people just barely make-by
The 2010s were not that easy to get a job in. It took quite a lot to actually get a job. It didn't take 6+ interviews and takehomes. But you could use a recruiter, go through the interview etc.
There was no leetcode and the resources weren't great. The introduction of leetcode made everything super painful.
How you handle employees after the layoff announcement is a much easier conversation: Give them a lot of dedicated resources to navigate it and give them a good parting offer.
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.
I mean, not to snarkpoast on main, but all of this has happened before re:
> 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.
Oracle?
I experienced that once. The parent and the parent's parent company were from the USA. The top CEO and CTO came over and fired everyone. My laptop was controlling a job that had to run pretty long on a 16 core server, but I did as asked: I shut down the laptop and left it on my desk. That was at least $50k down the drain.
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?
But I'm guessing that doesn't work with someone who's been collecting other logins:
> Muneeb had been assembling usernames and passwords—5,400 of them taken from his own company’s network data.
Though you'd want to make sure there's no essential information that only this employee knows, because that action might terminate that employee's desire to cooperate with the company.
There's the classic article by Matt Ringel and Tom Limoncelli back from 1999:
https://www.usenix.org/legacy/event/lisa99/full_papers/ringe...
I've turned off my own access at least three times when being let go from different jobs
When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence. This is absolutely a standard and has to be for these kinds of positions. I've never worked anywhere where it wasn't for the majority of IT staff. You meet with HR, someone clears your desk, and security walks you out.
There is a middleground, but it requires conscious effort to prop-up, support, and maintain over the long haul: off-boarding centers.
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.
Your last sentence sums it up. I was blown away by the system you described that would allow for such a humane transition through such a difficult time. At least process wise it seems like a good place to work.
It really was. I’d gladly go back, too, but they’re not hiring IT folks with my skills atm.
you left out the people who enjoy the suffering and pain of the person it is being done to, while they supervise (and film it, in some cases)
> When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence.
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.
For most of my career (over 30 years now) where I've had sufficient access privileges to matter, I've fairly diligently maintained a "Important credentials and access" list, which I've sent to my employer when leaving, strongly advising them of the need for them to disable or rotate those credentials.
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.)
The first option is flipping one switch. The second option is flipping some switches now, and flipping the rest later. Of course the safest (first) option is the correct option from a liability standpoint, which is all a company should operate on since it's first responsibility is to protect the company for those that are still there. There's plenty of ways to communicate with ex-colleagues that don't involve company resources or opening the company up to liability.
Let’s not forget the third option: proper security practices and principle of least privilege. No one should have been able to do this in the first place. Why were they able to get plaintext passwords with a simple query? Why did they have delete permissions on production db tables? Why were they able to modify system logs and delete backups?
> Of course the safest (first) option is the correct option from a liability standpoint, which is all a company should operate on since it's first responsibility is to protect the company for those that are still there.
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.
System security is not a human value. Access key rotation effective immediately is a compliance requirement, and completely orthogonal to human decency, which is delivered trough garden leave or severance, not extended system access
So, never lived in corp land? Healthy isn’t on most corporations radars except where it causes liability to them.
I haven't, but the parent said that this is what a company "should" do, not just what they do do.
I'd argue that failing to segregate things so that there's a switch for the sensitive stuff and a separate switch for the not-sensitive stuff is an operational failure. A rank and file employee having access to his email account should never pose a serious liability to the business.
Yeah I don't see why that's necessary. I'm sure you can always reach out to HR and ask (I have facilitated this in the past, pulling contact lists and phone numbers) but that also gives them ways to exfiltrate data. It's company data. Just think of all the info you have in your inbox. Unless you've managed offboarding for high level IT positions it seems harsh, but the risk is just too high to allow the user to do that stuff themselves.
> Just think of all the info you have in your inbox.
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.
No you don't get it, we have to take a harsh approach to firing people because we keep pallets of high explosive in the break room and management doesn't want to change that. /s
High level IT positions are not risky. This is the db admin who can do most of the damage.
If you don't trust your people so much, why to hire them in a first place?
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.
sometimes you fire because you trusted them then they gave reasons to stop. At company I work at it happened, but the more common way is just getting info few weeks later then working normally till the end date
>Looking at it from Europe - it is such a weird inhumane practice.
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".
No this is labour law in the UK, I just had this last year. Its 3 months where you get paid and you can search for a job etc. Made our new American CEO livid that he could not just fire people.
More specifically in the UK there are a few ways employees can be dismissed.
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.
All the couples I know who are divorced did continue living together after one of them said it was over, I think the longest time actually was about 6 months.
Yeah but did they still keep banging and cuddling like before the divorce announcement? They probably weren't doing much of that anyway if they got divorced but you get my point.
Looking at it from Europe, this definitely also happens. It depends on the situation. I know of ppl who were kept bcs the parting was in good faith (which was less a firing and more an agreement that parting is in everyone's interest), but I also know of ppl who had their access revoked before firing bcs it wasn't. The latter had unilateral system access as well, which added to it. It's not about humane or inhumane, it's about risk. The 3-6 months being nice is also a fairytale that I have only ever heard in a positive light from employees who are not particularly ambitious or awake or in any way satisfied with their jobs or the prospect of a future job. On the other hand from the perspective of employers it's consistently hard to effectively restructure, it's expensice and awkward to have to pretend to want to keep someone around that you or they don't want around.
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.
Europe is not falling behind on anything that is not reasonable.
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.
> It's part of the reason why Europe is falling behind on everything.
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.
That lawsuit sounds legitimate enough to me.
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.
>They couldn't find anything for her to do? Hard to believe,
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.
She had 20 years to resign if it was such a terrible ordeal
They were trying to force her to resign, so she would lose any unemployment benefits.
>Ithey 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'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 curious, the person is Laurence Van Wassenhove. That should suffice to find out more on the story. Interesting tale.
The anomaly there is that France Télécom was a public company at the time of the hiring, and through privatisation public servant benefits were upheld for existing employees, which blocked most unpythonesque solutions.
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.
Yeah but if you defense against somebody erasing a database is "we remove their access when they're fired" then your defense is garbage.
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.
I'm talking about off-boarding not general day to day security.
But I'm talking about general day-to-day security as well as off-boarding. What stops a single disgruntled employee from doing this before being fired? And if you have a good story there, why do you need the most extreme approach to "off-boarding"?
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.
I suppose that's a very powerful way of preventing "accidents" on termination. But isn't that just theatre? I mean - as though termination is the one and only case where an employee with the power to destroy the company gets angry and might do something really stupid?!
It's not theater, it's defense against aggrievement. Termination is a traumatic event that threatens your ability to exist or provide for dependents. People [rightfully] don't handle exile well.
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.
> 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.
Ok but with the European laws the incentive to do something at the last minute doesn't really exist.
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.
Having people with that level of access without some form of two-person-control is already a sign of incompetence.
Twins can defeat two-person control (okay I know one of them was locked out).
You always have to be careful about overfitting to a specific scenario like "this but if they had also forgotten to lock out the other evil twin". I'd prefer a system that is robust to a malicious employee (more likely: compromise of an employee's credentials) but has a slight gap in the "evil twins" scenario over one that prevents all post-firing malicious access from twins but doesn't consider at all what happens if a current employee's credentials are compromised.
TFA: Twins Fucking Authenticate!
Maybe they did, but since they were twins...
This takes the whole "you must mean my evil twin" to an actual example. Maybe this is more "you must mean my other evil twin". Part of me really wishes their names were Daryl
There is another thread elsewhere on the first page about low-trust USA.
Sadly, behaviors and expectations converge toward one another.
Last time I was laid off they let me keep my laptop for the rest of the day. I gave it to them immediately to avoid any accusations of sabotage.
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.
Last time I resigned, I got to keep the laptop and got to promise I had deleted everything work-related.
I work in government. If you think that is incompetence, then I have stories that could make your skin crawl.
They do all of that now though...
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 problem is that its so challenging to figure out what the person actually has access to. Have they ever done a export with sensitive information, that is now sitting on their local machine? Any important clients they still are in contact with over email that they may try to sabotage? Any other creative endeavors you haven't thought through?
The most fool proof way is just to nuke the computer in its entirety.
Privileged access should only be temporary in context of break glass with approval. People can go ballistic with core systems for reasons other than firing.
In an age of malicious agentic AI, this level of access is negligent. A lack of engineering controls preventing this from happening at all means that a simple phishing or supply chain attack could easily have resulted in the same outcome or worse.
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
The employee is always the last to know. This is standard fare.
> a more balanced version: <bunch of weedy ACLs, judgement calls, liability/>
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.
> Too complicated and subjective, stinks of more risk.
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. :-(
Then Opexus fired the one who said it.
Leaving no one to say anything anymore on their behalf.
> On March 12, 2025, a search warrant was executed at Sohaib’s home in Alexandria. Agents grabbed plenty of tech gear but also turned up seven firearms and 370 rounds of .30 caliber ammunition. Given his former crimes, Sohaib should have had none of this.
For god's sake, don't commit crimes while you're committing crimes.
I was kind of hoping he sprinted out his back door which happened to be on a state line and then mailed his guns back to his house, just to try to cover everything.
> Given his former crimes, Sohaib should have had none of this.
Nobody should have a personal armory.
Fortunately enough Americans have enough guns that no matter how much people like you whine about it you'll never be able to take them away.
Burglars take them away pretty often. Out of reported firearm thefts, most happened to those who had six or more such items.
It's funny how it's never just one thing.
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.
I'm not a big "lock them up" guy but seriously people don't seem to understand how hard it is to actually get the state to put and keep you in jail. You have to do really really bad things multiple times. The US prison population has been falling for over a decade now and part of that is everybody now faces pressure to not use incarceration as a first (or second or fifth) option
There is a strong bias towards stupid criminals getting caught.
Only commit one crime at a time
Serially.
Waterfall style
> At 4:58 pm, he wiped out a Department of Homeland Security database using the command “DROP DATABASE dhsproddb.”
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.
> 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?”
So many red flags, I can't even.
> In the space of a single hour, Muneeb deleted around 96 databases with US government information. He downloaded 1,805 files belonging to the EEOC and stashed them on a USB drive, then grabbed federal tax information for at least 450 people.
Maybe whoever runs infosec at that place should also be fired?
Brave of you to assume they had anyone running infosec by the sounds of it
Elon's brother's landscaper's nephew's girlfriend was sacked along with Elon, so nobody was filling that role in the government.
Which MAGAts applaud. Emptying the swamp!
Yep, Windows Server 2012 being a big one :o
They forgot a
> "How do I clear chat logs from LLM?"
I guess?
I love how this leaks out the fact that the DHS is running production databases on operating systems that are months away from end of extended support.
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.
> 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.
I wonder how foreign governments do it? Better or worse
It can be quite politically valuable to kick the can to the next administration.
The day-to-day operation of large government bureaucracies is surprisingly immune to elections. The same people stay in the same job for decades, the "churn" only happens at the highest levels, and even those positions tend to outlast changes in the current political party in charge.
Did you not see what happened in the last year to federal workers?
Unfortunately this is a good example of kicking the can. Not to the next administration but to after the next elections. Some aspects are felt already but not all.
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.
This problem has been "cooking" for 12.5 years, not 1.
You're off by an order of magnitude, sadly.
It’s a contractor to the DHS, but I’m not sure that makes it worse or better.
That's normal in big bureaucracies. I've worked on systems nobody wanted to breath around because nothing could be fixed.
To be fair, this transpired last year, so they actually had one year and some months before losing extended support.
That said, they should have migrated it years ago.
Ready access to AI tools sure makes vandalism easy.
This vandalism is a joke. You could find the method in an XKCD comic.
The fact that they didn't already know how to do it is the crazy part.
Ai is just a tool. You can kill with hammer, doesn't mean you ban hammers. And they could have used stack overflow instead of ai.
The tools we use are not neutral. A sword can be made to work like an axe, but we use axes for chopping wood because a sword makes a shitty axe. A sword is designed to kill people. The handle, the mass, the weight distribution, and every other aspect I am not qualified to get in to, means swords are designed to kill. They are a tool, and their use is not neutral.
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 computer keyboard: https://www.deseret.com/1997/7/6/19322063/mother-charged-wit...
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...
The fact that you had to find an article from three decades ago for an instance of killing with a keyboard is telling. All the others aren’t exactly that recent and are mostly isolated cases. Meanwhile, on gun related deaths, there are entire Wikipedia pages for it:
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.
My larger point is that nobody - nobody - defaults to telling us the coffee mug is unregulated, as AI allegedly ought to be. They always compare it to something much more commonly used as a weapon; something that, when asked to name a household object likely to be used as a weapon, the average person would guess.
Your point is that people make a stronger argument even when a weaker one would be sufficient?
Instead of comparing AI to any other tool, especially one closer to "useful with a computer", the common comparison is always a weapon of some kind.
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
That’s a non-sequitur. You don’t need to defend AI, your parent comment isn’t attacking it, simply making an observation.
> 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.
My god, they didn't say ban ai they said it makes vandalism easy.
No need to knee jerk react to an argument that hasn't been made.
It's not knee jerk to respond to an obvious contextual implication.
Absolutely wasn’t where I was going with that.
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.
Fair enough. I guess an LLM in an IT administration role could be aptly compared to a bulldozer.
You are the first person in this conversation to mention banning. I am not sure what your comment has to do with anything.
A tool which is supposed to supercharge you - supercharges you.
> So many red flags
starting with Windows Server _2012_ :O
As somebody who's spent most of my career in Fairfax County I find nothing about this story even remotely surprising.
Those two in the movies were always a highlight for me, especially when the one joins the other in the Mexican factory riot.
One of my favorite lines "Peligroso es mi nombre medio" (which of course is not grammatically correct in Spanish) and then his short inspirational speech invoking general Zapata were great.
Are you a man?
Yes, 19.
Are you alive?
Yes, 18!
Evel Knievel.
—
They also come off as a little bit rosencrantz and guildenstern imo
I think its them on video: https://youtu.be/Rx19zOzQeis
I'm just amused how these people were even hired to begin with ? They don't seem to be Americans? How were they even allowed to work on sensitive systems? Why was this even allowed? So many questions.
They were born in Maryland, and apparently quite skilled (or at least skilled at cheating their way through their studies, if not genuinely technically skilled).
https://www.somdnews.com/archive/news/19-year-old-twins-high...
I mean it's the DHS. Let's not pretend they're known for competence or hiring the best and brightest. Glorified chimps with ties and guns.
I would imagine they lied about having a felony conviction on their job applications, and that for whatever banal reason any background check service they used didn't flag it, or the contractor was so grossly incompetent they didn't even check.
>> They don't seem to be Americans? How did you conclude that? Just their names?
A few other circumstantial things lightly hint at the twins not being typically American:
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)
> "most Americans of their intelligence would be aware"
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.
> that would still leave up to 49% .... how did you conclude?
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.
These are not remotely indicators that someone is an American citizen.
I take it you're not in HR at the CIA or FBI, which vet applicants' families for a reason. i.e. how long ago applicants and/or their families came to the US does help predict their loyalties... It might not be a strong nor fair predictor, but it's not zero either.
"So the 2 brothers are named Eric and Donald Jr., they're white. No worries, must be upstanding citizens!"
We are all Americans but some are more American than others.
I'm not.
If their names were Eric and Donald Jr., surely they wouldn't have been doing petty crimes like these two...
Hmmmm:
> 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??
About 25 years ago we had layoff at a company I worked for. One of the DBA's got fired along with others. Back in the day they didn't revoke access and you had your work computer available until the end of the day. Most, who were fired, just packed and went on their way.
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!
That seems… normal?
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 don’t know where to start with this other than to point out that there is no way in hell these two clowns had the security clearance necessary to access a prod DB at DHS. I can only assume they stole creds from another employee who had that level of clearance. Also, tax records are not stored in a DHS domain .
I think this story has been sanitized to mask some details which is ok I guess but I ain’t buying the back story.
> it does follow from the simple fact that a fired employee with access to company systems is a security risk.
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
How did they get access to 5k passwords? Are they being sent/stored in cleartext? This is the most baffling part of the article for me.
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.
From the article, it sounds like the passwords are indeed stored in cleartext:
> 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.
It still blows my mind. Shouldn't the government audit their contracting companies for egregious issues like this? Seems extremely reckless not to.
I've been through a handful of SOC2 audits and they've never asked us to _prove_ that we aren't storing passwords in plaintext or with reversible encryption (we weren't).
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.
I'm pretty shocked as well. I thought every company stopped doing this like 20 years ago? Even for a legacy system that is a long time to continue storing credentials like that.
20 years is rookie numbers in these systems. I guarantee it’s been at least 40 years since a single fuck was given.
My wife works in IT at a mid sized city. They still store credentials in source control.
Policy and practice might not be the same thing. The company and the entire management staff should be on somebody’s blacklist for future procurement.
The tighter your security is, the more inconvenient it is for legitimate users, and the more you have to do audits because it's easy to justify going around security in the name of efficiency.
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.
The whole point of stuff like SOC2 and audit to verify that policy is actually implemented. Seems like nobody actually checked.
SOC2 requires an audit. But one of the weaknesses of SOC2 is that the audit mostly checks to determine that you are following whatever your policy is. It doesn't verify that your policy is rigorous.
I don’t think you understand what SOC2 is.
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.
Depends on what their offboarding policy is. If it's 72 hours or something they would not breach policy.
And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored.
The only solution is correct access segregation and a bastion
You should never store passwords in plain-text, encrypted or not, you should always use a one-way cryptographic hash like bcrypt [0], scrypt [1], or PBKDF2 [2], combined with a single use salt [3] and optionally a pepper [4], and then store the output of the hash in the database.
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
[3] https://en.wikipedia.org/wiki/Salt_(cryptography)
[4] https://en.wikipedia.org/wiki/Pepper_(cryptography)
(I will be copy/paste this answer for the other comments)
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 :)
Hashed, you store them hashed (and salted). A breach should never reveal passwords.
(I will be copy/paste this answer for the other comments)
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 speak very authoritatively on something you don’t know.
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.
(I will be copy/paste this answer for the other comments)
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 :)
I hope youre joking
(I will be copy/paste this answer for the other comments)
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 :)
Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.
Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.
And rainbow tables appeared too.
Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the client, and sent to the server the attacker doesn't need to reverse the hash, they can just send the hash in the request. Instead, you should send the password to the server (using TLS encryption) and do the hash and compare on the server.
You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison.
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.
Hashing client side is sufficient because the only service you can breach with the hash is the one you already had to breach in order to read the database.
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.
People shouldn't be downvoting this...
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.
I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side?
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.
> This seems to mostly prevent accidental logging
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.
Yes limited protection against insiders is good defense in depth but not the primary purpose which is to protect end user accounts on other services in the event that you are breached.
My question still stands: how do you disallow cleartext password extraction if you are breached, assuming all your IT infrastructure and code is now accessible to an attacker?
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.
There are substantial differences between database access, snooping the logs, internal (no TLS) wiretap, and full MITM of the frontend.
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.
We are not disagreeing, but I am not getting my answer: how is client side hashing really helping, what are the circumstances it helps with if you do have the basics right?
In your enumeration, what is breached for this to be meaningfully impactful for other services where customers might be reusing credentials?
As opposed to what? Your question seems unclear to me.
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.
There is certainly good reason to do server-side hashing: you do not keep a persistent record of the customer's secret, yet keep the ability for them to authenticate with it.
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.
> There is certainly good reason to do server-side hashing: you do not keep a persistent record of the customer's secret, yet keep the ability for them to authenticate with it.
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.
(I will be copy/paste this answer for the other comments)
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 don't store passwords.
You store safely crafted hashes.
I don't think those words mean what you think they mean.
Assuming you're serious? Store passwords with salted one-way hashes.
I can only think of a scenario where this is still valid: spying.
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.
I have no problem with my credentials being revoked everywhere before I know about a layoff. I don't really care how I learn about it, just please don't make me come in to the office.
> just please don't make me come in to the office.
But how do you pick up the stuff from your desk? I once lost a nice pair of headphones this way.
I've never had a job with a permanent individual desk like this. The one in-person real job I had, it was only shared working space that different people used at different times of the day or on different days, and I think you were discouraged from leaving anything. The idea of there being "your desk" with a framed photo of your kids and favorite coffee mug seems like a nearly extinct piece of nostalgia. It must have been nice in a way, far preferable to the new style of open office at least.
May I ask how long you've been working?
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.
I'm on my third job since COVID. None have dedicated desks, and this ranges across startups, corporates and large govt agencies.
Every job I had before COVID back to when I started back in the early/mid 90s had dedicated desks.
2017 I believe.
ship it?
Meh. Don't leave anything at work. Forgo the convenience and carry your things on your commute. Use a bag. If there's "too much stuff", that's a sign to pare back what you "need" at work.
God, if we're at the point where we're so paranoid about being laid off that we don't dare leave a single piece of personal property in the office then I think we're in a very dark place indeed. Can’t imagine the mental damage from considering losing your job every single day you wake up.
I never left anything valuable or personal at my desk when I worked in an office simply because I had a very nonzero number of colleagues who acted like animals. My fizzy waters, coffee, and snacks would be consumed without permission or replenishment. Chairs, monitors, and input peripherals would get swapped without asking. Desks surfaces would be sat on with chairs used as footstools. Corporate effluvia of all types would end up on my "unused desk" because I wasn't in at the exact moment some roving bandit walked by looking for a spot to dump their crates of paper and binders.
Some people simply have no regard for others and will mess with or jack your shit. Don't give them the chance.
I always thought it was weird that all of the equipment issued to me beyond the laptop was registered to me, such as the monitors and desk phone. Your comment enlightens me... That's wild to imagine folks just swiping things from other peoples desks. We even have storage rooms of office supplies where someone could drop off their crate of paper and binders if they had one for some reason.
well this did just happen to me. laid off while taking care of my father in laws estate and my personal belongings were thrown away. 7 years at the company as an EM ftr.
I had my gym stuff in a gym locker. The reason I was able to commit to a gym routine was being able to get off my desk, get down the elevator, enter the gym and change in gym clothes in literally 5 minutes. I would never be willing to commute with all that gear. And I never got that gear back.
Still a net positive in my experience.
Same, almost. When I was a student, I rented a locker near the showers so I could start my day at the school gym, shower, and go to my first class.
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.
I know this is not a good year on the job market, but if you are traveling to work with a "go bag" and not leaving coffee mugs on your desk to prepare for being laid off maybe it is time to carry that go bag to some other buildings...
The obvious middle ground is don’t leave anything valuable at your desk that you wouldn’t want to lose. You shouldn’t leave valuable stuff at your desk even if you don’t expect to be laid off. Unless you work in a very secure environment, you don’t really know who will be sniffing around your desk.
Go ahead and leave a coffee mug, who cares if you lose a coffee mug?
I'm really happy I live in a country and company sizes where you could leave your wallet on your desk and nothing happens. Glad I don't need to secure my mug to my desk.
Even in the safest country I would never intentionally leave my wallet at my desk.
I would be devastated if a few of my coffee mugs were eaten by a firing/layoff. (But I would also not bring those specific coffee mugs to the office, either.)
It feels a little weird to tell people not to personalize or make comfortable a place that they might spend 8 hours a day at, 5 days a week.
Many humans like to decorate their desks, keep personal stuff there. It's normal.
If they are keeping your personal possessions, isn't that theft?
Yes, but the company may well be judgement-proof at that point.
Yes, I will bag my two tree-sized plants, 4 paintings, 1 old map, 2 posters, drawings of my kids, figurines and a few more things. Ah yes, the ball I sit on.
I spend in the office more time than at home so I want a nice environment.
So this was why the FBI Director Kash Patel was in a panic when he couldn't log in one day. Revoking credentials before firing someone makes a lot of sense in security.
> So this was why the FBI Director Kash Patel was in a panic when he couldn't log in one day
Ever tried to login with two factor and justify a maxed out company card while high as a kite and drunk?
It’s stressful.
Professionally, he spells his name thusly: FBI Director Ka$h Patel, so you know he’s serious.
Written in bourbon
no, becaus the simple and pragmatic solution for ANYONE who is subject to arbitrary termination, is to litter everything they build with caltrops and dead man triggers and then hint that they will go into "consulting" when fired.
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!
Or if you don't want to booby trap your code, buy one of those tiny devices that make a cricket noise randomly every 5-15 minutes, and hide it somewhere in the restroom.
https://annoyingpcb.com/
These are too obvious - 5-15 minutes gives your victim way too many opportunities to narrow down the location.
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.)
Next time I'm bored and need a project, I'm building that ;-)
That is some top notch wrongthink… HN does NOT find it funny!
I was always curious how come firing a person is a risk in the US culture.
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.
He may be a bad person but he has a very pretty handwriting.
Your comment made me go read TFA, and yes, that is rather pretty handwriting.
What a stupid move! way to make things worse for yourself! Some people have such low impulse control it is just unbelievable the sort of damage they can do to themselves and others.
I wonder if their stellar academic record is due to the same shenanigans? Given that they were caught manipulating logs and deleting evidence to cover their tracks in 2025, that they did the same to their academic records is technically plausible.
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.
> Muneeb and Sohaib Akhter, now both 34, had been in trouble before. Back in 2015, the brothers pled guilty in Virginia to a scheme involving wire fraud and computers. Muneeb was sentenced to three years in prison, while Sohaib got two.
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?
No, this is exactly what giving people second chances looks like. It means taking a risk that they're the sort of person who is likely to commit a crime and who will commit a crime again after being given the second chance. The only way to prevent this is to have a blanket policy against giving second chances to people convicted of crimes, which harms people who genuinely intend to reform and not commit crimes again, and who you cannot systematically distinguish from chronic criminals.
There are literally thousands of occupations a former computer based wire fraudster can be given a second chance in that aren't here's a computer full of sensitive government files, with CRUD privileges.
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.
The fraud conviction seems totally inappropriate for a government contractor and yet... somehow totally appropriate for someone appointed to work directly for the upper echelons of federal government. Hell, everyone else hacking government officials emails and tax returns and randomly deleting stuff for the lolz in February 2025 was being paid by DOGE.
The article isn't particularly clearly written, but it seems like their background checks were bad and were fired once management figured it out.
In my company there were layoffs recently. People had access to production database due to support requests, as we're a young company, so no least-privilege rules were applied yet. Nobody did anything bad. People knew what was going to happen, but no retaliation happened. First, I guess, to not have any problem with law, to pursue the next job without burdens. Things are traceable. Second, why? Why should I destroy my colleagues' work?
Most criminals probably know they will get caught for their crimes and that there may be external or indirect casualties for their crime. Yet it doesn't stop them. Even in places and for crimes with death sentence.
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!
Nice handwritings, though.
prosecute the company too.
storing passwords in plaintext should be persecuted & having unlimited access to customer databases.
A true professional always makes sure to leave their workspace completely spotless before going home
So no guns and ammo?
Look the us government (and I'm sure many others) is so inept at basic software construction I can only view this as a good thing. I presume thousands previous penetrations were simply not so trivially detected.
> 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.
WTF?
This whole story is just line after line of utter incompetence.
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.
> “Delete their filesystem as well?” he said.
> “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..
Dumb and dumber. Criminals just can't stop doing crimes (the password stuff, the gun stuff, etc, etc).
It’s crazy that people are desperate for jobs and these clowns get hired.
Well, who else would you hire for the circus?
Perhaps don't hire people who act as foreign adversaries for government work? Is that really such an absurd proposition?
You can’t assume someone is foreign based on their name.
In fact I’d guess they’re not, since they’ve been employed on government projects since a young age.
>who act as foreign adversaries
This does not mean they are from another country.
I don't think they were spies. They have ethnic names, but it sounds like they are just good ol' red-blooded Yankee crooks.
I can understand wanting to be perceived as being on “the right team” but that comment is so silly that it undermines credibility. To put it otherwise, could you imagine a scenario where I had a labor, arbitrage opportunity that involved a higher paying job in Shanghai, China and that I had lived there for a few years to do that. Let’s also say that I was found guilty of some similar crime. Would you call me a good old fashioned red-blooded Chinese crook?
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.
It was a silly comment. It was meant to be.
As opposed to...
What is this even supposed to mean? “I was joking, and it’s your fault for taking it seriously?”
> Perhaps don't hire people who act as foreign adversaries for government work?
Hilarious in the context of this administration.
Yeah. Here in america, we demand domestic adversaries!
Uhh... The guy in charge of the whole thing does things a foreign adversary would do. Has for years and he's back for round two. He even tried to overthrow the government once.
He wasn’t hired, he was elected.
That's a bit pedantic. There's really not much of a difference there.
He can be fired too, but the current shitheads in charge would never do that.
Maybe they're really, really good at leetcode. You can't pass up talent like that. </sarcasm>
Sidenote I love that the DHS prod DB is called “dhsproddb”.
How on earth did someone previously convicted of what sounds like hacking get job access to so many prod government databases? Wild that it took them so long to get caught.
I had the same questions. Apparently discovery of the prior conviction is what lead to them being fired:
> 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.
The company involved here is apparently based in Washington, DC, which has a "Ban the Box" ordinance that limits employment background checks for most kinds of jobs. And apparently DC's version of the law is particularly strict.
The prevents them from asking before extending an offer, but it seems they could (and should) have checked after.[0]
> 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...
Shouldn't this force companies that need to pass a SOC2 out of the district? Doesn't SOC2 require background investigation of personnel with access to sensitive systems?
And I recently couldn't get a job through a federal contractor for a federal position (requiring NO security clearance) because they didn't like something on my credit report.
> 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.
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.
It's probably some sort of crusty old application written before salt and hash was SOP. No agency is going to spend money on hardening something non-critical unless there's an incident or there's free money to do so. And that application was likely written by some contractor who's no longer around or has the source code available so any fixes would require an entire redo. And while you're redoing the whole thing, let's add in a bunch of features and scope creep to balloon the cost and schedule. Oops, the new contractor writing the app is overrun so let's bail and go back to the old version.
This is what I want to know. Are there any consequences for this contractor? At least fraud or negligence or something?
The handwriting was very solid.
No back ups? Skill issue.
Not many people test their backups. I've encountered some situations where the backups didn't work. And one previous employer who was so lazy that he didn't rotate the backup tapes so that the one tape cartridge was used so long that the oxide layer was rubbed off of the tape - so it was no longer brown but was transparent instead (imagine adhesive tape with no adhesive).
The article says that they did have backups
so, apparently, the passwords were stored in cleartext.
Remind me of a forum a long time ago that sent me my password in clear when I used the "forgot password" link.
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.
In my free time, I help maintain the web presence for a small non-profit org with memberships. The original system when I started helping was a bespoke system that was smart in many ways (essentially a static site generator with membership control years before SSGs were cool, with regular automated tests), but the guy who wrote it absolutely insisted on storing passwords in plaintext and could not be convinced otherwise. Eventually he had to drop the volunteer position due to other things in life, and the first thing we did was correct this issue.
There was a screenshot of some website floating around a few years ago, where if you entered the correct password but a wrong username, it would helpfully tell you which user the password is really for.
But did they handle the edge case of two users having the same password?
"That password's already been taken by user 'mekdoonggi'"
Product manager; “That’s a great UX.”
I've got a better one. I once had the same argument mentioned to me by my manager at the time when I pointed out that passwords were being stored in clear text. That it needs to be this way so that it is read/sent when the users forget their passwords(which happened a lot). I tried to explain that typically a "reset password" flow is used for that but that fell on deaf ears. That system contained healthcare data.
Something bad did end up happening due to that lax security and there were oh so many meetings about it.
> 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...
Yeah, I can relate. It's a problem if you don't bother since you won't be doing your job to the best of your abilities and it's a problem if you do since you might get in trouble with the management for not being a "team player" or some other silliness. Without meaningful consequences, I don't see this situation changing.
> Defeated by such argument, I deleted my account.
I'd bet your account wasn't actually deleted, just marked as deleted or inactive.
Circa 2012 the San Francisco water bill pay was able to send me my password in plaintext when I forgot it. I was scandalized. But the alternative was to not pay the water bill, so I just made extra sure the password was very random and wasn't one that got re-used anywhere... I think they fixed this issue in the years since.
Gnu Mailman still does this, and sends a monthly reminder email of your password.
Greetings, Bioconductor
Some good handwriting
> While this was going on, the brothers held a running conversation. (The government is not clear about whether this took place over text, instant message, or in person.)
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.
Probably confession
Claude: drops production zone with the database and backups
Meatbags: hold my beer...
Dude gets A++ on penmanship, seriously someone should make a font.
Hire ethical people.
<In the US, fired and laid-off workers often have their digital credentials deactivated before they learn about the loss of their jobs; indeed, the inability to log in to a corporate system may be the first an employee knows of the situation.
They still can install traps that detonates if they are fired. A simple cron job is enough to break havok.
This is very surprising that they would pass a background check. I've been denied an offer because of a low credit score multiple times.
Deleting data like that is a crime investigated by the FBI. In a very sad story, a brilliant former coworker made a mistake of deleting data after leaving employment and ended up in prison. Brilliant guy, momentary mistake. Overzealous employer.
These are the cases why I understand HR kicks people out immediately during a layoff. But then the employee cries inhumanity and desires that they have access for weeks, when they no longer need to. It’s a risk that’s proven unwise. Blame the layoff, not the access revocation
This makes sense but also an employee who is dishonest is also a security risk; fired or not.
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.
The penmanship of the guy is extremely neat, like, uncannily so
Asked for the plaintext password, and then his brother made a “ database query on the EEOC database and then provided the password”.
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.
imagine the delete-fest the current whitehouse is going to do in a few years
all with pardons waiting so they can't be convicted
they might not even wait a few years
"Legal Eagle" has a new video about this. The administration's viewpoint is that the Presidential Records Act is unconstitutional, plus the President owns every document, so he can't be forced to return anything because it belongs to him.
They might not leave, at all.
Oh no, the workers have power!
My first thought. I was browsing comments to see if everyone from the US did their mandatory bootlicking and yes, they did. Of course they did.
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?"