私のホームページは、ＣマガジンにURLが載った途端にリムネットのアクセスラ ンキングを急降下した。一体何なのだ(^^;)。(*1) とりあえずABC of Cの再構築 とHTML化を進めているのだが、「すげ〜大変」を実感しているのである。しかも、 カウントを見れば、殆ど誰も参照していないのがもろバレってやつで、こういう のを無駄な努力というのかもしれない。大体、通常電話回線からダイアルアップ で接続してこの手の講座をオンラインで読むというのは回線の無駄である。かと いって、ダウンロードして接続を切ってから読むというのも、そう簡単ではない。 なかなか難しいものだ。
ところで、URLがディレクトリの場合は、最後にスラッシュを付けるのが正しい というご指摘があった。というわけで訂正させていただく。 http://www.st.rim.or.jp/~phinloda/ 、がURLです。これでさらにアクセスが減ったらどう解釈しよう か。
*
FPROGでも誕生日問題が炸裂した。元はといえばFCが発祥の地なのだが、要する
に歳を取るのはいつか、という問題である。FPROGでこの話題をさかのぼると結構
とんでもない所まで源流を遡ることができて面白いのだが、チェックポイントと
しては、私が書いた次のコードがある。
---- list 1 年齢を求める(1)
/* ty年tm月td日に、誕生日がby年bm月bd日の人の年齢 */
age = ty - by - (tm < (bm + (td < bd)));
----
これに関して「例としては最悪かもしれない」と説明を付けているのだが、実
はFC（C言語フォーラム）の初心者質問コーナーで年齢計算を質問した人がいたの
で、それに回答するために考えたのだ。ただし、そちらでは、List2のように回答
している。最初のコードは初心者には見せない方がいい類のものだと思ったらし
い。FPROGに書いたのは、そこが「Software Fools (ソフトウェア無作法)」とい
う会議室だから。無作法で構わないのである。処理は何の変哲もないもので、ま
ず年を引き算して、誕生日の月が来ていなければ１を引く。もし月が同じなら、
誕生日が来ていなければ、１を引く。List1は比較演算の結果が0か1になることを
利用しているだけだ。
---- list 2 年齢を求める(2)
age = ty - by;
if (tm < bm) {
age--;
} else if (tm == bm) {
if (td < bd)
age--;
}
----
ところが、「法律では、４月１日生まれの人は、３月３１日の時点で歳を取る
ことになっている」という指摘があったのである。この後は法律解釈論議に突入
して大混乱というか何かよく分からない世界で、とりあえずANSI Cでは定義され
ていないという程度の合意しか得られていない。
これで現実世界の事例と照らし合わせてみると、学校入学の年が参考になる。 よく知られているように、学年の最年長の人は４月２日生まれである。余談だが、 よく「誕生日が４月２日の人が多い」と言われているが、私自身は不思議なこと に４月２日が誕生日だという人に出会ったことがない。それはさておき、なぜ４ 月１日生まれの人が学年最年長ではないのか。
学校教育法第二二条 > (1) 保護者(子女に対して親権を行う者、親権を行う者のないときは、後見人 > をいう。以下同じ。)は、子女の満六才に達した日の翌日以後における最 > 初の学年の初から、満十二才に達した日の属する学年の終りまで、これ > を小学校又は盲学校、聾学校若しくは養護学校の小学部に就学させる義 > 務を負う。(略)「学年」は４月１日から始まり翌年３月３１日で終わることが別途定められて いる。４月１日が誕生日の人は、誕生日が同じ年の３月３１日生まれの人と同じ 学年に入るという事実がある。ということは、「子女の満六才に達した日の翌日 以後における最初の学年」が、同じということだ。つまり、４月１日生まれの人 は、前日の３月３１日の時点で満六才に達したという解釈でなければ説明ができ ない。
ということは、歳を取るのは誕生日当日ではなく、その前日ということになる。 なお、この議論は原稿を書いている時点でまだ錯綜中だ。私にも何が正しいのか よく分からない。
さて、とりあえず現実を踏まえてList1を修正しなければならないが、皆さんな らどう修正するだろうか。私の修正した結果は、List3の通りである。
---- list 3 年齢を求める(3)
/* ty年tm月td日に、誕生日の前日がby年bm月bd日の人の年齢 */
age = ty - by - (tm < (bm + (td < bd)));
----
*
さて、トリは何といってもこれしかないだろう。NIFTY-Serve会員規約が変更さ れて、次の条文が追加された。
>第９条（ニフティによるＩＤの一時停止等） >1. ニフティは別途定める一定期間に会員がパスワードの変更を行なった形跡が認めら > れないと判断した場合、当該ＩＤを使用停止とすることがあり、会員は予めその旨 > を承諾します。この「別途定める一定期間」を公表しないというのである。個人的には「別途 定める」というのは、別の箇所で公表するという意味だと思ったのだが、ニフテ ィに直接問い合わせたから間違いない。理由がものすごかったが、ものすごすぎ るのでここでは書かない。FPROGとかには紹介してあるのでご覧ください。
さて、ということは、結局、この条文によって、会員はいつでもIDを停止され ても文句がないという規約に同意したことになる。いつでも、というのは変だが、 例えば「一定期間」は３秒かもしれないのである。流石に３秒は短いから、多分 ３日あたりかと想像しているのだが。
つまり、NIFTY-Serveは４月から、パスワードを３日変更しなければIDが使えな くなるかもしれない、という状況になったわけで、これは困った話だ。なお３日 なんてのは根拠も何もないというか、単に夢の中のお告げ程度のものなので、念 のため。実際は１日かもしれない。真の期間については私は何等保証しない。ま た、規約では「使用停止とすることがあり」となっているから、必ず停止すると いうわけではないようだ。
で、仕方ないからパスワードを毎日変えることにした。こんなのを毎日やって いれば面倒どころの騒ぎではないので、例によって通信ソフトの出番である。最 初は、パスワードを最終アクセス日時を使ってYY-MM-DDにしてやろうかと思った のだが、流石にこれは「破ってくれ」と言っているようなものだから没にして、 日付の箇所だけを変更するように修正した。
例えば、パスワードとして00shioriと指定する。通信ソフトは、このパスワー ドの中の数字の箇所を調べ、前から２つを、その日の日付に変更し、それを新た なパスワードとしてパスワード変更の作業を行う。つまり、5月18日にアクセスし たら、18shioriというパスワードに勝手に変わってしまうのである。
で、試しに使ってみた。いやパスワードを間違うこと間違うこと。最初のうち は、まさにやってられない状態だったが、だんだん慣れてきたら間違わなくなっ た。考えてみれば、最終ログイン日時は通信ソフトがログで保持しているのだか ら、ログインの時のパスワードも通信ソフトに生成させればよいのである。つま り、最初に現れた２文字の数字は、勝手に最終アクセス日時の下二桁に置き換え て送信してしまえばよいのだ。
これでパスワードを変更し忘れていきなりID停止ということは避けられそうだ が、心配なのはセキュリティである。まず、自由に指定できる桁数は８桁。異様 な少なさだと思う。大昔の、まだUNIXが一般市民（って何だ？）にはとても手の 届かない異次元の存在だった頃、やはりパスワードは８桁までという制約があっ たはずだ。長い年月が経った。それこそ数多くの人がパスワードを盗難されて今 日に至るのだが、この制約は伝統として意外と守られているようである。もっと も、長ければいいなんてものではないが、特に日本のように英語を遣い慣れない 人が多い国だと、英数字で８文字などというとあまり気の利いた単語を思い付か ないのである。すると、名前をローマ字で入れてみたり、電話番号を…というこ とになったりして、ますますパスワードを盗みやすい状況にしてしまうのだ。
せめて２０桁にすればパスワード盗難騒ぎも激減すると思うのだが、少なくと もニフティはそのような対策は取る気が全くないどころか「８桁あれば十分」と 考えているらしい（問い合わせた人からの情報である）。実績があるならまだし も、パスワード盗難事件が報道されてかつ桁数とは無関係と主張するあたりが不 自然だ。８桁のパスワードと２０桁のパスワードを盗む難易度の差は、少し計算 のできる人なら一瞬で理解できるはずである。２０桁にすれば絶対安全とは言わ ないが、安全性は文字通り桁違いなのではないか？
ともかく、この処理を追加したため、有効なパスワードは２桁を日付に使って 残りの６桁になってしまう。使える文字の種類はアルファベットが大文字と小文 字それぞれ２６文字、数字が１０文字、特殊記号が「!"#$%&'()*+,-./:;<=>?@[\] ^_`{|}~」の３２文字だから９４種類である。従って、パスワードを破られる確率 は単純に計算すれば8836倍になってしまうのだが…ＩＤをいきなり止められては たまらないので、多少の危険は仕方ない。しかし危ないな、これは。
ちなみに、私はパスワードを変更しないタイプである。今回のようなことがな ければ、パスワードはまず変更しないから、５年以上そのまま、なんてのがごろ ごろしている。パスワードを盗まれたことは一度もない。辞書にない単語を組み 合わせて使えば、８桁といえども、そう簡単に破れるものではない。桁数を増や さない主義ならば、せめてパスワード入力時に、辞書にある単語と数字の組み合 わせだと許可しない、といったチェックを行うシステムにしてはどうだろうか。