3 comments

[ 2.0 ms ] story [ 21.6 ms ] thread
>We are a security company based out of Rochester, NY that plans to deliver a high quality product which provides a way for organizations...

You plan to do it, or are doing it? Do you provide high quality products, or planning too? Your doubt, gives me doubt.

Why no domain email? Using a personal email for contact? Not very professional. Just saying....

> Passwords can be sent to the Blur service from any application or system to be secured before being further processed and stored.

So, Blur will review plain text passwords for multiple applications across the organization,possibly logging it?

1) Why shouldn't I spend money on securing the apps with good password requirements and 2fa,instead of on Blur? It seems,integration work is needed with the app anyways.

2) This might secure the passwords but it also increases my risk. The Blur infrastructure will constitute the most vulnerable segment of my organization. How can I justify such a reduction of security? Is it not better to accept the risk of weak password usage? This feels much like getting a bullet proof vest weighing 200lbs,where it might protect me from bullets but then it also means I can't move,my protection suddenly made me a sitting duck.

3) Let's say my previous questions are without merit. Why shouldn't this be an internal self hosted app? Why an external service? Surely you can charge customers for support and license.

4) This solution becomes less relevant as apps move to SSO or secure their login. I would be concerned about developers and application stakeholders becoming complacent or resistant towards suggestions of improving app login security or they might neglect login security because Blur can fill in that gap.

Overall,my impression is that Blur remediates a specific security issue without considering the impact it will have on the organization's security posture as a whole.

Sorry for being negative,I hope OP can address these concerns as I am sure I won't be the only one to have them.

You aren't being negative, that you very much for the thoughts

1. Good password requirements doesn't mean that your users will use secure passwords. Password123! is not secure. There is nothing wrong with 2 factor authentication. This is not a replacement for that. A lot of users choose not to use 2 factor authentication because they don't want to go through the hassle. So we have a strong password policy and we have 2 factor authentication enabled, yet our user isn't using 2 factor authentication and their password is extremely weak.

2. Yes the Blur infrastructure adds an extra component to your application to it and if something were to happen to it, availability would be in jeopardy. Resources would need to be put in place to reduce that risk, just like a database.

3. This can be a self hosted internal application. Its does not have to be an external service. What i have on my website is a demo. How an organization chooses to deploy it is up to them and i agree it makes the most sense to deploy it internally.

4. I don't understand how a SSO would make this solution less relevant. If anything I would think it would make it more relevant. To have a host of applications use one entry point for authentication, its more important for you users to use secure passwords. If the SSO account was compromised, all apps using that SSO is now at risk. SSO in my opinion isn't a security solution, its an integration solution. I don't see how Blur would cause stakeholders and developers to become less complacent regarding security. I'm sorry but that doesn't make sense to me.

Blur does not log any of the passwords it secures. No information regarding the original password and the secured password are logged or stored in any database.

Again thank you very much for the concerns.