8.7.3.10と8.8に任意のコードを実行される脆弱性が存在する。「ユーザIDは8文字以内の英数字にすべし」というのが暗黙の考え方としてありました。運用している所をよく見ました。近年は、ユーザIDもパスワードも管理方法が複雑で、そのポリシーも複雑で統一性がないのでID管理に複雑な機能が要求されます。文字で、実質8バイト、というのがヘッダファイルのソースでは宣言されており、一応それが「暗黙の決まり」となっているようです。化けてしまうと言った問題もでてきます。アカウントと連動するアプリケーション側が、古い標準に従って8文字に制限している場合もあるので「システム的には管理運用上ユーザアカウント名は8文字以内」が無難であると考えます。バイトでハードコードされているようで、デフォルトでは、ホストのユーザアカウントを参照するのですが、ユーザ名とパスワード自体が別に管理されているので、システムにログインしなくても使えるわけです。ユーザアカウント文字数の最大長は20文字でした。20文字なので、恐らく最大20文字の制限は引きずっているでしょう。場合も20バイトの様です。文字列が使えないってのもなんだか笑わせられます。時代を知らない、若い方々には訳が分からないでしょう。こんな制限は古いシステムでも、最新のシステムにも制限があるのですね。文字間にドットが入っても問題ない様です。ユーザフォルダ名は5文字にトランケート(丸めて短くされる)されます。そのため、5文字を超えるユーザアカウントのホームフォルダに何かアプリケーションでアクションを行う場合、ユーザアカウントを参照するソフトウェアが5文字を超えると「色々と楽しくて痛ましい事故?」が起こるようです。\\nas\backupなどとバックアップ用のバッチファイルを書いてユーザに配布すると失敗する訳です。文字になっているのですが、なぜなのか分かりません。文字、@以前の、いわゆるローカルアカウント部分は最大64文字です。ローカルなアカウントの部分はドット、ハイフン、アンダースコアは利用可、ただし一番先頭と末尾、連続する事はできません。RFCでは他の特殊文字も使える様ですが、契約先のISPや携帯メールとか、レンタルしたメールサーバー、メーラー(クライアント側)の制限により、その限りではありません。制限がかかっている場合があります。)では、ローカルホスト内でメールが使えればよかったので「ログイン名=メールアドレス」です。今時はホスト外にメールを送るのが当然です。エイリアスを使っているので、ほとんど問題にはならないでしょう。管理上面倒と言えば面倒です。バイトまで許容しています。そのもの自体に制限は無いようです。万物共用の命名規則として通用するわけです。ログインや動作で問題が起こります。互換性のため、特殊文字にドットは使えません。コンテナ区切り文字です。特殊文字はハイフンだけ許可されます。カンマや@が入っているとURLと間違えられ問題があるからでしょう。メールアドレスのローカル部分になります。系システムであれば、大文字小文字はケースセンシティブなので、アカウント名に大文字小文字を混在させるのは好ましいものではありません。系システムではケースセンシティブではありません。管理を一般化した場合、一番確実なユーザ名を決めるネーミングスタンダード(命名規則)構築方法でしょう。セキュリティ上、ユーザ名もパスワード同様に長ければ良いというご意見もありそうですが、、まずアカウント名を解析してからのパスワード解析はクラックするにはちょっと実際の現実感がありません。手元にアカウントリストとハッシュ化されたパスワードリストがあってこそクラックし甲斐があるでしょう。-後に述べる「同姓同名問題」を解決させるため、8文字目は丸めて最大7文字とします。8文字使う場合は特例とします。短くなるのは構わないとは思いますが、必要に応じて文字を追加して6文字以上(tsuurrk)にする、と言った方法も良いと思います。8文字以上のIDを要求する場合、長ければトランケートして8文字に抑え、短すぎる場合、規則に従った文字列を加えると良いでしょう。2バイト文字や特殊記号の利用は厳禁、特別に許されても”-”ハイフン位にしておきます。文字も検索のスクリプト条件で使われる可能性があるため、好ましいとは言えないという意見もあります。-大規模な組織では、エンドユーザは相手のファーストネームを知らない事がほとんどです。したがって、ファミリーネームに識別子としてファーストネームのイニシャルを添付します。ファーストネームのイニシャルを1文字加えて「同姓異名」を区別します。イニシャル+ファミリーネームを使うところがありますが、本人や周囲の人には暗黙の了解ですが、初めて会ったあなたにメールで返事を書きたいと言った場合、ファーストネームを思い出せる人は少ないものです。ファミリーネームを優先的に使った方が良いでしょう。ファーストネーム+イニシャルがダブる場合、後で追加するユーザは、ファミリーネームを一文字削除して、イニシャルの次の子音を一文字加えるのが一つのアイディアです。nakaknjという感じです。-よくある例として、社員番号をユーザ名としている所がありますが、最悪の選択です。社員番号と「ニンゲン」を結び付けてモノゴトを考えられるのは本人と、人事担当だけです。間違っても派遣で来ているヘルプデスクさんや、ログ管理をしている外注さんにはわかりません。ログイン名は「ヒト」をちゃんと認識できる何らかの符号が必要です。これで例外があっても8文字に収まります。ここで上の例で最悪だと断じた社員番号の下2桁を使うのも一つの手段でしょう。-普段あまり意識しないのですが、日本語のユーザ名をローマ字化するための方法として、ヘボン式ローマ字と訓令式(日本式)ローマ字の二種類があります。一般的にパスポートなどの人名表記はヘボン式を基本としているので、ヘボン式に統一すべきでしょう。ヘボン式ローマ字綴方表http://www.seikatubunka.metro.tokyo.jp/passport/documents/0000000485.htmlまた、外国人の場合、帰化しない限り日本の戸籍名がないので、原則として「通称」を使うことになります。その際も母語のスペルを使うのが原則でしょう。なってはいけないわけです。母語がアルファベットで表記できない場合もあるので、その例外措置も考慮すべきです。例外規則に命名規則+「本人の希望」というものがあってもいいわけです。条件の最大公倍数で禁忌とすべきです。パイプに相当するためやめた方がいい。特殊なデバイスを意味するユーザIDもやめるべきでしょう。ファイル名は使えません。ユーザアカウントはバッチやシェルで処理する場合もあるので、これらの全システムで禁忌文字は最大公約数として、使用してはいけないと思います。文字列一括変換などのプログラムやシェル、バッチ処理で問題になるようです。たしかに「特殊文字が使えるシェルの書き方」というのがありますが、メンドクサイので禁忌文字とした方が無難でしょう。当たり前ですが機種依存文字(○付数字やカッコつきの「株」「〒」)とかを含め、「ソ」「申」「表」などのシステム依存のいわゆる「5C文字」を含む。すべての漢字を含め2バイトの文字は使うべきではありません。正しい日本語処理を行わないと想定外の動作をするアプリケーションやシェル、バッチファイルがあり得ます。条件で絞り込んだ最小公約数として命名規則に加えるべきです。-主に姓が変わるのは、お年頃の女性が多いと思いますが、男性でも次男坊、三男坊が一人娘を娶った場合なんかは、戸籍上「婿入り」するわけで、そのような場合はどうするのかという事も決めておかなければなりません。ユーザID=戸籍名なのか、ユーザID=通称名とするかですね。「ユーザID=戸籍名」で、メールアドレスを決めてしまうと、幸か不幸か何度も結婚を繰り返しちゃった女性(男性も)、メールアドレスが頻繁に変わるわけですから、あまり好ましいものとは思えません。本籍名を使うのか、通称を使うかの判断は「本人の希望があれば」認めるべきですが、業務上「頻繁に変更できない」というルールが必要です。-忘れてならない事は、このような運用ルールを文書化し、担当課長のハンコを貰って、オーソライズしてもらう事です。後任者が誤って8文字以上のユーザアカウントを作ってトラブルって、後で仕様変更するような目にあっても、それはルールを超えた例外処理として余分な出費を認めてもらう十分なりゆうになるからです。-命名規則は文書化して、認印(ハンコ)をもらってオーソライズしておくこと。--とまぁ、書いてみた訳ですが、実際に古くから運用しているディレクトリサービスで暗黙に8文字運用している現場で、たまたま9文字のユーザアカウントを作ってみると、システム全体に影響がでる現行システムの古い仕様上の互換性との問題点というのが見つかりました。新規登録のルーキーユーザなので、8文字に短くして問題が解決しています。文字英数子文字」をネーミングスタンダードのサンプルにしているので、どのシステムアカウントもこの文字数に従う事が無難です。アカウントを8バイトで確保するのは難しいので、一般的なインターネットサービスではあまり問題にならないかも知れません。ウェブサービスの一部では、やはり文字数の制限がある訳でして、最低限8文字以上が必須だったりしますし。”8文字”(以下)が無難だ、というのはどこでもあり得る話なのです。ブルートフォースアタックかける場合、組み合わせは事実上無限なので、総当たり戦ではあまり関係ない、と思うのは私だけでしょうか。ユーザのログインIDの文字数を調べてみると色々なことが解って勉強になりました。最低の「短過ぎるユーザIDは何文字が許されるか」も併せて調べるともっと面白いかも知れません。ログインできなくなりました。様から送り付けられ、通りにやったらログインできなくなってしまったという事。「有効」に設定します。アカウントのパスワードを設定します。マスターパスワードを問われるのでマスターパスワードで認証します。ログインできるようになりました。アプリケーション」の信頼関係、を作り出す仕組みだそうです。マスターパスワードを要求するようになりました。