[1] HTML の type が password の input 要素は、単一行文章入力制御子を定義します。 この制御子では、入力された文章は隠されます。

[2] 仕様書:

[3] 属性:
属性名属性値既定値説明出典
accesskey%Character[HTML 4]
align配置[HTML 4] 非推奨
autocompleteon | off自動補完WinIE 5+, Web Forms 2.0
class級[HTML 4] %coreattrs
datafldデータ欄[HTML 4] 予約
dataformatasデータ書式[HTML 4] 予約
datasrc%URI(なし)データ源[HTML 4] 予約
dir書字方向[HTML 4] %i18n
disabled(真偽値属性)(偽)無効[HTML 4]
id一意識別子[HTML 4] %coreattrs
inputmode入力モードOMA 規格XHTMLMP
istyle入力モードiモード 2.0
lang自然言語[HTML 4] %i18n
xml:lang自然言語[XHTML 1]
languageスクリプト言語WinIE 4+
maxlengthNUMBER最大長[HTML 4]
name制御子名[HTML 4]
onblur%Script焦点を失した時[HTML 4]
onchange%Script現在値変更時[HTML 4]
onclick[HTML 4] %events
ondblclick[HTML 4] %events
onfocus%Script焦点を得た時[HTML 4]
onkeydown[HTML 4] %events
onkeypress[HTML 4] %events
onkeyup[HTML 4] %events
onmousedown[HTML 4] %events
onmousemove[HTML 4] %events
onmouseout[HTML 4] %events
onmouseover[HTML 4] %events
onmouseup[HTML 4] %events
onselect%Script文選択時[HTML 4]
readonly(真偽値属性)(偽)読取専用[HTML 4]
size寸法[HTML 4]
styleスタイル情報[HTML 4] %coreattrs
tabindexNUMBERタブ順[HTML 4]
title注釈的題[HTML 4] %coreattrs
typetexttext制御子の種類[HTML 4]
value初期値[HTML 4]
vcard_name自動補完WinIE 5+

名前

[7] 制御子名は name 属性で指定します。

初期値と現在値

[6] 初期値は value 属性で指定します。

現在値は、はじめ初期値です。その後は、利用者が編集した結果が現在値です。

[17] Bidi と提出値: 利用者が入力欄の基底方向性を上書きした時は、 それを (提出する文字符号化方式で可能なら) LRM や RLM で囲んで示すべきです SI 4281:1998 8.2。

レンダリング

[18] 制御子と bidi: 制御子自体は、 (中身である現在値と関わりなく) 方向性に関して中立な1文字であるかのように bidi 的には扱います SI 4281:1998 6.1.4。

[19] 方向と入力モード: ヘブライ語に対応した利用者エージェントの場合、 右から左の入力欄では、カーソルの初期位置は右側とし、 入力モード (鍵盤言語) はヘブライ語とし、 左から右の入力欄では、カーソルの初期位置は左側とし、 入力モード (鍵盤言語) は異言語とするべきです。 SI 4281:1998 8.2

[20] Bidi と合言葉: そもそも合言葉で書字方向が混在した場合、どうなるのでしょうか? 代替文字表示を行っている場合は本来の表示順と代替表示の表示順が必ずしも一致しないかもしれません (し、本来の表示順に合わせているかもしれません) が、これは何を意味するのでしょうか?

[21] 入力システムと合言葉: 一部のシステムでは、仮名漢字変換を合言葉入力で使うことができません。 別のシステムでは使うことができますが、変換中の文字も代替文字になります。 仮名漢字変換を使うことができ、変換中の文字は代替文字にならないでそのまま表示されるシステムも考えられます。代替文字になっていても、 変換候補選択画面では通常通りの表示になっていることもあります。

システムによっては仮名漢字変換で再変換の機能があります。 これが合言葉入力でもはたらき、変換候補選択画面では通常通り隠さず表示されるとすると、 一旦正当な利用者が合言葉を入力した状態で席を離れ、 不正な利用者がその間に再変換して合言葉を盗む可能性があります。

入力の隠蔽

[8] UA は、入力された文字列 (初期値・現在値) を隠してレンダリングします。 HTML 4 17.4.1

