これほど単純なのに、なぜ Basic 認証はまだ使われるのですか?

TLS 上ではマシン間のエンドポイントに対して十分であり、実装が極めて簡単だからです。弱点はクレデンシャルの再利用と、有効期限・スコープ・失効の仕組みがないことです。トークンベースの方式がこれらを追加します。

デコード結果が文字化けして見えるのはなぜですか?

プレフィックスが除去されていないか、クレデンシャルに別の文字セットでエンコードされた非 ASCII 文字が含まれているかのどちらかです。デコーダのオプションで正しい文字セットを指定して再試行してください。

Base64 デコードとコロンによる分割、そして Basic Auth の資格情報が慎重な取り扱いを要する理由をはっきりさせます。

1

HTTP Basic 認証は、クレデンシャルを Authorization ヘッダーとして送ります。「Basic 」に続いて username:password の Base64 エンコードを置く形式です。デコードはまさに 1 回の Base64 操作です。これはセキュリティ上の教訓でもあります。Base64 は転送エンコーディングであって保護ではありません。通信路上でクレデンシャルを守るのは HTTPS です。
2

Base64 デコーダー →
まず「Basic 」プレフィックスを取り除き、残りを UTF-8 文字セットでデコードします。出力は username:password です。
3

分割は最初のコロンの位置でのみ行ってください。ユーザー名にコロンの含まれるシステムもあれば、パスワードにコロンの入ることは頻繁にあるからです。最初のコロン以降のすべてがパスワードです。デコードされた値は生きたシークレットとして扱ってください。ログ、チケット、スクリーンショットに貼り付けないでください。可能ならこの演習には使い捨てのテストアカウントを使ってください。

これほど単純なのに、なぜ Basic 認証はまだ使われるのですか?: TLS 上ではマシン間のエンドポイントに対して十分であり、実装が極めて簡単だからです。弱点はクレデンシャルの再利用と、有効期限・スコープ・失効の仕組みがないことです。トークンベースの方式がこれらを追加します。
デコード結果が文字化けして見えるのはなぜですか?: プレフィックスが除去されていないか、クレデンシャルに別の文字セットでエンコードされた非 ASCII 文字が含まれているかのどちらかです。デコーダのオプションで正しい文字セットを指定して再試行してください。