お客さまの情報は安全です
お客さまの安全のため、PayPal は、お客さまの銀行口座番号や、クレジットカード番号を全桁再入力していただく場合は必ず、事前にその番号の少なくとも「下2桁」を提示します。この数字によってお客さまは、PayPalがお客さまの番号全桁をすでに知っており、残りの数字の再入力をお願いしていることがわかります。カード番号の少なくとも下2桁を表示することによってお客さまの番号を知っていることを証明せずに、確認と称して番号を聞いてくるウェブサイトやメールには十分ご注意ください。
paypalのパスワードリセット手順のヘルプより
なるほどねぇ
昨日、こんなニュースが飛び込んできました。
パスワード盗む新手口＝ネット銀の不正送金－被害、最悪ペース・警察庁
インターネットバンキング利用者の口座から無断で現金を送金する事件で、パスワードを盗む新しい手口による被害が多発していることが２４日、警察庁への取材で分かった。不正送金を防ぐため内容を毎回変えている「ワンタイムパスワード」を、犯人がコンピューターウイルスで入手したとみられる。
今年確認された不正送金の被害は９０００万円を超えた。昨年の約４８００万円を上回り、過去最悪だった２０１１年の約３億８００万円と同じペースとなっている。（2013/04/24-21:38）
『「ワンタイムパスワード」を、犯人がコンピューターウイルスで入手』だと? 最初は、いよいよ本格的なMITB(Man in the Browser)が使われ始めたのかと思いました。
その後、ネットで検索して以下の記事を見つけました。
三菱東京ＵＦＪ銀行など複数の銀行で、インターネットバンキングの利用者のＩＤやパスワードが不正に盗み取られるなどし、預金を別口座に送金される被害が今年に入ってから約９千万円に上っていることが２４日、捜査関係者への取材で分かった。
【中略】
捜査関係者によると、利用者のパソコンの多くは、送金などをする際に本人確認のため銀行からパソコンのメールアドレスに送られてくる「ワンタイムパスワード」を盗み取る新タイプのウイルスに感染していた
三菱東京UFJ銀行には口座がないので知らなかったのですが、ワンタイムパスワードをメール送信するタイプのものが使われていたのですかね。調べてみました。これですね。
インターネットバンキングのログイン時の本人確認方法を一部追加します。（平成24年2月12日（日）より）
三菱東京ＵＦＪダイレクトを更に安心してご利用いただけるように平成24年2月12日（日）よりEメールによるワンタイムパスワード（使い捨てパスワード）を導入します。【中略】
現在、当行のインターネットバンキングでは、アクセスされた際のパソコン環境やネットワーク環境などの分析を行い、普段と異なる環境からのアクセスと判定された場合、IBログインパスワードに加えてダイレクトパスワードのご入力をお願いしております。
今回、この本人確認の方法に「ワンタイムパスワード」を追加します。
ワンタイムパスワードは入力が必要になった際に当行が都度指定し、ご登録のEメールアドレスに通知します。
新着ニュース | 三菱東京ＵＦＪ銀行より引用（強調は引用者）
これを読むと、リスクベース認証の追加認証手段として、メールによるトークン送信機能が追加されたようですね。そして、以下の注意が…
※携帯電話をお持ちのお客さまは、利便性と安全性のため、携帯電話のEメールアドレスを登録されることをおすすめいたします。
今回の報道とあわせて考えると、携帯電話のEメールアドレスではなく、パソコンのメールにワンタイムパスワードを送信していた利用者が、ウイルスによりワンタイムパスワードを窃取されたようです。
私は最初、振り込みなど重要な操作の際に入力するワンタイムパスワードが破られたのかと想像したのですが、そうではなく、リスクベース認証の追加認証としてのワンタイムパスワードだったことになります。
そうすると、犯人が振り込み操作をするためには、暗証番号表などの追加の情報が必要になるはずですが、これは従来通り「利用者にすべて入力させた」のでしょうか?
利用者側でとれる対策は下記となります。
追加の報道や銀行からの発表に注目したいと思います。
たとえば、SQLインジェクションは悪意のある、なしにかかわらず、ユーザが入力したデータを検証せずに、そのままSQL文の一部として利用してしまった場合に発生します。
もちろん、ユーザの入力だけでなく、他のシステムから渡されるデータもすべてチェックすべきです。たとえば、バッファオーバーフローは、コピー先バッファの大きさを考えずに渡されたデータを言われるがままにコピーしてしまった場合に発生します。
このようなユーザによる入力や、他のシステムとの連携ポイントでは、必ず入力されたデータをチェックします。とにかく、検証されていないデータはすべて有害であると思ってください。この検証を忘れた場合に、攻撃を受けます。
一方、すでに検証済みの信頼のおけるデータはそのまま利用することができます。先程の例では、高い塀の内側にある場合がそれです。この壁を信頼境界といいます。たとえば、あなた自身がしっかりと管理しているシステムや、そのデータは信頼できるかもしれません。しかし、それ以外のすべてのデータは信頼できないもの、有害なもの、と考えてください。ですから、その信頼できるシステムとそうでないシステムの境界、つまり信頼境界を越えるデータをすべてチェックすべきなのです。
第6回 検証しないデータが引き起こす問題[PPT]スライド4のノートより引用（強調は引用者）
「検証済みの信頼のおけるデータデータ」であっても、SQLインジェクション攻撃は可能なので、この説明はまったく不適切。
これは、トラストバウンダリの定義が間違っているからではなく、トラストバウンダリの考え方ではSQLインジェクション対策はできないのに、無理にSQLインジェクション対策を例にしていることが原因。
ネットを見ていたら「問題集 ： PHP技術者認定・初級」というのを見つけました。
【セキュリティ対策】
セキュリティ対策について、正しいものを1つ次の記述の中から選択せよ。
- 入力のフィルタリングのみ行う。
- 出力のエスケープのみ行う。
- 少なくとも、入力のフィルタリングと出力のエスケープを行う。
- データベースのデータは信頼してよい。
過去問なのか練習用の想定問題なのかわかりませんが、「問題提供： PHP技術者認定機構」とあります。
PHPアプリケーションの問題ですから、Webアプリケーションセキュリティの問題ですね。茫漠とした問題文ですが、実は正答を得るのは難しくありません。選択肢から技術的な中味を抜いてみると下記になります。
このように並べてみると、○○の選択肢（1, 2, 4番）は「これだけやっていれば大丈夫」となっているのに対して、□□（3番）は、最低限これだはやるようにと慎重な書き方になっています。よって、技術的なことは知らなくても、3が正答と分かります。
でも、こういう「国語入試問題必勝法」みたいな解き方はよくないですよね。ここからは、技術的な内容を見ていきましょう。1～3も曖昧で良くないとは思うのですが、このエントリでは、「4. データベースのデータは信頼してよい。」について検討します。
データベースのデータを信頼（信用）してよいかは、データベースの置き場所などにも変わってきますが、一般的には信用してよいと扱うと思います。
この問題の出題者は、PHP技術者認定機構顧問の大垣さんだという気がしたので、その線で検索して見ました。例えば以下の記事です。
トラストバウンダリのコンセプトは非常に単純かつ明快です。しかし，この基本が正しく理解されていないことが多いのです。例えば，数年前に某大手ベンダーがセキュアプログラミングの動画を公開し，トラストバウンダリを使ってどのように安全性を確保するか解説していました。その動画ではなんとトラストバウンダリの中にデータベースが含まれており，前提条件無くデータベースが信頼できるシステムとして扱われていました。
第28回 あまり語られないセキュリティの基本 ── トラストバウンダリより引用（強調は引用者）
この某大手ベンダーとはどこだろうと思って調べたところ、マイクロソフトのようですね。大垣さんの以下のブログ記事が根拠です。
まだ全部見ていませんが
皆様からご要望の多かった開発者が考慮すべきセキュリティの問題点を1つ1つを解説した
【中略】
とメールが来ていました。
【中略】
Trust Boudary（信頼の境界）の説明は私の認識と異なります。プレゼンでは
「特権レベルの替わる場所」
としていますが
「データの受送信でセキュリティ問題が発生する箇所」
と考えています。プレゼンではIISとデータベースが同じ特権レベルであるのでトラストバウンダリの同一領域として「IISとデータベース」が同じ領域として書かれていました。
私の考えではIISとデータベースの間にはトラストバウンダリがあり区別します。区別する理由はセカンドオーダSQLインジェクションやセカンドオーダXSSなどのリスクを考えれば明らかではないでしょうか?
あいにく参照先の記事は今では読むことができないようですが、おそらく以下のような図が掲載されていたのではないでしょうか。
Web アプリケーション セキュリティ強化: 脅威とその対策より引用
つまり、マイクロソフト社はデータベースのデータを信頼して良いとしているが、大垣さんの意見は違っていて、データベースのデータは信頼してはいけない、その理由はセカンドオーダーSQLインジェクションなどの脅威があるから、ということのようです。
しかし、SQLインジェクション脆弱性となるのはアプリケーションのバグが原因であり、データが信頼できる・信頼できないは関係ありません。データの中味がSQLインジェクションコードであっても、バグ（脆弱性）がなければ影響を受けないわけです。すなわち、SQLインジェクション対策という文脈では、トラストバウンダリも、「データの信頼性」も関係ない、ということです。
また、大垣さんは以下のような記事も書いておられます。
たとえ内部システムから取得したデータであっても，そのデータの起源や管理状態が不明確な場合はデータを信用してはなりません。実際にあった例ですが，管理システムが動作ログをメールメッセージで送信し，ログ保存システムがそれを受け取ってデータベースサーバにログを保存し，管理用のWebアプリがそのデータベースから取得したログを表示するシステムがありました。ログメッセージにはHTMLタグが含まれる場合があるため管理用のWebアプリはエスケープなしにログを表示していました。ログメッセージの送信先のメールアドレスとメール形式を知っているユーザであれば，誰でも簡単にスクリプトインジェクションを行い管理者のセッションを盗むことが可能な状態でした。
メールサーバから直接ログを取得していたのであればプログラマも危険性を考慮できたかもしれません。別のシステムを経由するとリスクが明白でなくなることがよくあります。本当に信頼できるデータのみ信用できるデータとして扱わなければなりません。
【スクリプトインジェクション対策12】データベースなど，内部データを信用しないより引用（強調は引用者による）
データベースのデータをHTMLエスケープなしで表示するケースは確かにあります。CMSやブログシステムなどで、HTML形式のデータを保持している場合は、出力の際にHTMLエスケープしません。この種のシステムでは、SCRIPT要素などが入力されてXSSとなる可能性がありますが、通常は以下のように対処します。
後者の場合、タグの検証をどの段階でするかですが、通常は入力時、すなわちデータベースに登録する前にチェックするでしょう。そして、いったんチェック済みとしてデータベースに登録した後では、HTML出力時には再チェックしない場合がほとんどではないかと思います。すなわち、データベースのデータは信用しているわけです。
ここで、思い出すのが、『ヤフーにおけるインプットバリデーション「何も信じるな」』という記事です。ヤフー!では「何も信じるな」というセキュア実装方針を採用されているそうですが、この記事の中には「データベースのデータも信じない」とは書いていないのです。すなわち、「何も信じない」という実装ポリシーにおいても、データベースのデータは信用するということだと私は理解しました。
私がそう思う理由の1つとして、HTMLタグのチェックがかなり重たい処理であるという事情もあります。このため、許可されたタグのみであることのチェックは入力時に行い、データベースの内容は「チェック済み」として信用するという実装が一般的です。少なくとも、私はHTML表示の度に許可されたタグであることのチェックをしている実装を見たことがありません。もし、Yahoo!のように負荷の高いシステムでこの出力時のチェックをしているのであればすごいことなので、ぜひ教えていただきたいと思います。ただし、広い世の中には表示の度にHTMLタグの検証をしているWebシステムもあるかもしれませんが、それはアプリケーション要件として実装しているものであって、必ずそうするべしという証拠にはなりません。
ここで、もう一つの問題が浮上します。データによっては「HTMLエスケープしないで表示する」場合があることを認めるとすると、冒頭に紹介した選択肢「3. 少なくとも、入力のフィルタリングと出力のエスケープを行う。」は間違いと言うことになってしまいます。つまり、これも一般的な原則なのであって、例外もあり得るということで、問題としては不適切でしょう。
大垣さんの主張を要約すると、以下のようになるでしょう。
私の意見は以下の通りです。
私は大垣さんの記事の熱心な読者なので、冒頭に紹介した問題文を見て、「（出題者であろう）大垣さんは3を正答にしたいのだろうな」とすぐに分かりましたが、同時に、大垣さんの記事をあまり読んだことがない方には、この問題を（国語入試問題必勝法以外の正攻法で）正答するのは難しいだろうなと思いました。この問題が、「世間の大多数が正しく理解しておらずマイクロソフト社のような著名企業でも間違って説明している」という大垣さんの持論を根拠にしているからです。
※追記※ 引用した問題の出題者が大垣さんではないかというのは、あくまでも予想です。しかし、仮に、大垣さんの出題でないとしても、引用した問題文が適切でないという結論は変わりません。
イケダハヤト尊師の「社畜と家畜の共通点」が話題です。昨日の段階で「思いのほかウケました。5.300PVほど」ということなので、今日は8,000PVはいくのではないでしょうか。
反応は賛否両論という感じですが、以下のやりとりのように、不快感を示す感想も多いようです。
うふふふ。 “@evilsniff: ひとを不愉快にさせる天才だなこのひと｜社畜と家畜の共通点 ikedahayato.com/index.php/arch… @ihayatoさんから”
— イケダハヤトさん (@IHayato)
それでは、なぜ読んで不快になるかですが、以下のように「図星だから怒るのでしょう」という意見もあります。
おもしろい。社畜の人はあたってるから怒るんでしょうね。w / 社畜と家畜の共通点 ikedahayato.com/index.php/arch… @ihayatoさんから
— Fuminoriさん (@glitter_14)
しかし、そうとは限らないと思います。このエントリが不快になる理由は、文章が曖昧だからです。
元エントリは以下のように始まっています。
巷でよく言う「社畜」って何なんでしょうね？と思ったので、家畜との共通点を洗い出してみましたよ。
飼われている
家畜は牧場主に飼われています。【後略】
社畜と家畜の共通点を列挙する形で始まっているのですが、この文章には以下の二通りの解釈が可能です。
1. と受け取った人は、「日本を支えているサラリーマンを十把一絡げに家畜になぞらえるとは何事か」と不快になります。一方、2.と解釈した人は、「自分は家畜でないし、すなわち社畜ではなく、これは自分のことを指していない」と読むので不快にはなりません。
私自身は、最初 1. なのかなと思いながら読み進めたのですが、最後のところで、以下の文が。
このブログをお読みの方々は、「社畜」からは遠い存在でしょう。
「このブログをお読みの方々」の中には当然サラリーマンも多く含まれているはずで、そうなると、2.の解釈が正しかった、ということになるのでしょうか。
しかし、この文にいきあたるまで、1.と受け取った読者は十分に不快になっているので、今さら（あなたは）「社畜」からは遠い存在ですと言われても、不快な気持ちが晴れるわけではないのですね。
一般的な散文の作法としては、二通りの意味に取れる文章はあいまいで良くないとされますが、イケダハヤト尊師は必ずしもそう思っておられないのかもしれません。
どんなテキストも、「著者の真意」なんて気にする必要はありません。そんなものに縛られると、ろくなことがありません。
「著者」の中には尊師自身も含まれるはずで、とすると、尊師の「真意」を推し量ろうとしている私はろくなものでないということでしようか。
また、以下のようにも述べておられます。
100%の文章じゃなくていいのです。80%の完成度に達したら、とりあえず出してしまいましょう。そのことによるマイナスは、ほとんどありません。眠らせるぐらいなら80%で「えいやっ」と出してしまうべきです。あえて生煮えのものを出すことで、市場から叩かれ、より考察を深めることができるでしょう。
【中略】
ぼくは一つの記事の執筆時間の目安を「15分以内」にとどめています。この文章も銀座から新宿に向かう20分ほどで仕上げています。ふとした空き時間にサクっと書けるようになれば、それだけ継続しやすくなります。
文章を練りに練って曖昧性のない正確な文章を書くことは、元々狙っていないようですね。
この「文章作法」は、「プロブロガー」にとって以下の恩恵をもたらします。
素晴らしい。そして、私は「プロブロガー」になるのは無理そうだと、あらためて思いました。
twitterでは以前からパスワード設定時に辞書による「ありがちなパスワードチェック」がありましたが、facebookでも辞書によるチェックを始めたようです。
上記は「password!」というパスワードを設定しようとして、弾かれたところです。
昨今パスワードに対する攻撃が活発になっているので、このような「ありがちなパスワードチェック」を取り入れるサイトが増えるとよいですね。
UTF-8の亜種の一つで、Oracleが使っている不届き千万な仕様の一つ。
概要
本来UTF-8(RFC 2279)では、サロゲートペアは適時解釈してから符号化せねばならない。
しかしこのCESU-8は、サロゲートの各ペアを機械的にUTF-8に変換するのみであり、supplementary characterは6バイトで表現される。これはUTF-8の仕様から外れた手法であるばかりか、公害ともなりうる実装である。
しかしながら、Oracleはこのような実装をしてしまった。それを正当化するために、CESU-8としてエンコーディング登録をしてしまったのである。
脆弱性には2種類あります。
たとえば、パスワードリセットするのに、(a)秘密の質問に対する答えを知っている、(b)あらかじめ登録したメールへの送信文を読める、の両方が必要という要件に対して、実際には片方だけでリセットできたとすると、「アプリケーションの要件を満たさない」という意味では脆弱性ですが、一般的な要求水準は満たしているので、「一般的には許容されるレベルだが、本来のセキュリティ機能を満足していない」という意味で「軽微な脆弱性」となります。
一方、個人情報入力フォームがSSL暗号化していない場合、「最低限の水準」を満たしていないとはいえないので一般的には脆弱性ではありませんが、プライバシーポリシー等に「個人情報は暗号化して送信されます」などと書いてあるのにSSLになっていない場合は、利用者への約束（=要件）を満たさないという意味で脆弱性です。
さらに、個人情報をSSLで送信しているが入力フォームがSSLになっていないので不十分な対応という場合も脆弱性です。これは、要件として明記されていなくとも「個人情報を暗号化して送信する」という暗黙の要件があり、その要件に対して不十分な実装、という意味で脆弱性とみなされるわけです。
まったくSSLを使わない場合は脆弱性ではないのに、中途半端にSSLにすると脆弱性になるのは「まったく何もしないよりマシなのに脆弱性となるのは変だ」、と感じる人が多いと思います。
しかし、提供者側が「暗号化されているから盗聴されないだろう」と思っていたり、利用者側も「SSLを使っているから大丈夫」と思っているところ、実際にはそうではないという点が問題なのです。「危ないかも」と思っていれば公衆無線LANなどの環境では使わないという回避策がとれますが、安全だと思い込んでいれば回避策も取れないことが問題です。安全でないものが安全なフリをしてはいけないのです。
※facebookでの会話から抜粋+追記
ネットの記事を読んでいたら、セキュリティ対策していないPCをインターネットに接続すると平均4分で不正プログラムに感染すると書いてありました。どこかで読んだ記憶があるなと、古い記事を調べましたので、皆様の参考のために共有します。
当該の記事には、以下の記述がありました。
ノーガードなら平均4分……国内の複数のセキュリティ機関が合同実験をしたところ、何も対策をしなければ、平均して4分で不正プログラムに感染することが分かった。必ずウイルス対策ソフトをインストールし、パターンファイルを最新にしてからネットサーフィンしていただきたい。
“迷探偵”ハギーのテクノロジー裏話：ウイルス対策ソフトの未来を占う (3/3) - ITmedia エンタープライズから引用
「ノーガードなら平均4分」というのは、どこかで読んだ記憶があるなーとfacebookでつぶやいておりましたら、歌代さんとはせがわさんが教えて下さいました。Telecom-ISAC と JPCERT/CC の調査(2005年)ですね。
調査は、ISP内に設置したハニーポットによる検体の収集・観察や、ISPへのヒアリングを通して実施。調査結果として、国内のISPユーザーのボット感染率は2～2.5％で、40～50人に1人が感染していることが判明した。また、小山によると、対策をまったく施していないPCをインターネットに接続した場合、平均4分でボットに感染するという。現状では常時20種類程度のボットが感染活動を行っており、1日平均70種類以上の亜種が確認された。
40～50人に1人がボットに感染――ボットネットの実態が明らかに - ITmedia エンタープライズより引用（太字は筆者）
この記事を手がかりにネットで検索すると、上記実験の解説もありました。
図3を見て分かるとおり，(1)だけが能動的な感染方法であり，その他は受動的な感染方法である。
前述のボットネット研究チームのデータをここで再度紹介すると，ボットが感染に利用しているのはほとんど(1)の方法であることが分かっている。最も多かったのはWindowsのぜい弱性であるMS03-026（全検出数に対し31.5％の割合）。また，ぜい弱性以外で多かったのはパスワード破りによる共有フォルダへのアクセスである（全検出数に対し23.7％の割合）。
ボット / SAFETY JAPAN [セキュリティの今を読み解く10のキーワード] / 日経BP社から引用
ネットにつないで「何もしないで4分で感染」ということは、能動的感染であるわけで、原理的には以下の二種類の経路があります。
前述の引用もこれを裏付ける形になっていますね。このため、この記事でもボット対策として、以下を推奨しています。
この2点を考えると，セキュリティ対策の鉄則である修正プログラムの適用と複雑なパスワードの使用がボットの感染を防ぐために肝要である。
ボット / SAFETY JAPAN [セキュリティの今を読み解く10のキーワード] / 日経BP社から引用
しかし、もう一つ大事なことがあります。能動的な攻撃を外部から実行するには、攻撃対象のポートが開いていないといけません。前述の記事に出てきたMS03-026の場合は、以下のように説明されています。
攻撃者がこの脆弱性を悪用するには、リモート コンピュータのポート 135、ポート 139、ポート 445、または RPC 用に構成されたその他のポートに対して特殊な細工をした要求を送信することが必要条件となります。イントラネット環境では、通常これらのポートはアクセス可能ですが、インターネットに接続されたコンピュータでは、通常これらのポートはファイアウォールによってブロックされています。
[MS03-026] RPC インターフェイスのバッファ オーバーランによりコードが実行されるより引用（太字は筆者）
明快な説明ですが、「ノーガードなら平均4分」というのは、ウイルス対策ソフトが導入されていない場合というよりは、下記の二点が問題だったことになります。
現在では、ブロードバンドルーターのファイアウォール機能や、パーソナルファイアウォールによって、上記ポートがインターネットに対してブロックされている場合が大半だと思いますが、2005年当事は、それができていないPCが多かったのでしょうね。
本日早朝に、Evernoteが外部からの攻撃を受けて、ユーザ名、メールアドレス、パスワードハッシュ値（ソルト付きハッシュ）にアクセスされたという報告（セキュリティ関連のお知らせ：Evernoteでのパスワード再設定のお願い）がありました。
Evernoteのユーザは、このお知らせの指示にしたがい、パスワードをリセットしましょう。問題は、Evernoteのコンテンツ（ノート）にアクセスされたかどうかですが、Evernote社では、以下のように、ノートにはアクセスされた形跡はないと主張しています。
弊社セキュリティ調査の結果、Evernote に保存されているコンテンツが外部からアクセス・変更・消失された形跡は確認されませんでした。また、Evernote プレミアムおよび Evernote Business のお客様の決済情報がアクセスされた形跡も確認されていませんのでご安心ください。
一応これを信じるとしても、アカウントにアクセスされたからには、コンテンツにもアクセスされる可能性はあると考えるのが自然でしょう。Evernoteに機微なテキストを保存する際には、テキストを暗号化する方法があります。この際の暗号化パスワードはサーバー（ノート）には保存されないということですので、仮にノートの情報が漏洩しても、テキストの内容までは漏洩しにくくなることが期待出来ます。
テキストを暗号化する作業は、PC版あるいはMac版のEvernoteクライアントを使います。まず編集中の文書から、暗号化のための領域を適当な文字列で確保します。この状態で、以下のいずれかにより暗号化を選択します。
すると、以下のようにパスフレーズを入力する画面が表示されます。
パスフレーズを2回入力します。また、パスフレーズを思い出すためのヒントをオプションで入力します。すると、選択状態の箇所が四角い枠で囲まれるので、その場所に暗号化したい内容を入力します。場所取りのために入力した文字列は消します。これがめんどうであれば、暗号化したい文字列を先に入力してから暗号化操作をしてもよいですが、秘密の文字列がEvernoteのサーバーに、Evernote社に読み取り可能な形式で送信される可能性があります。
このままセーブすると、以下のように錠前のアイコンとして表示されるようになります。
暗号化テキストを平文で表示するためには、このアイコンをダブルクリックするか、アイコンを選択した状態からコンテキストメニューで「暗号化したテキストを表示する」を選択します。以下のように、パスフレーズ入力画面が表示されます。
パスフレーズを入力すると、暗号化テキストは表示されます。
一方、「やっぱり一々パスフレーズ入力するの面倒くさいし、暗号化やめるよ」という場合は、コンテキストメニューから「暗号化を完全に解除する」を選択して下さい。
暗号化テキストは、EvernoteのWebクライアント上では以下のように表示されます。
錠前アイコンをクリック（ダブルクリックではない）すると、以下のようにパスフレーズ入力の画面が表示されます。
パスフレーズを入力すると暗号化テキストが以下のように表示されます。
以前はこの機能（Webクライアントでの復号）はなかったように記憶していますが、追加されたのでしょうか。おそらく、復号機能をJavaScriptで実装したのでしょうね。このJavaScriptを読めば、暗号化アルゴリズムなども分かるのでしょうが、私はそこまではやっていません。
また、iOS版とAndroid版のクライアントでも、暗号化テキストの復号はできます。iOS版は、「暗号化を完全に解除する」機能も使えます。一方、暗号化した状態での編集は、どちらもできないようです。
以下に、いくつかの注意点を列記します。
