400ms for pwd_context.verify ? Won't this block the main thread for 400ms if called in async func ?

[plsholdmybeer]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

def x():
    a=time.time()
    pwd_context.verify("123",pwd_context.hash("123"))
    print(time.time()-a)
x() # 0.3718242645263672

**400ms**

Description

This is used everywhere in examples, but won't this block main thread for 400ms for all async endpoints?? With a guessed username an attacker could block all async endpoints with a single request every 400ms. Am I missing something?

If that's the case, easy fix should be always using synchronous functions (def) instead of async def for endpoints that use pwd_context.verify, so that handling is done in the background thread pool.

I feel like this should be documented, or I might just be thinking wrong.

Operating System

Windows

Operating System Details

No response

FastAPI Version

0.95.0

Python Version

Python 3.10.10

Additional Context

No response

[8thgencore]

If an async endpoint calls this function, it will indeed block the main thread for around 400ms, which could cause performance issues if many requests are being made simultaneously. To avoid this, you could use a synchronous function instead of an async function, as you suggested.

It's worth noting that the pwd_context library is designed to be computationally expensive, in order to make it more difficult for attackers to brute-force passwords. However, if you are concerned about the performance impact of password verification on your application, you could consider using a different password hashing library with lower computational requirements.

[n8sty]

You can also run your webserver eg: gunicorn with multiple workers with the idea that one of the other workers may not be busy computing these blocking calls.

[plsholdmybeer]

I thought for some reason there could be only 1 async worker when reading your response. I thought of workers as threads, in threads there can be only 1 async thread, but with workers, there can be N uvicorn workers, they will be separate processes through, so no memory sharing. Please correct me if I'm wrong.

[plsholdmybeer]

Thanks guys for the answers, I'll look into adding a warning to docs. Most people will deploy the most commonly used method to prod. This is really susceptible to both timing and bruteforce attacks to find valid usernames as well, once attacker finds a valid username, he can just keep spamming it (that would be the slowest yet the most efficient DOS attack ever, doable from a toaster with a dialup connection) and block the whole API that was supposed to be lightning fast because it's fully async. Thinking of fully async approach both excites me and scares me so much because of things like this.

[yinziyan1206]

I use @functools.lru_cache and threadpool. It is nogil using hashing library in python

[plsholdmybeer]

I'm not touching that nogil thing for what I'm doing but it's pretty awesome (and terrifying).
I wanted to add that my comments and the whole issue doesn't take in consideration best deployment strategies for this kind of app. If I used gunicorn + uvicorn workers I would've shrugged off the issue in the first place