ご覧のとおり、デフォルトの User モデルは、使用されているハッシュ関数をカスタマイズする方法を提供していません。それをサブクラス化し、問題のあるメソッドを再定義してハッシュ パラメーターを取得するか、webapp2 プロジェクトで機能リクエストを提出することができます。
ただし、Webapp2 のパスワード ハッシュには、パスワード ストレッチングが行われないため、はるかに大きな問題があります。必要に応じて (!) ハッシュをソルトしますが、反復処理は行わないため、ブルート フォース攻撃が攻撃者にとって必要以上に実用的になります。PBKDF2、SCrypt、または BCrypt などの適切なパスワード プリミティブを実装する必要があります。
ハッシュ関数の相対的な強さについてのあなたの質問に答えるために、SHA1 はいくらかの弱さを示していますが、プリイメージはおろか、衝突をうまく生成した人はいません。さらに、HMAC の構築により、ハッシュ関数が衝突攻撃に弱い場合でも、安全な HMAC を実現できます。おそらく、MD5 でさえここで機能します。
もちろん、攻撃は改善されるだけで悪化することはないため、将来に備えておくことをお勧めします。ただし、セキュリティを懸念している場合は、ハッシュ関数の選択よりもストレッチングの欠如について懸念する必要があります。また、セキュリティが本当に心配な場合は、自分で認証を行うべきではありません。Users API または OAuth を使用する必要があります。そうすれば、他の誰かがパスワードを安全に保管できるようになります。