Ghedipunk

Use slime mold. discovermagazine.com/planet-earth/…

Rather than a per-IP limit, you could require that they create accounts, and rate limit based on that. Be honest that, due to bots bypassing your Captchas, you need a valid email address, and that you're blocking registration from the email providers that you see the most spam from, such as mail.ru. (Similarly, if I were in Russia, with an ad-supported lookup site for Russian telephone numbers, I'd block gmail.com rather than mail.ru.)

Added bonus: You can have an ad-free option for accounts that pay a monthly fee, and tiers for easing the rate limits.

1: No. 2: Security also depends on usability. If people won't use a security feature, then it's not actually a security feature.

@uhoh, with that narrow interpretation of the question, the technically correct answer would be "The Shuttle Orbiter Discovery's frame, and every piece of hardware mounted to it which hasn't been replaced during the orbiter's lifetime." I think this answer gets that point across well enough, as well as provides supplemental information for anyone with similar questions.

Nevermind, they're not making multiple accounts; they're unregistered users.

Are there any policies for people who make accounts to ask just one question? (and who have made at least two such accounts?)

Even if the articles are never adopted by The PHP Group, it'll still be good to have a collaborative effort to document PHP in a sane way, where people can be pointed to first.

I suppose the first step to updating PHP.net's documentation would be to subscribe to the developer mailing lists, then lurk for a while to figure out how to get changes in place. In the meantime, start a wiki or git repo to write articles.

I look forward to it.

I'm about 4 hours past when I should be unconscious... Honestly, realizing that it isn't the random ad-laden blogs teaching obvious security vulnerabilities are the symptoms of the problem, rather than the root, is a revelation that in my sleep deprived state, I feel I need to address, but know I'm not capable of doing right now.