代替文字による表現

[24] 例えば文字を星印 (*) にかえてレンダリングします。 HTML 4 17.4.1

[9] 実際の UA では、 * の他、 ● なども代替文字として使われています。 Windows Vista など新しい Windows では「●」が標準的な代替文字に採用しているようで、 Firefox など Windows 上で動作する Webブラウザーもそれに沿ってレンダリングしているようです。

[25] しかし、旧来の「*」を想定してデザインされていた Web頁は文字幅の異なる「●」 (一般的な日本語環境ではそれぞれ半角、全角の幅) が表示されると十分な数の文字を同時に提示できなくなってしまうことがあります。 特に暗証番号の類は4桁など狭い幅で表示され、「●」だと半分程度しか表示されないことがあります。

[30] このレンダリング方法では、表示画面を覗き込まれると合言葉の文字数が知られてしまうおそれがあります。

[31] Bug 97811 - use bullets instead of asterisks to block out password characters https://bugzilla.mozilla.org/show_bug.cgi?id=97811 (名無しさん 2006-10-25 23:41:19 +00:00)

空文字列による表現

[10] オペレーティング・システムのログイン画面や Unix 系 CUI ソフトウェアなどで合言葉を入力する際には入力があっても空文字列としてレンダリングする (何もレンダリングしない) ことがあります。 覗かれても文字数すら分からないという点ではより安全かもしれませんが、 入力されているかどうかが分からないので、特に (相手が信用できるかすらわからない分散システムである) ウェブのブラウザではそういうのは望ましくないかもしれません。

但し、入力欄の枠線の色を変えるなどして入力されているかどうかを容易に判別できるなら、 別に問題とはならないでしょう。

隠さず表示

[12] システム環境によっては、 合言葉であっても隠さないで入力されたとおりレンダリングするような設定ができることがあります。 ウェブ・ブラウザによってはシステムのそのような設定を反映するかもしれませんし、 独自の設定でそれが可能かもしれません。

[29] 携帯電話上の Webブラウザーでは入力中は文字入力の画面に切り替わり、 そこでは平文のままレンダリングされることがあります。

保安性

[11] password 制御子は、合言葉などを要求するために使われます。 しかし、 UA は入力を隠してレンダリングしますが、 その他の点では他の制御子と扱いは変わりません。 HTML 4 17.4.1

ネットワークを通じた提出

[27] フォームの提出の方法に依存しますが、普通に HTTP で送ればおそらく平文のままとなるでしょう。重要な情報であれば TLS を使うなどして暗号化した方が安全です。

[23] passwordsInTheClear-52 ( 版) http://www.w3.org/2001/tag/doc/passwordsInTheClear-52

ソースの表示

[13] また、 value 属性に指定される初期値は当然平文で記述します。 たとえ UA にレンダリングしなくても、ソースを見ればわかります。 ですから、一連の作業 (セッション) の中で、 前に入力された合言葉を後から password の value 属性で送りなおすと危険な場合もあります (例えば、 作業者が途中で席を外した隙に他の人がソースを覗いたらどうでしょう)。

[28] ソースに直接記述されていない入力中の値であっても、 Firefox の DOM Inspector のように DOM の値を閲覧できる方法が用意されていると読み取られてしまうことがあり、 注意が必要です。

利用者界面の機能を通じた複写

[22] 多くの GUI システムなどではクリップ板を使った複写や貼り付けの仕組みが用意されており、 合言葉入力欄でもこれが有効なことがあります。 しかし、合言葉を複写して他の場所に貼り付けることで合言葉が盗まれる危険性があります。 クリップ板以外でも、例えばマウスによるドラッグ及びドロップで文字列を移動する機能が実装されていると、 合言葉入力欄から他の欄に移動できてしまうかもしれません。

スクリプトによる取得

[14] スクリプトなどの手段を使うと、初期値や現在値が取得できるかもしれません。 また、環境によっては、その環境で用意されている widget (GUI 部品) を使うと (たとえレンダリングされていなくても) 現在値を別のプログラムから取得できるかもしれません。 特に UA の設計者は、スクリプトからの access 可能範囲の限定を徹底するなど、 十分な配慮を行うべきです。

補完機能

