larssorenson

Your concerns aren't unfounded, but they're a bit misplaced. Password managers aren't intended to protect you from a local attacker, on your machine, like the malware you described. It is trivial to capture clipboard contents, as you say, but it's also similarly easy to keylog so your passwords would be exposed either way. If you consider your computer compromised or antagonistic like this, don't use it for anything sensitive.

Password managers are mostly intended to help facilitate unique passwords per account, to avoid password re-use which prevents credential stuffing. That is, if an attacker gets a hold of your password from one website they can't use it to log in everywhere.

Back to your concern, there isn't a solution for Windows in this space at the moment. Malware that's alive in your user context (or Satya forbid, SYSTEM) can do quite a bit thanks to Win32 APIs.

You're right, it is done. I worded my comment carefully to leave room for this because it's hard to prove a negative, but I stand by my statement, specificay in refuting the implication from the original comment: we aren't haphazardly blasting plant genome with radiation, at scalr, and guessing it's safe enough to feed to the world. I don't have numbers but GMO crops today are by and large the result of non-radiation genetic engineering.

GMO's are not produced by targeted radiation in the way you have described, at least not as common practice (i.e. the GMO food you buy isn't created this way). GMO crops are generated in two ways: targeted gene modification (with deliberate modifications being made in contrast to the randomness of the radiation method you described) and crossbreeding (which has a more randomized effect but does not involve radiation).

If you look at the [Wikipedia article on genetic engineering techniques](https://en.m.wikipedia.org/wiki/Genetic_engineering_techniqu...) radiation doesn't appear once.

It's worth drawing the distinction that Steam, as opposed to Apple and their app store, does not hold an exclusive monopoly and cannot dictate where users can install software from. If a Dev doesn't like Steam, there are other publishers and store fronts that they can peddle their wares through. Similarly users can go elsewhere to buy and install, even direct from the manufacturer.

Steam being the de facto choice is another issue entirely, and yet another discussion for their fee structure.

I had this happen recently with a finance website! Although technically the reverse, it silently stopped logging me in because the password field was changed to use HTML validation to enforce a max length of N, but they had previously accepted my password that was length N+1. Maddening.

Interesting, I haven't worked with rainbow tables very much since by the time I got into the world of hash cracking it had either been deprecated by salting or wasn't relevant (i.e. NTLM). That is a clever trick of trading back some of the space for extra time; I remember some of the rainbow table file sizes being ridiculous to the point of almost unusable haha.

edit: spelling

Unfortunately short of forcing everyone to use an ORM I don't see how we can block the unsafe API, which I'm assuming to be the string-based query interface e.g. `conn.query("SELECT * FROM users")` since any interface that accepts a string will allow a dynamically constructed string which lets developers open themselves to injection attacks. Only ORMs AFAIK can prevent this, e.g. db().users.all() or db().users.select(name="bob").

Maybe there's a clever trick I'm missing here.

Compromising the hash and salt, since they must be stored close together, makes it possible to identify if the salted hash is a password in a corpus of previously compromised passwords. An attacker can do Hash(PW, Salt) for all PW in a list of leaked/cracked plaintext passwords. If they've guessed your password and it's shared across multiple services, lateral compromise. Salting only prevents the rainbow table attacks, where an attacker precomputes all possible hash values for a known keyspace (like, say, 8 alphanumeric length passwords) and just look up for a match. Encryption is concerning because it necessitates the ability to decrypt since they're often inverse operations of each other, and presumably there's a shared key stored somewhere to do the comparison, which means it's likely trivial to recover the password compared to hash cracking and undermines any strength or complexity benefits. This also likely points to other bad behaviors utilizing this "feature", such as helpfully emailing you your plaintext password when you forget it.

You're probably thinking of the twitter account @justsaysinmice, https://twitter.com/justsaysinmice.

For the uninitiated and otherwise unaware, many studies regarding illnesses, disease, nutrition, exercise, medicine, etc. perform clinical trials with mice. Resultant publications are picked up by news outlets who headline the results, without the caveat that the results were only found in mice. Mice are, notably, not humans and the results don't (in fact, rarely ever) carry over 1:1.

It is worth noting that there exists legitimate RATs that offer the bullet point features you've highlighted. The marketing issue is another problem entirely; these legitimate projects are usually open source on GitHub or posted on public blogs.

I think a lot of vegans drink soy and pea protein powders to get enough protein in their diet.

Actually a common misconception, most vegans get more than enough protein in their diet eating a relatively healthy/varietal diet. The exceptions would be people particularly concerned with their protein intake, namely athletes, bodybuilders/weight lifters specifically.

The previous discussion on HN highlighted Mens rea with regards to establishing intent, i.e. they didn't have criminal intent (they went in with the understanding that they had full rights and privileges to be there) and would probably (hopefully) be vindicated in a court of law. There is still a matter of CoalFire vs State / Local govt, where CoalFire might be liable for not confirming that they had the proper authorization to dispatch their testers (which is part of the state vs local issue that's ongoing).

IANAL but I've been tracking this pretty closely since I'm also a pentester; everything seems to reasonably indicate that the two guys should be released, but someone else is likely ending up in a court over this.

As a vegan who tracks their nutrients and vitamins pretty closely, I do not have trouble getting enough choline. The big hits in the vegetable world are: soybeans, cauliflower, potatoes, peanuts, kidney beans, quinoa.... and on and on. There's really no difficulty if you eat a sufficiently diverse diet.

Sweeteners are addictive, leads to more sales.

Re: stores that promote home cooking, their prices make them largely inaccessible to the broader market (and those who make less) since they tend to be branded "health food stores" and the markup is 50% or more.

Heck, even the difference between two (differently named) grocery stores in my area, owned by the same larger company, can be that bad and neither is touted as a health food store.

