341–350 of 463 posts
Oh no, the workers have power!
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?"
Earlier quoted context omitted.
[flagged]
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
Earlier quoted context omitted.
> 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…
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 wa…
Earlier quoted context omitted.
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.
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.
Until someone starts providing examples of software companies where the employees are unioned and clear $400k+ annum, the bar is still “no unions”.
> [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…
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
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 . Who puts that in their HTML?
> 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??
> [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…
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
Earlier quoted context omitted.
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 valu…
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 :)
Earlier quoted context omitted.
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
Hashed, you store them hashed (and salted). A breach should never reveal passwords.
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 :)
Earlier quoted context omitted.
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 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.
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 :)