Misskey: Insecure clear text password must not be sent when authenticating users

Created on 24 Jul 2020  ·  32Comments  ·  Source: syuilo/misskey

This is not the software should be built. We should only store a hash sum of users password and every operation that requires authentication should be permitted with hash sum. Cleat text password should not be used on any internet connection and never leave the computer.

I suggest put this issue in todo as it will bring changes to the database and fundamental software behave. But it should be kept in mind, clear text password is easy to steal and may bring damage to thousand of Misskey instance. MitM attack is now everywhere.

截屏2020-07-24 下午3 09 23

🔒Security

Most helpful comment

将来的には実装するかもしれないが優先度は低めという温度感にします
皆様ありがとうございます🙏🙏🙏

All 32 comments

@有識者
TLS使っててもパスワードを平文でサーバーに送信するのってダメなの?

仮に平文やめてハッシュみたいなのをサーバーに送信するようにしても、このIssueによればTLS使ってたとしても通信を傍受される恐れがあるため、結局はそのハッシュを第三者に知られることになり、パスワード自体の流出は防げるにしても不正ログイン自体は防げないということになる

@Co2333 Thank you for your suggestion.
But what about TLS? Communication with the server is encrypted by TLS, so it seems that a third party cannot intercept the communication contents.

結局はそのハッシュを第三者に知られることになり、

あー、パスワード自体とその時の時刻情報のようなものを合体させたものをハッシュ化すれば第三者に知られても問題ないようには出来るか(?)

例えばTwitterのような大手サービスも、前調べた時はリクエスト見ると普通にパスワード平文で送ってるし、特に問題ないように思えるが…

そもそもMitMできるような環境下ではWebブラウザが表示してるログイン画面も本物とは限らないのでどうしようもないのでは?
ネイティブアプリの話ならまた別だけど

The hole point using hash can be breakdown into two major reasons.
1 - Users may use the same password over sites, if a attacker capture a password, may result somthing no one can predict.
2 - TLS Can not protect user infomations over all devices. MitM only requires a certification to be installed on users devcices and no visible alert to let users get attention into. This usually happens on public devices, and users dont know them at all

If we use the hash to store users password, then the real password wont be stolen anyway bacause it doesnt exists. Only people that knows the password can be authorized.

[1/*]

サーバーからのチャレンジに対してパスワードのハッシュとかをキーにした HMAC で投げるとかはどうだろう

サーバーからのチャレンジに対してパスワードのハッシュとかをキーにした HMAC で投げるとかはどうだろう

This can do the job. Im drawing a concept pic.

tls cannot protect user information

if you are in an environment where your tls is already compromised and you're subject to a mitm attack, then hashing your password won't do you much help. the authorization token used in all following requests is only protected by tls as well.

then again, sha-256'ing your password at client side can be a layer of protection, but if you're up against an adversary who can compromise your tls and mitm you then not sure if it's much use at all. they can just use your hashed password later without your authorization. (and rainbow table it back)

if the "public device" is compromised then are we sure it's worth to add significant complexity by a hmac challenge? the device itself is already compromised...

In this day and age the whole security of the internet (just look at OAuth 2) is based on "TLS is secure". If you throw that away you're in a much deeper problem than that can be solved by hashing the user's password client side.

It is of course possible to make an internet service secure without TLS but it's not something i'd demand of misskey. (You'd basically have to build "your own TLS")

截屏2020-07-24 下午4 39 57

I think, if users affected MitM attack, login form can't trust because attackers may injecting some malicious code (like send plain password to attackers server before actual login).

in this context, we can only defense by 2FA (but meaningless because attackers can spy access token).
do you think about this?

"TLS is secure" =/= We should use clear text password, this is not the way an app should do.

I understand this change may break a lot of things, but it is what we should do. Use a hash to store users password is what wordpress and other applications also used to keep everything safe.

I'm positive Misskey stores your password hashed and not in plain text. That doesn't mean you can't send authentication information over TLS. The whole point of TLS is to resolve this complexity.

in this context, we can only defense by 2FA (but meaningless because attackers can spy access token).
do you think about this?

This is not the only reason I want to let you get notice.
2FA is greate protecting from unauthorized login on our Misskey Instance, but can not protect users from being cracked on other sites.

Users may use the same password over sites, if a attacker capture a password, may result somthing no one can predict.

That doesn't mean you can't send authentication information over TLS. The whole point of TLS is to resolve this complexity.

We should protect our users in any situation, not let them check if there network is safe. They are users and likely having no idea what is going on on backend.

Again

"Make TLS Secured Again" =/= We should use clear text password, this is not the way an app should do.

We should keep this in mind, and redesign our login system if possible. I truly understand this is a long way to go.

重大な脆弱性というわけではなく、やれたらよりセキュアだね(nice to have)くらいの認識だけど合ってる?

GitHubも平文で送信してるので、今すぐ対応しなければいけないって程でもなさそう

I have to point out that Twitter is sending your password in "plain text" (over TLS of course). I wonder if it's good enough for Twitter are we sure it's not good enough for Misskey?

保存は平文ではないですよね?

データベース上ではハッシュ化してます

まあそれはそれとして運用者がログを雑に扱っていて漏洩する可能性はある(Twitter もやらかした)

送られるパスワードはログ出力されることある? それは避けたいことやな。(Railsなら自動でREDACTEDとしてログされる)

アクセスされたURLをログすることはあるけど流石にPOSTのbodyまで出力することはないハズ
そういうログ周りを考えたらこのissueを実装する価値はありそうか

Misskey本体のログとして出力されることはない。
悪意ある運営者がWiresharkみたいなソフトウェアで無理やり抜くことは可能だけど。

アクセスされたURLをログすることはあるけど流石にPOSTのbodyまで出力することはないハズ

Misskey 自体のログでは発生しないけどリバースプロキシ側だと構成によってはありえなくはない

うんまぁログインページと一緒にchallengeみたいなの返してそれをsaltに使ってハッシュして送るてはあるがサーバー側で扱うのがそこそこめんどくなる

I have to point out that Twitter is sending your password in "plain text" (over TLS of course). I wonder if it's good enough for Twitter are we sure it's not good enough for Misskey?

Twitter is using certification pinning on there mobile app, iirc. Have not looked at web 😓

Yep, it is nice to have.

まあログ見てパスワード抜くような悪意ある運営者なら、このIssue実装したとしてもアカウント作成時からリクエスト監視しておいてパスワード抜いたり出来そう
それともこのIssueではアカウント作成時のパスワード設定もハッシュ化しようとしている?(可能なのか?)

運営者に悪意があるならもうそれはどうしようもないと思うけど、サーバーにウイルスが入った際などのパスワード漏洩防止にはなる

確かにそうか

将来的には実装するかもしれないが優先度は低めという温度感にします
皆様ありがとうございます🙏🙏🙏

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ibrokemypie picture ibrokemypie  ·  3Comments

syuilo picture syuilo  ·  3Comments

tamaina picture tamaina  ·  3Comments

tamaina picture tamaina  ·  3Comments

AyaMorisawa picture AyaMorisawa  ·  3Comments