Hacker Newsnew | past | comments | ask | show | jobs | submit | jarkhen's commentslogin

I can't really speak to the first part of your message, since I've never really tested anything like that, but at least anecdotally I've never really noticed any additional click latency in Linux compared to Windows.

For the second -- FFXIV works flawlessly _once you get it set up_, but there's a couple tweaks to deal with to get there -- the launcher in particular (the default/"modern" launcher doesn't play nice). Games with separate launchers in general seem to have more issues/be more finicky in Proton. I don't personally use ACT, so I don't know if there's any real issues with setting it up, but I know others on Linux who do so it's at least possible. For your reshade concerns, GShade[1] comes with a linux install script that I've had no issues with.

[1]: https://gposers.com/


Believe it or not, League of Legends actually works pretty well on Linux (I run it through Lutris). It takes a while for the launcher to initially load on startup, and the launcher is a bit of a slow/laggy mess, but from what I hear from my Windows friends the latter at least is just a general LoL launcher problem more than a Linux problem. Once you actually load into a game it runs completely flawlessly, with great performance.


With all the work that's gone into Proton over the past few years, the vast majority of games Just Work and there's very well-documented tweaks for making the vast majority of the rest work as well. It's relatively rare to have a game that's completely unplayable on Linux, unless it's hampered specifically by anti-cheat software that doesn't like Linux.


A bunch of games in Proton pretty much work in singleplayer and very few work in multiplayer due to anti-cheat software incompatibilities.

It’s disingenuous to steer people toward Proton without mentioning that fact about multiplayer, given how hugely popular multiplayer is.


Not if one doesn’t play any multiplayer games. There are many who don’t.

If you’re looking to switch then shouldn’t you be doing your own research? Words like disingenuous reek of fanboyism.


I have high hopes that the apparent future popularity of the Steam Deck will make a serious dent into this shortcoming within the next year.


The anti-cheat software (which borders on being spyware) is the issue, in particular for very popular games today.


> I'm not sure how one could avoid dressing to express oneself, to at least some degree, unless you exclusively wear work uniforms or hand-me-downs.

Exclusively wearing work uniforms (outside of work) or hand-me-downs is still, in its own way, expressing oneself. One way or another you make a personal decision on how to dress and whether to follow a particular style, trend, price point, etc. and that reflects something about you.


> My company doesn't even hash passwords...

I understand this is somewhat my privilege speaking here, but I don't think I could continue working at a company that didn't do something as basic as hashing passwords (and refused to prioritize fixing that as soon as I pointed it out). It's a massive ethical, if not legal (IANAL), liability -- and a huge breach of users' trust. It's 2021, hashing user passwords is astonishingly easy; I can't imagine any remotely justifiable excuse for something like that.


For what it's worth, the European Union Agency for Cybersecurity publishes recommendations[0] for measures that digital services should implement to fulfil their responsibilities under the GDPR. One of the recommendations, K.6 is:

> User passwords must be stored in a “hashed” form.

These guidelines aren't legal requirements for every service, but if a data breach occurred, and passwords were leaked, regulators would presumably point to this recommendation, and the ease of complying with it, and take that into consideration when issuing a fine.

[0] https://www.enisa.europa.eu/risk-level-tool/help


If the string changes each time, how could they possibly have the matching hashed password stored in the database?


They have the users password hash stored in their db so they can replicate the process server side:

login_token = hash(pwd_hash + nonce)

its nothing too wild, especially considering the age of yahoo mail.


Ah, right, I misread the original description of what they were doing.

As is, then, it really is just making the hashed password the new password. If I can get the hashed password out of the DB, I can load the login page and simply skip the initial hashing step that's done on the frontend. I now have access to the account without ever knowing the original password.


Except that it's easy (indeed, required for security) to change the nonce for each login request, so you can't just replay the hash.


That protects against an attacker reading network traffic. It does not protect against an attacker that has the hashed password from the DB.

The only thing you need in order to authenticate at any given time is the hash of (hashed password + nonce). The latter you get for free, at any time, from the server, so you only need to know the hashed password -- not the password itself. Since the hashed password is directly stored in the DB, if you get your hands on that you can authenticate.


Right. My mistake. I should have thought it through more thoroughly before posting. Hopefully my comment doesn't mislead anyone, I'll try to do better in the future.


Unfortunately, your interpretation of facebook's motives require trusting that they'll only do what their PR says they'll do, and not what they're able to do. Or, even if that is their current reasoning, one then has to trust that they won't then take advantage of said ability in the future.

For many of us, facebook's past actions are more than enough to prove that they do not deserve the benefit of the doubt in this case.


In addition, if this is indeed the backstory, then Facebook’s product management team failed miserably by not owning the story and instead deferring to anonymous internet commenters to explain their changes.


Remember when Facebook Security added SMS 2-factor verification and promised to never use the phone number for anything else, but then they were overridden and it was fed into the social graph, leading to their CISO resigning ?


Was there no concern about an attacker being able to -read- the contents, as well?


Not really. It was an internal application, which greatly reduced the risk. The type of information wouldn't be very useful to an attacker. The main problem is that there are developers and business people who also run some SQL and use the system. If they accidentally paste SQL into a search box, it will execute. They could drop tables or anything, even in PRD. If someone were disgruntled or an attacker gained access they could intentionally wipeout the database.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: