電話番号をデータベースに追加するときのハッシュ化のアルゴリズムの選択

セキュリティについて素人の私が良い悪いを言うのは良くないと思いますが。

password_hash() （bcryptなど）の場合には、公開ソルト＋遅いハッシュでガードする、という意味だと思います。

一方、hash_hmac() の場合には、非公開鍵（≒非公開ソルト）でガードすることになると思います。

情報漏洩の場合に、非公開鍵が一緒に漏洩しないとは言えないため、根本的な対策にはならないと思います。

Qiita の記事で以下のようなものがあります。

この記事のコメントで徳丸さん @ockeghem （セキュリティ関係の本も書かれている、セキュリティに詳しい方です）が以下のようにおっしゃっています。

加えて、秘密のソルトを用いたとしても、その秘密が隠せるとは限らないという事情があります。
なぜなら、パスワード情報が漏えいした局面で、ソルトは隠しおおせるとは限らないからです。ウェブサイト等がOSコマンドインジェクションなどで任意プログラム実行可能な攻撃ができたばあい、攻撃コードはウェブアプリケーションと同じ権限で動作します。なので、ウェブアプリケーションからは秘密ソルトを読み取れるが、攻撃コードからは読み取れないという仕掛けを作ることは困難です。
なので、ソルトを隠すことは、さっぱりとあきらめるという実装が多く用いられています。

一般的なセキュリティの話としては、hmacなどのメッセージ改ざん防止のハッシュ機構を使ってパスワードのハッシュを作るのは良くない、bcrypt などを使うのがベストプラクティス、だと思います。

そもそもの話として、電話番号をパスワード代わりに使用する、という意味なのでしょうか？
そうだとしたら、11桁（固定電話なら10桁）の数値のみという項目をパスワードにすることそのものが問題なのだと思います。
（現在のパスワードのベストプラクティスは、とにかく長めのパスワードを使う、だと思います）

パスワード＋電話番号で認証しようとして、電話番号もそのまま持たないでハッシュする、という意味ならまだわかりますが（その場合には、素人考えではパスワードと電話番号を合わせてbcryptなどでハッシュすればよいのではないか、と思います）

@yoshi389111さんの意見に全面的に賛同しますが、追加で。
DB流出からの電話番号割れを危惧されてるみたいですが、それより先に「組み合わせ総数が少なすぎてブルートフォース（総当たり攻撃）で速攻で破られる」問題が来ると思います。
上司や顧客がやれと言い張ってる場合、上で翻意するように説得して、どうにもならないようであれば接続制限めっちゃ厳しくする（1時間あたり5回までとか）とかですかね……。

@yoshi389111 @u83unlimited
お二人とも、とても分かりやすい説明ありがとうございます。

HMACが万能のように考えていましたが、ご指摘の通り、データベースの内容が漏洩するような状況下で、秘密鍵が漏洩しないとは言えませんよね。

電話番号はSMS認証で使用しようと思っていました。
SMS認証を行なった上で、電話番号のハッシュを保存し、新たにSMS認証をしようとした場合に、すでにSMS認証をしたことがある電話番号の場合は、認証できないようにするようなものです。
が、そもそも電話番号自体を保持するという考えが間違っていたようです。

もしSMS認証するなら、is_phone_number_authenticatedのようなカラムを設けるに留めたいと思います。
その場合、複数アカウントで同一の電話番号を認証されることは防げない、ということになると思いますが、仕方ないですよね。

それでも重要性としては、一つの電話番号で複数アカウントを承認されてしまうことより、ユーザの情報を守ることの方が重要なので、前者は諦めようと思います。