[15] 現在では、多くの UA で自動補完機能が用意されていて、 利用者は以前に入力した合言葉を毎回入力する必要はありません。 しかし、この機能が危険と隣り合わせであることは自明です。 特に共用の環境では、この機能は常に切っておくべきです。

また、以前に保存した合言葉を利用者が自由に管理できるように (何を保存したか把握できるように、いつでも削除できるように) するべきです。 但し、何を保存したか把握できるような機能は、同時に、 悪意を持った人がその環境を利用した時に何を悪用できるのか把握できる機能でもあります。 実装においては (ファイル・システムのどこにどう保存するかを含めて) 十分に留意するべきです。

[26] Firefox は合言葉を記憶し、自動補完できる機能を備えていますが、 記憶された合言葉は、「マスターパスワード」を設定しない限り平文で保存され、 設定画面でも表示することが可能なため、注意が必要です。

関連

[4] type 属性の既定値は text です。また、多くの UA は type 値を認識できない (未対応の値が指定された) 時には text と見なして処理するようです。

[5] 同じ文章入力制御子として、 type が text の入力内容を隠さない単一行入力制御子があります。

入力内容を隠さない複数行入力可能な textarea 要素による制御子はありますが、複数行入力可能で入力を隠す制御子はありません。

メモ

[16] 利用者が要素を活性化すると (焦点をあてると)、入力欄は編集可能な状態になります HTML 4 17.11.2。

[32] Windows XP のログオン画面の合言葉入力欄は CapsLock が有効だとバルーンが出て教えてくれます。こういう配慮があるといいですね。

[33] IRC logs: freenode / #whatwg / 20100319 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20100319#l-856

[34] WebサイトにXSS脆弱性があった場合にブラウザのパスワード保存機能で保存したパスワードを読み取り可能かどうか - 金利0無利息キャッシング – キャッシングできます - subtech ( ( 版)) http://subtech.g.hatena.ne.jp/mala/20110428/1303982930

[35] [whatwg] password-related feedback on forms ( ( 版)) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035671.html

[36] IRC logs: freenode / #whatwg / 20120726 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120726#l-710

[37] ncsa-mosaic/CHANGES at master · alandipert/ncsa-mosaic ( ( 版)) https://github.com/alandipert/ncsa-mosaic/blob/master/CHANGES#L443

[38] [webappsec] Rechartering: Write-Only Form Elements ( (Brad Hill 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0124.html

[39] CREDENTIAL: Drop write-only, as the WG decided against. · c9aa66f · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/c9aa66ff02d0896b56170531f2ed0b0813462597

[40] IRC logs: freenode / #whatwg / 20110616 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110616

[41] ログインフォームが含まれる非 HTTPS サイトは安全でないと表示されます (影響あり) | Firefox サイト互換性情報 ( 版) https://www.fxsitecompat.com/ja/docs/2015/non-https-sites-containing-login-form-will-be-marked-insecure/

[42] 1179961 – Use a lock with a strikethrough for HTTP pages that have Password Fields in the Control Center ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1179961

[43] 1188121 – [userstory] CC: Warning for password on non-secure connection ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1188121

[44] Avoiding the Not Secure Warning in Chrome  |  Web  |  Google Developers () https://developers.google.com/web/updates/2016/10/avoid-not-secure-warn

To ensure that the Not Secure warning is not displayed for your pages, you must ensure that all forms containing <input type=password> elements and any inputs detected as credit card fields are present only on secure origins.

[45] malaさんのツイート: "東大、この状態で野良アプリ危険とか言っててマジで養豚場か https://t.co/zj7pPclJ8e → https://t.co/NJIYJaTA4v → https://t.co/enaZQcQklQ" () https://twitter.com/bulkneets/status/855331694366171136

[46] No More Passwords over HTTP, Please! | Tanvi Vyas () https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/

[47] Communicating the Dangers of Non-Secure HTTP | Mozilla Security Blog () https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/

[48] 25239 – autocomplete fields: mechanism to prevent saving fields after form submission () https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239

[49] Release Notes for Safari Technology Preview 46 | WebKit () https://webkit.org/blog/8042/release-notes-for-safari-technology-preview-46/