[1] HTML の type が password の
input 要素は、単一行文章入力制御子を定義します。
この制御子では、入力された文章は隠されます。
[2] 仕様書:
INPUT element
<IW:HTML4:"interact/forms.html#edef-INPUT">| 属性名 | 属性値 | 既定値 | 説明 | 出典 | |
accesskey | %Character | [HTML 4] | |||
align | 配置 | [HTML 4] 非推奨 | |||
autocomplete | | 自動補完 | 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+ | |||
maxlength | NUMBER | 最大長 | [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 | |||
tabindex | NUMBER | タブ順 | [HTML 4] | ||
title | 注釈的題 | [HTML 4] %coreattrs | |||
type | text | text | 制御子の種類 | [HTML 4] | |
value | 初期値 | [HTML 4] | |||
vcard_name | 自動補完 | WinIE 5+ |
現在値は、はじめ初期値です。その後は、利用者が編集した結果が現在値です。
[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>
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/>