(Not to mention, any comment that is critical of PHP's documentation style on the docs pages gets downvoted out of existence.)

That is both true and very disheartening.

Good point. I've been railing against those random blogs that use mysql_* and "INSERT INTO $_POST['foo']"... but if php.net actually taught the language AND web development... well...

Personally terrifies me... but honestly, it makes me glad that python has never reached the level of usage for networked applications that PHP has, since python has had FFI for several years...

@MechMK1 Yeah... red teams are going to have a lot more fun for a few years; that's for sure.

I know my peers who write PHP code haven't been known for being security conscious... I'm honestly hoping that FFI will prove to be so newbie unfriendly that it never really catches on.

PHP 7.4 is nearing release... a few weeks to (at most) a couple of months... New feature is Foreign Function Interface, which gives PHP direct access to .so (.dll) files... I foresee a lot of segfault questions on SO... but I also see the potential for exploiting buffer overflows and underruns in PHP code; something that hasn't been much of an issue yet.

@MechMK1 Yes, I have never set my own avatar on StackExchange.

My experience with most certs are, unless they are extremely prestigious (CCIE), their worth is in getting you past any HR filtering process there might be. They're a way for entry level candidates to get their foot in the door in saturated markets and, in industries that are heavily regulated (finance, etc.), can help with passing audits, since you'll know the checklist-side of the industry.

* Or even if you just implicitly trust your own people.

Yeah, I've just learned to distrust people. Some of them may be working for governments. The vast majority are wonderful people. A few are outright monsters. There's no easy way to sort them before they can do harm, if you implicitly trust everyone.

And no, I didn't participate. Didn't even have indirect access to the TS side of things during Operation Iraqi Freedom; I was helping to train the then-brand-new Stryker Brigade.

Just as people in the US distrust Russian and former USSR citizens due the KGB operations.

I'm not talking about people getting US citizenships, I'm only talking about classes of people having cause to distrust private US citizens due to the risk that they may be acting on behalf on the US government for nefarious purposes.

Saudi Arabia, 1968. Iran, 1972. Iraq, 1984. I say CIA in this context as shorthand for meddling in the internal affairs of democratically elected nations, which seems to end up in the nations no longer being ran democratically... And I was an Army intelligence soldier from 1999 through 2004; including dismantling our CIA-installed government in Iraq and destabilizing Afghanistan.

Yeah, and I don't expect it to die down in my lifetime... Just as I wouldn't expect anyone to trust me as a private US citizen, due to things the CIA has done.

It does seem like some pretty clever social engineering, though. A refinement on the quizes from a few years ago. People love to talk about themselves.

The Air Force and the Democratic National Convention released statements telling airmen and political candidates not to install it and, if they did, to uninstall it immediately.

My prediction for tomorrow's SE too broad questions: FaceApp.

On the topic of nation-state intrusions... As an MI soldier in 2000, one valid disposal method of TS-SCI safe contents was (and probably still is) high explosives. From 3 miles away, you still feel it in your chest.

There are zero-knowledge proofs, where you can demonstrate that you know the password without the server ever getting that password or reverse engineer it without brute forcing it... The question, though, simply takes the domain name, identity, and secret, and turns that aggregate into a new secret that the server knows. The hash becomes the secret, and if stored improperly (which developers will, since it's a "secure" password protocol), they might as well store the password in plaintext.

(And, of course, stop thinking about hashes when thinking about authentication systems; think about key stretching algorithms like PBKDF2, bcrypt, scrypt, and Argon2.)

The identity should also not be case sensitive. Using it as part of a hash to verify the secret will make it case sensitive.

@VipulNair hash(domain+identity+secret) is significantly less secure than hash(secret+salt), because the domain name and identity are very low entropy values. Adding in a salt means that the server needs to broadcast the salt to anyone who might want to authenticate, which while the salt isn't a secret per-se, it's still best to treat it as sensitive... (and asking for a salt can be used in an enumeration attack).

@jdgregson [facepalm.png] Right, because ransomware is totally going to respect boundaries that exist purely in the vendor's imaginations...

And honestly, because it's someone else's computer, even if I have root access through SSH, I still treat it as belonging to the hosting service, distrusting it as much as I distrust my own users.

Not really. "The Cloud" is just someone else's computer.

Just... be careful. We care for you as a person. There are too many developers who have good intentions who get caught between a lawsuit and a hard place. Dot your Ts and cross your Is... and read the NIST authentication standards very thoroughly. You never want to know any passwords, and you want to make it as hard as possible for you to ever learn a user's password.

A recurring theme on workplace.SE is that your company's legal and HR departments don't represent you; they represent the company. If your manager is doing things that can get your company into a tough legal situation, then legal and HR are your best friends... If not... well...

And... I wonder if the lawyer has fully contemplated the implications of plausible deniability... That is, a user's actions on the platform can be positively applied to that person as a legal entity. If an admin can log in as that user, then the person's responsibility can be summed up as "I didn't do that; must've been MJHd logging in as me, since they had my password, too." (Are YOU prepared to take that responsibility? If a malicious user blamed you for their actions, could you be jailed?)

I mean, any every reasonable system, the password is truly unique to both the account and to the platform, so this should never be an issue... but the reality of security is that there are few truly reasonable authentication systems...

"The user doesn't own their password." I'm honestly curious about the precedence in court cases that lead to this conclusion. I'm not challenging your lawyer; merely ignorant of the precedent, and have seen precedents leading to contradictory legal opinions, namely in law enforcement (failing in) obtaining warrants to compel users and platform owners (Apple Inc) of phones to reveal their codes to unlock devices.

@SChand, knowing the company does indeed help. Your steps are now clear: Go to telit.com/contact-us, and complain loudly, profanely, and constantly until they fix it.

sudo kill -9 11025 -- This will stop that process. It might have side effects that nobody here can foresee. It will only stop it until it restarts, which is likely the next time the computer is rebooted, and the next time it restarts, it will have a different process ID, so you'll need to use a different number. It could auto-restart. It might crash your OS (very unlikely, though). Treat this command as a gun that might be pointing at your foot. A better option would be to get a professional to look at it in person.

@SChand, it's in the dwcore application installed on your RPi. So far, nobody knows what that is beyond its name. Maybe someone will come by with a better idea, but right now, you're the one with the most access to information on it, since you're the one with that application. If you want to stop that vulnerability, your options are to investigate further (we're unlikely to be able to help you with that), or remove that program and see what happens. (Be aware that bad things might happen if you remove that program. Until someone learns what dwcore is, we can't give you good advice.)

@SChand, if that's the case, then it's definitely not in your PHP code.

A laser can also be tuned for the armor, by detecting the light that is reflected back. A laser weapon is also a spectroscope, able to break down materials and make their specific elements glow at specific energies, revealing what the compound is made of. You can change your duty cycle accordingly; short, rapid bursts to make narrow, deep holes in the armor, then long slow bursts when you've hit a soft target and want to start doing damage. (Measured in milliseconds, not in timespans that humans experience.)

Lasers can also be used to keep troops from poking holes through the hulls of spaceships. Combine with a mapping system, the laser also knows the distance to its target, where it's pointed, and where the outer hull is. If it detects that it's hit the hull, it'll warn the operator.

Another way to beat this race condition without row locking or other explicit atomic operations is: Rather than just track whether it's been scanned or not, insert a transaction ID for when it's scanned, and do a second read after your insert to ensure that yours txid is still in there. If they arrive within 100ms of each other, the second person will get in, but on human timescales, it's synchronous... In all other cases, the first person gets in. This has the added benefit of logging which gate a person went through, if you use a scanner's MAC address as part of the txid.