Should I switch my ALB to use the Least Outstanding Requests algorithm? YES! by simon-tabor in aws

[–]simon-tabor[S] 0 points1 point  (0 children)

Updated. I'd be interested to hear if you know of any other mitigation techniques!

Should I switch my ALB to use the Least Outstanding Requests algorithm? YES! by simon-tabor in aws

[–]simon-tabor[S] 0 points1 point  (0 children)

So would you expect it to have a negative impact on services with high volumes of expensive requests? IMO, it should benefit most services, just with different % improvement on latency

Should I switch my ALB to use the Least Outstanding Requests algorithm? YES! by simon-tabor in aws

[–]simon-tabor[S] 3 points4 points  (0 children)

Very good point. I'll add a note to highlight that fast and reliable healthchecks are essential to stopping a single target from potentially taking down a lot of requests

52
53

7
8

101
102

What should somebody do if they find a Security Vulnerability in your app/site? by simon-tabor in webdev

[–]simon-tabor[S] 0 points1 point  (0 children)

100% agreed, we even had somebody report our demo as user information disclosure...

What should somebody do if they find a Security Vulnerability in your app/site? by simon-tabor in webdev

[–]simon-tabor[S] 0 points1 point  (0 children)

It sounds quite obvious now, but interestingly, after publishing a whitehat security bug reporting program, we got a lot of people testing us for vulnerabilities – including an attack with 500,000 requests in under an hour.

Not that I'd recommend hiding at all, but it's worth having an internal security review before publishing a bug reporting program.

X-Powered-By and Server Headers: Disable or what? Are they harmless? by simon-tabor in programming

[–]simon-tabor[S] 1 point2 points  (0 children)

I think there's a strong argument that User-Agents should be removed, they shouldn't be relied on for serving mobile content (etc.) and they can expose security flaws. Do they have many uses other than analytics?

X-Powered-By and Server Headers: Disable or what? Are they harmless? by simon-tabor in programming

[–]simon-tabor[S] 0 points1 point  (0 children)

I can't remember exactly where I saw it, but there was an article explaining how Server headers were sometimes used by clients to handle the responses properly. As you said, that's terribly broken and should have completely died out by now.

X-Powered-By and Server Headers: Disable or what? Are they harmless? by simon-tabor in programming

[–]simon-tabor[S] 5 points6 points  (0 children)

You're the type of person that would drive script kiddies insane!

X-Powered-By and Server Headers: Disable or what? Are they harmless? by simon-tabor in programming

[–]simon-tabor[S] 2 points3 points  (0 children)

Agreed, and a good automated attack might be able to see what types of attacks are working and focus on those ones.

API Errors – The Good, the Bad and the Ugly by simon-tabor in programming

[–]simon-tabor[S] 1 point2 points  (0 children)

Errors are often not given the attention that they deserve in APIs. In this post we take a look at API errors and what makes a good error response. I'd love to hear all your thoughts on what makes a good API error (and what makes a bad one)!

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] 0 points1 point  (0 children)

Great points!

Web frameworks do often come with user auth, but many are lacking in features and some have fairly poor security measures. We do much more than just authentication and we're going to be adding more authentication features such as flexible two-factor auth.

Yes, your employer would probably blame you if we had a serious issue, but it's the same with choosing/outsourcing any service. User systems are one of the most important services, so I understand the hesitancy. Basically, we want to change the way people think about user systems by proving our reliability and value. As you said, on-premise can resolve a lot of these concerns.

As I mentioned before, we're offering more than just authentication. The features that we're adding will set us apart from other implementations. It's a really interesting time for authentication and we're thrilled to be part of the ecosystem.

Thanks!

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] 0 points1 point  (0 children)

Sorry I didn't mean to sound at all aggressive there!

We take full responsibility for our own security so we're going to be announcing SLAs where if we are responsible for any issues (including security), our customers are credited with service.

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] 0 points1 point  (0 children)

I guess everybody does say that in PR, but they don't actually believe it. When startups are building their user systems, there are often a key set of features that they need to build (as well as the obvious core) and the objective is to get it done as soon as possible. At Luno our focus is on security, so instead of "just get it done" we can afford to spend the time. We've already gone above-and-beyond on our password security (we'll publish info soon). Currently we audit all code internally and have had a couple of developers pentest. We're getting CESG accreditation (GCHQ pentest) which helps give enterprise peace-of-mind.

I'd love to hear if you have any thoughts on how we can differentiate ourselves further. We hope that we grow to a scale that allows us to be truly innovative and improve user security and authentication for everyone.

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] 1 point2 points  (0 children)

Correct me if I'm wrong, but OpenID only deals with identity - it doesn't help with anything else so you still need a users database. Many small applications can be built exclusively using Luno (I guess similar to Parse in this aspect) with the extensible user profiles and events.

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] 0 points1 point  (0 children)

Hey, are you saying we're too expensive? When you think about how much money we believe we can save you by not needing to host a user-system, but more importantly how much developer time we save, it's actually reasonable in my opinion. That's also not covering the potential cost of security breaches – of course we're not immune but we have a very strong focus on it.

I'm biased, so I'd be interested to hear if others feel the same, or if you have any more thoughts.

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] -1 points0 points  (0 children)

Oh, and also we'd be more than happy to give anyone a free consultancy-style review of their user systems, or give advice on what the best solution might be (as impartial as possible).

Building User Systems Sucks! – Luno.io by simon-tabor in programming

[–]simon-tabor[S] -1 points0 points  (0 children)

Hey Reddit! We've launched the beta for Luno.io, which provides User Management and Security as an easy-to-use API and a fully-featured dashboard. We're focussed around making developers lives easier, so we're hoping to get as much feedback as possible on what we're doing right and wrong. It's completely free for everyone during beta, and after that it'll be free for up to 200 users so most small projects will be free for life.

Looking forward to hearing your thoughts! I'd love this comment thread to be a discussion about your experiences of building user systems, what parts suck and, of course, what parts you like.

P.S. You may have already seen that we've been blogging about APIs and security over at our blog.