ノートンパスワードマネージャを使うと他のパスワードマネージャに移行できない可能性がある、あるいは非常に手間がかかる

概要

検討に際してパスワードのインポート、エクスポート周りの挙動を調査した結果、エクスポートしたデータに問題があることが分かった

どういう問題があるのかをここにまとめる

前提

ファイルが添付できないのが悩ましく、しかたなくファイルをbase64エンコードしてテキストデータとしてメモ欄にでも保存して移行しようか・・・とか考えていた

が、このあたりの挙動調査をしていて気になる点が見つかった

問題点

エクスポートに問題がある。以下は適当に作ったダミーデータをエクスポートした結果である

https://gyazo.com/ba4c0cbadef3f61b622ed4ea5b9a7ca5

このエクスポート結果のどこに問題があるのかを以下に列挙する

Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes.

改行(CRLF)、ダブルクォート、カンマを含むフィールド はダブルクォートで囲む必要があります。

If double-quotes are used to enclose fields, then a double-quote

appearing inside a field must be escaped by preceding it with

another double quote.

フィールドを囲むために二重引用符が使用される場合、二重引用符は

フィールドの内側に現れた場合は、その前にそのフィールドをエスケープしなければなりません。

別の二重引用符で囲む。

つまりCSVの仕様を満たしていない

正しくは以下のようになっているべき

"a""b,cd"

CSVパーサーによっては読み込む時にバグりそう

Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes.

改行(CRLF)、ダブルクォート、カンマを含むフィールド はダブルクォートで囲む必要があります。

こんな名前の人が存在するわけないが

こうなるのが正しいはず

"\,,,,,,,,\"

つまりは、データとして入力したカンマと、データとデータの区切り文字としてのカンマを区別できないので、他のサービスにデータ移行しようとしたときにズレで取り込まれる可能性がある

Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes.

改行(CRLF)、ダブルクォート、カンマを含むフィールド はダブルクォートで囲む必要があります。

1行目のメモデータが該当する

元のデータは以下

code:memo.txt

a

b

c

d

これはRFCでは以下のようになっていないといけない

code:memo2.txt

"a

b

c

d"

つまりメモに改行文字が含まれてると、列数を満たさない行データが生まれてしまう

RFCを読むと以下とわかる

文字コードは規定されていない（RFC内を検索したけれど見つからなかった）

改行文字はCRLF。ただし一部別の値を使用することがある

技術者以外の人はRFCなんか知らないので、ファイルとして最初からダウンロードされるようにしてるべきなのでは

問題点を踏まえて

これらのエクスポートのされ方を踏まえると、以下の推測が立つ

暗号化されたパスワード情報を複合し、ループでカンマ区切りでテキストに書き出すだけの単純な処理をしており、CSVを扱うライブラリ等は使っていない

流石にこれはパスワードマネージャーとして合ってはならない非常に危険なバグ、または仕様

パスワードを別パスワードマネージャーに移行できない可能性がある

移行に成功するけれど、正しく移行されない可能性がある

例：パスワードにカンマが含まれていて、別カラムのデータとして取り込まれる

これが一番たちが悪い。パスワード自動生成でカンマとか含めていた場合に起こり得る

以上の問題を踏まえてサポートに問い合わせたところ※１、「現状の仕様を変更できないので手動で修正して移行してください」という旨の返答が返ってきた

※１後述するが、僕もサポートへの問い合わせ方が良くなかった

故に、別のパスワードマネージャーに移行する際にはデータをじっくり確認して、ダブルクオート、カンマ、改行文字が含まれていないことを精査してから移行する必要がある

僕は100個以上パスワードがあるので、万が一移行が発生したら一筋縄ではいかない

メモ書きもフル活用していて、改行文字もバリバリ使っているので、手動修正が厳しい

余談：CSVの仕様について

CSVって結構昔から使われてるデータ書式だけれど、明確な仕様が定まっていなかったものと理解している

今回の発見を契機にCSVの仕様を調査して初めてRFCが存在していたことに気付いた

ただしRFC内でも以下の記載があるとおり、やはり仕様が定まっていない時期があったのは確か

策定されたのも2005年のようで、割と最近仕様が定まったみたい

たとえばXML 1.0とかは1998年にW3Cが勧告していたらしい

反省

さすがにこれはパスワードマネージャーとしてあってはならないバグでしょう、と思ってすぐさまサポートに問い合わせを出した

ただこの時に僕もCSVの仕様を勘違いしていて「これが正しいCSVの仕様だと思う」という誤った問い合わせを出してしまった

具体的には3つの問い合わせを出したが、2つが誤りだった

カンマのエスケープが必要→正しくはダブルクオートで括る

「怒ってる時ほど6秒待て」とは良く言ったもので、冷静にRFCで仕様を調査した上でサポートに問い合わせを出すべきだった

Scrapboxでこの記事を書くにあたって、情報ソースを確認するべくRFCを読み始めて、指摘が間違っていたことに気付いた

サポートから指摘されたわけではない

これについては技術者としてあるまじきミスだったと反省するばかり

指摘が間違っていた事は反省するが、それはそれとして現状のエクスポートした形式に問題があるのは変わりない

まとめ

エクスポートしたデータにダブルクオート、カンマ、改行文字が含まれていた時に、正しいCSVデータとしてエクスポートされない

したがって、別のパスワードマネージャーに移行しようとしたときに、インポートに失敗するか、成功するけれど本来あるべき取り込まれ方と違う取り込まれ方をされる可能性がある

ダブルクオート、カンマ、改行文字が含まれる場合は手動でデータを修正してから取り込む必要がある

僕はそんなことはあり得ないと考えているので、パスワードマネージャー選定する時はインポート、エクスポートが正常に行えるかを必ず確認してから選択する

そうしないとサービス終了する時の移行作業が大変になる

サービス終了しなくてもそのサービスにロックインされてしまう

参考