I would posit that even mass manufactured is slightly off point. For instance, if you can produce bread dough of the same consistency and quality with 4 ingredients (flour, water, salt, yeast) how does scaling it, in a factory or by hand, make it less healthy?

As a note, "sugar" isn't the only added sugar ingredient you'll find in bread, or really any packaged food. For instance, I read through the nutrition guide for Breadsmith's breads and rolls, 28 of their 44 offerings have some form of an added sugar (see: malt syrup, honey, granulated sugar, molasses). I wouldn't qualify that as "most" although it's certainly not slim pickings overall.

The label may not say "sugar" but it can be there in many different ways. See https://www.healthline.com/nutrition/56-different-names-for-..., one of the first results I came across that only lists a fraction of the possibilities.

As someone who works as a "white hat hacker", allow me to shine some light on the industry. There are many branches, distinctly divided into two categories: Red team/Attackers and Blue team/Defenders. Within the attacking side is what most people think of when they hear "hacker", key among them is penetration testing (pentesting). Pentesting breaks down into distinct categories that target different scopes: internal/external network, web application, mobile app, thick client, IoT, SCADA, Social Engineering, and physical. The list shifts over time, but that's the gist of it. Those that interact with software/hardware rarely have the benefit of white box testing, which includes having the source available, nor do the tests often go deep enough to require subtle CPU behavior or assembly-level reverse engineering. All of these pentests are dynamic, where as what you've described falls under the static analysis camp which involves a different set of skills and tools.

There are some who work in reverse engineering, CPU interactions or static analysis but those are often more senior positions within a company, are more research focused or specifically marketed as such; my role as a pentester is focused on dynamic testing from a blackbox perspective. Sometimes we are lucky to have architecture diagrams, API docs, or source code but they only serve to benefit the test from an external perspective. I don't analyze the code and report vulnerabilities there, I report findings from a perspective of breaking the application in runtime; the code only makes that easier.

Anyone here wishing to break into security to "be a hacker" might find web app pentesting to be the most familiar for developers (it's not far from skills used for UAT, QA and debugging) and provides a pathway down the OSI model. There are companies that will take strongly motivated and technical people to train into pentesters, as the field is vastly understaffed and it's easier to train someone on your methodology from day 1. However, this normally starts as Web App (it's where the money and clients are) and one can move into other areas over time.

I'm more than happy to provide more details or resources to those interested. My knowledge is more in the attacker area, but its possible to start in either side and pivot into the other. Time, patience, and a willingness to learn.

Yes, the author is specifically refering to KVM (https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine) which was merged into the Linux kernel in 2007.

Whereas Docker (https://en.wikipedia.org/wiki/Docker_(software)) was first released in 2013.

I thought the exact same thinng.

I got as far as the Security section before I had to comment. They claim they care about data and user security by providing a fingerprint reader, which is known to be a poor method of authentication, as well as integrating with Google 2 Factor Authentication. They also tease about storing your, encrypted of course, on their servers. But what about in transit? What encryption cipher suite is used? How are the keys managed? Can I decrypt my data manually or do I have to use their product? Can I export my keys? Also if I cared about data security and privacy, which I do, the absolute last thing I would do is intentionally place all of my data on third party external servers that I didn't in some way have direct access to, behind a fingerprint reader or Google 2FA. I think for this to be "Next Now" they need to provide more information about something like this, especially since they claim to be concerned about it.

But I feel like it would have been the same if he got to the point he did and recognized that he had access to keychains. Whether or not he actually accessed them,especially since they weren't auditing (from what I understand), is sort of irrelevant at that point, they would have to be cycled either way.

I understand that they're top secret, but that sort of proves the extent of the vulnerability.

I see your point but I'm not sure if having passwords like 'changeme' qualifies as being a privacy violation... You should almost expect it to happen at that point.

But I do recognize that cracking passwords goes a step too far.

While I'm on his side, his wording seems to indicate he did download data from SOME of the buckets, just not those specifically containing user sensitive data.

I understand how dumping SENSITIVE data can make you a flight risk, but he specifically outlined that he avoided dumping anything sensitive (that is anything directly related to Users and their data). He did dump S3 buckets that had a treasure trove of other files (such as the API keys for the other services and static content), so I guess my question here is at what point does dumping of any kind become bad?

It is worth pointing out that Wesley specifically avoiding dumping data from the S3 buckets which were directly related to User Data / Information. "There were quite a few S3 buckets dedicated to storing users' Instagram images, both pre and post processing. Since the Faceboook Whitehat rules state that researchers need to "make a good faith effort to avoid privacy violations", I avoided downloading any content from those buckets" In fact, the only 'sensitive data' he retrieved in regards to user account information were the weak employee logins.

There is also the situation of security to consider. Although browsers have made great strides in improving security, if we start including our payment information directly in the browser it could lead to potentially interesting situations. If a malicious entity escapes the sandbox or some memory reading vulnerability, they could figure out the payment information. Of course there's also XSS and CSRF which could potentially allow a malicious entity to silently authorize payment by the user for their own website, all of which would have to be considered not only by the websites implementing the 402 API but also the browser. Sure we're already working to fix these problems for all other data and account purposes, but if history is any indicator then I don't think we're ready just yet.

I got 'down briefly for scheduled maintenance, please check back in a minute.'

Scheduled? Yeah right.

Every student, teacher, and staff is bringing or already has one of those in the school every day in computers, laptops/macbooks, smartphones, security cameras/alarms, etc.

It seems that this article also somehow missed entirely the potential link between some artificial sweeteners and diabetes[1][2]

[1] http://www.ncbi.nlm.nih.gov/pubmed/26095119 [2] http://www.nature.com/nature/journal/v514/n7521/full/nature1...