maxymajzr's comments

I see an interesting library, risk quantification (relates to what I work with).

I click the link.

Sniff/Accountwall stops me. I hit ctrl+w before I even thought of doing it (yes for muscle memory!)

For people who went through the trouble to see the content, is the library worth it?

These days, anything behind paywall/sniffwall/must-be-authenticated-to-read-this-wall warrants a ctr + w from me.

Unless I'm reading it wrong, the text says "Please implement TLS". Not everything is evil, toxic and in need of your downvote hammer. There's no injustice to be fixed here.

How exciting! I can't wait for next brilliant idea. Maybe... "notify your friends when you're thirsty via click of a button! Subscribe now, only $4.99 a month!"

The author is right. It just sucks to read what's true. He's not entirely right but he's on the right track.

You'll find a lot of tiny companies with dev. blogs where they explain in-depth the scaling strategy of their unknown, sporadically-used product.

Yes, react and vue are a few hundred kb gzipped. But are we seriously going to pretend that projects built with react are in a few hundred kb range? You can't even predict how big a project will be. It's not react's or vue's fault, it's simply how it is - add assets, add css, add additional libraries for <insert reason here> and it's not unrealistic to get 2-3 MB that you need to download.

A lot of people are designing their products to show off to their peers or for google (SEO). Users get left out. And we (users) are starting to feel it. Heed the warning or turn the blind eye.

When I used "they have no right" - what I meant was this: they haven't experienced anything fundamentally different 10 years ago, therefore they can't be writing about something that "died" simply due to the fact there was nothing different to experience back then that doesn't exist today. The article seems forced, as any article from fake-factory would be. I'm always skeptical towards such content, that attributes to my negativity when typing all this. I merely find it ironic that someone who has no clue about the matter is writing about it :)

I remember the sound my 28800 modem made before connecting.

I knew I have exactly 1 second below 60 minutes to be online before I get disconnected from my student dial-up.

I had ICQ. We used Altavista (and Astalavista to crack the software we illegally got). Relevant information and socializing was done via newsgroups, as well as content-sharing. Many don't know why winzip/winrar has the option to split an archive into multiple files (so they can fit 1.44" floppy disk and avoid upload limits). Later on I used Miranda so I can use ICQ/IRC/AIM/MSN from the same client. Browser wars were nonexistent. First "awesome" browser shell I used was Maxthon and content was shared on lan parties or you used obscure xdcc search engines to leech off of IRC. FPS games that I played (quake 1, 2 and 3) lagged, I had 200 ping - which is how I learned about the importance of latency and what it is. It dropped to 50 once I got ISDN.

Now, why did I type this? Not to present myself as "the old internet user". I don't consider myself a user of internet from "before", I'm well aware of even older generation whose internet looked even different. I'm just saddened by the fact that buzzfeed, one of the worst ad-ridden sites that exists, is making this kind of an article, spreading false knowledge (which is what it does anyway). It's not even an article. It's made by someone who used Facebook when it looked slightly shittier than it does now.

That's not "old" internet. The consumer-generation that's lifeblood of leeches such as buzzfeed/youtube has no experience nor right to write about "old" internet. They simply haven't experienced how internet used to be when total population online was well below 50 million people and when broadband was a luxury.

But it's not educating anyone. A handful of people who deal with this particular area on daily basis are capable of understanding what the blog post is about.

Gist of the post is that if you have all the info needed to construct the secret used to extract 6 numbers - you can copy it around and have copies of the device that produces one time passwords.

Obtaining the shared secret and knowing the user's credentials is difficult to achieve (obtaining both). Even if it were to happen, you, as a service provider, have undeniable evidence that the user was negligent because leaking out the secret for MFA isn't exactly easy to do.

Data leaks due to malicious employees is often the attack vector in these cases. I'd argue that safe-keeping the data in a way that employees can't access it easily is what's actually a big deal in data breaches, not the actual mechanisms (RFC4226 and RFC6238 algorithms and their derivatives) that rely on keeping data safe.

Attacking a service that's been breached by leaking shared secrets is still extremely hard - you have to know the credentials and corresponding shared secret out of hundreds of thousands of leaked ones. Only way to attack the service is brute-forcing it. That doesn't go unnoticed.

Plausible attacks are extremely rare and difficult to achieve and edge cases that are possible only when extremely sensitive data is leaked aren't an argument against MFA.

The post we're commenting on mentions U2F - that particular approach completely obviates all the problems mentioned in this blog post, on top of being vastly easier to use to the end user (stick the token in the usb port, press the flashing button, job done).

> Mod_php was always faster at executing scripts

I've never, ever witnessed that mod_php came close to be fast, let alone faster than PHP-FPM. There's more work to be done in order to prepare everything needed for Apache to pass the data to PHP executable once it embeds it within its own process. Once opcache is up and running, PHP-FPM blows mod_php away (and there are tools to warm up the cache prior to letting the php-fpm node go live).

> This is was also the reason for the fpm hype a long time ago: don't waste memory on php when php isn't needed

I've been present when the "hype" as you called it hit. It had nothing to do with memory as much as it did with scaling. Added benefit was the ability to have PHP-FPM act as a multiplexer towards certain services (database to name one).

Today, there's no reason to use Apache and mod_php. It's slower and worse by definition. It can't be faster. If you receive results that show it is faster, you're either testing it wrong or your PHP-FPM runs on a raspberry pi.

Can you elaborate? I've yet to see Apache + mod_php to be capable of coming even close to <anything> + PHP-FPM so I'm really interested in what you guys are doing.

You're reading the entire spec, but the flow is what's trivial. 2 systems are exchanging info, they use cryptograhpy to assert that message is coming from a valid, registered resource and the message carrier format is XML. You ask for info, you get XML back, verify the sender and if correct trust the info is valid. That's the gist of the protocol and the tedious part is parsing the XML you receive.

In most cases, SP doesn't know user is removed from IdP. If there's a need for such feature, you resort to shared sessions - IdP has control of storage service where SP's save sessions (say, Redis). Once user is removed from IdP, IdP deletes the session record in Redis and SP loses all user info.

This implementation happens rarely.

The single logout process is often flawed since it depends on SP's accurately processing the request and returning the user back to IdP if a session has been successfully destroyed. This often fails due to network connectivity, problems with session destroying at the SP, SP's not implementing the SingleLogout properly etc. What I've experienced and seen in many cases is that IdP simply kills the session it has on the user and stops right there, then the rest of the SP's handle it through back-channel.

I work in this area so I'm relaying my experience through past 10 years of implementing SSO for various enterprises.

In reality, the SAML protocol is quite straight-forward but something odd happens when people hear the term SSO. It's not magic, it's quite trivial but takes a bit of discipline to grasp it fully and implement properly.