アトラシアンは有害と考えられる
Joe Schaeferこのページのようなものに二つの視点があります。過去10年間のアトラシアンソフトウェアの脆弱性:
それは責任ある開かれた開示を示し、販売のためのよいマーケティング材料であることを、
これは、大規模なアーキテクチャ障害の長い記録です。.
私は後者のキャンプです。1
脚注
1。私たちのチームの有名な2010ポストモーテムの最後の文で
https://infra.apache.org/blog/apache_org_04_09_2010 2
We State(パラフレーズ)
「私たちは、他の人々が私たちの過ちから学ぶことを願っています。
後見では、明らかに私たちの希望は誤って配置されました:
https://cybersecuritynews.com/atlassians-model-context-protocol/
ただし、オリオンアパチェCMSは、そのポストモーテムが出版されてから6ヶ月後に生まれた。その場合、これらの教訓は、生きた経験の痛みからデザインを知らせた。
2。この事件についてのAtlassianの無能なポストモーテムへのブログエントリは、インターネットからリダクションされています。基本的に彼らは数年後に301を維持することができなかったので、それが傷ついた場所です:
https://www.atlassian.com/blog/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach
セキュリティ・インシデントをPRの推進の機会と見なすメガ企業のパーマリンク優先度のため。
レコードの場合、SHA-*は暗号化アルゴリズムではなくハッシュ・アルゴリズムであり、暗号化的にセキュアなハッシュ・アルゴリズムははるかに少なくなります(例: bcrypt またはcrypt-md5). SaaSベンダーから、ハッカーが復号化キーを取得してプレーン・テキストで読み取る可能性があるため、パスワードが暗号化されていることを通知されたくありません。
ハッカーがSHA-*ハッシュを持っているときに安全であることを安心させたくないのは確かです。SHA-*は、ハッシュ自体に対して計算的にトラクタブルなブルートフォース検索/推測アルゴリズムにパスワードを従わせるのに十分なパフォーマンスを発揮するように設計されています。パスワードが次の方法でハッシュされたことを仕入先に伝えたいbcrypt その構成で少なくとも5ラウンド- ブルートフォース推測を打ち負かし、時代のハードウェア仕様に更新できるように設計されています。
でも、それを変えるのは、やるべきことだからです。
パスワードセキュリティに関するApache postmortemの箇条書きを理解するのに困った場合、ハッカーが盗んだ顧客のパスワードのSHA-*ハッシュの安全性について、顧客に送ったMike Cannon-Brookeのドリベルを読むのは馬鹿げています。
さらに、毎日彼らのインシデント対応チームが週末に寝ていたが、別のF/OSS組織がそのSliceHostボックスによってハッキングされた。シドニーでの営業時間後の調査結果を金曜日にチームに通知し、セキュリティ電子メールを時間外に読んで、日曜日のPST時間にハッキングされなかったことを顧客に伝える代わりに、彼らはファイブベッドし、ハック自体を発見したと述べました— 完全に捕まった。
RedHat、CodeHaus、JBossは、Atlassian IRチームが眠っている間にハッキングされた偶発的な犠牲者のうちの3人でしたが、他にもいくつかありました。