-4

Since the login process itself involves an expensive hash, it also makes this part of any app vulnerable to (D)DOS attacks.

Is it a good idea to put the login portion of the app on it's own dedicated servers as one line of defense or are there equivalent and less expensive approaches?

Thanks in advance.

user420667
  • 101
  • 1
  • 1
    Seems like you'd be better off just beefing up the existing server. Plus, implement login attempt rate limits. – ceejayoz Jun 27 '16 at 01:40
  • I'm new to this website can people explain the reasons for downvote? – user420667 Jun 27 '16 at 01:59
  • 1
    Questions that are primarily opinion based, as opposed to seeking solutions to specific problems, are off topic at SF. See [What topics can I ask about here?](http://serverfault.com/help/on-topic) and [What types of questions should I avoid asking](http://serverfault.com/help/dont-ask) for more guidance. – Colt Jun 27 '16 at 02:48

2 Answers2

3

No, it is not a good idea. You can rely on the per-IP and per-username login attempt rate limits which you have already implemented to ameliorate password guessing attacks anyway.

You have implemented login attempt rate limits, haven't you?

womble
  • 95,029
  • 29
  • 173
  • 228
  • Aside from the cost is there another reason this isn't a good idea? My thinking was simply: worst case some people can't login, but people who are already logged in would be unaffected. We could also beef up the various servers as needed. And yes, I plan to use rate limiting logins thank you. – user420667 Jun 27 '16 at 02:07
  • 1
    There's lots of reasons. It's another tier that needs to be managed (monitored, scaled, fixed when it breaks), it adds utterly unnecessary complexity, its existence will confuse anyone with half a clue if they have to work on it, and you'll probably end up creating a security hole in the authentication handoff between the login server and the rest of the app. That seems like a decent list to be starting with. – womble Jun 27 '16 at 02:25
1

As always, it depends.

In theory the log on process is a one-time event and once an active session has been established the actual usage patterns of authenticated users are what really determines the load on a server. In that regard even the computational cost of calculating a hash that was deliberately selected for being slow and expensive such as PBKDF2 is minimal.

As an attack point, you can and should implement measures against brute force attacks such as the ones Womble mentions.

Seperating the login process from your application is a valid software design choice, but not for the reasons you mention. That is typically done to create Single Sign On for a (large) number of different applications, where the authentication logic for each individual app can be reduced to confirming a valid session and you don't need to duplicate login policies, dual factor auth etc. for each individual app.

Community
  • 1
HBruijn
  • 72,524
  • 21
  • 127
  • 192