  |
はてなキーワード: パスワードとは
当方、企業研究所勤めのアラサー世代(夫婦のみの世帯。共働き)。周囲に貯金ゼロ勢とマンション買った勢しか可視化されておらず、この世代の平均的な収支と今後のための投資計画が知りたかったので、まず自分が書いてみることにした(収支は私の分のみ掲載)。匿名のほうがblogよりも広まりやすい話題だと思ったので。
2016年の収支は大まかにはプラス100万だった(後述するが、プラスの分はほとんど投資に回される)。傾向としては毎月収支が平均プラス5万程度で推移して、ボーナスなどを含めて最終的にプラス100万という感じ。去年も計算したが、ほぼ同額だった(給料は上がっているはずだが、収支は変わらずで少し悲しい...)。現在の貯金額は350万程度。使いまくっているわけでもないが、切り詰めまくっているわけでもない。欲しい服を気の向いたときに買ったり、PSVRを勢いで買ったり、年に2回くらいは旅行に行ったりしている。院卒なので、働き始めて3年くらいしか経過したが、自分の収入と支出がどれくらいで、一年の終わりには収支がこれくらいになるというのが掴めてきた。ちなみに、学部と院で奨学金を借りていたため、毎月2.8万ほど返済を続けている。返済完了まであと10年くらいかかりそう...。
なお、収支の計算をレシートから記入しているととてもやる気が持たないので、moneyforwardを自分は使っている。ほぼ全ての口座をmoneyforwardに登録し、毎日のコンビニやスーパーでの買い物もクレジットを使っているので、レシートから入力する手間はかなりかからなくなっている(ゼロではないが...)。使途不明金も年間3万もいかないので、ほぼ確実に自分の収支に関してはトラッキングできていると思う。こう書くと頑張っているっぽく見えるけど、いかに頑張らないで継続的に収支をトラッキングする仕組みを整えるかを考えていたら、自然とこうなった。
moneyforwardに口座のあれこれを預けるのはどうなのかというのはよく聞かれるが、自分の収入や支出がいったいいくらかも分かっていない状態で5年も10年も生きているほうがよっぽどリスキーだと思ったので登録している(働き始めた最初の年の自分もそうだった。あれを続けていたらと思うと恐しい...)。閲覧のパスワードと実際の取引のパスワードが分かれているところも増えているので、どんどんそういうのが普通になっていって欲しい。
毎年100万貯金していくと65歳には4000万程度貯まっていると思うが、夫婦で老後をそれほど不自由なく暮らすにはいくら必要かを本を読んで計算してみたところ、7500万程度必要ということが分かった(90歳くらいまで生きるという想定)。年収はそんなに上がることは期待しないほうがよさそうだし、かといって直近の生活も切り詰めたくない...。そんなわけで数年前から確定拠出年金とインデックス投資を始めている。1年に100万の投資を3.5%程度で運用できると65歳には7500万を越えていそうなので、3.5%運用を目指す。
確定拠出年金は老後まで引き出せないというデメリットもあるが、節税効果(掛金/運用益が非課税)が圧倒的に大きいので、老後への投資を考えるならやっておいて損はないと思っている。私の場合は企業型確定拠出年金だったので、限度額の5.5万を毎月回している。残りはNISA(こちらも運用益が非課税)に回していて、株式と投資信託に回している。個別銘柄を選んでいると日々落ち着いて生活できないので、インデックス投資をしていて、選ぶやつも運用コストが低いものを重視して選んでいる。日々の株価の変動で売買したことはなく、buy and holdでやっている。株式と投資信託はリスク運用マネーなので、一年で価値が最悪1/3くらいになるような自体があっても死なずに生活していけるように、国債も一緒に買うようにして、自分が許容できるリスクを満たしながら、3.5%運用を目指して頑張っている。頑張っているといっても年始にNISAの分投資して、後は放置しておくだけだが...。
日々こんな感じで収支を振り替えったり、投資計画を立てたりしているわけだが、同世代の他の人がどんな感じでやっているかを聞けるとうれしい。
日本は仕事の効率が悪いって言われることについて思ってることを殴り書きしてみた
これはよく言われることだけど普通の国なら電子化によって効率化して仕事量は減る
本当なら電子化するときに紙では必要だったけど本質的に必要じゃ無いものは削ったり
電子化することで自動化できる部分に関しては省略したりする必要があった
ただ特に大企業の人間は「もしかしたら必要かもしれない」という恐怖心に勝つことができず
成功はないけれど失敗もない「ただ紙でやってた業務をデジタル化した」だけに留めてしまった
さんざん議論して効率化するために導入したはずなのに大半の大企業は完全に電子化されてなくて
一部は印刷して手書きのサインが必要だったり領収書は原本を貼り付けないといけなかったり
別に法律で決まってないけど念のため紙で印刷して保存してたりする
日本人はハイコンテクストで会話するもんだからそういうルールは明文化されていなかったりして
新しい作業をするときに何をすればいいのかを調べるのことに凄く時間がかかる
紙でやってた処理をデジタル化しただけなので
本来はデジタル的に入力させる項目もExcelに入力させてそれを電子ファイルとして保存するというアホなことをやってる
Excelの場合は入力するときにセルをはみ出ないか気にしたり入力値が間違ってないか別のファイルを参照にしながら確認したりして
紙に書くより時間がかかってるのでは？ということもある
紙管理していた頃は棚を探せば紙が出てきたけど
フォルダの奥底にある場合があってそうそう発見できないので逆に時間がかかる
部署毎にコピーを持ってたり過去のデータから様式を持って来たりすると
実は様式が変わってたりして二度手間になってまた余計な時間がかかる
「慣れてくれば早い」
という日本の古来からある謎の文化のせいで時間が経てば職人的になって効率も上がってくるんだけど
一方で人事異動システムは残ってるからその職人もいずれいなくなる
そして異動先では別のシステム・ファイルサーバが動いていたりしてレベル１からやり直し
異動元では職人がいなくなったことで効率が下がり無駄な稼動が発生する
これらに加えて海外企業（特にIT系）やベンチャー系は電子化に強いので
という感じになってみんなひたすらパワポと睨めっこ
そりゃみんな細かいところに突っ込んだり議論が二転三転したりして全然終わらない
偉い人の会議にかける前に事前チェックをする会議を開いてそこでチェックをする
暗号化＋ネットワーク越しのせいで一つ一つの作業にストレスが溜まるし
メールがこれだけ危ないって言われてるのに他のメッセンジャーアプリは導入できず
ファイルを暗号化してパスワードを別に送るという謎セキュリティのせいで
そんな雑務を高い給料払ってる正社員にさせるのはもったいないので
コンプライアンスとか請負法とか言い出してそっちの管理をするために余計な稼動が発生
再発防止の水平展開とか言い出して二重・三重のチェックをやりだす
電子化をやり直すために新しいシステムを入れようとするんだけど
前述の通り日本人はハイコンテクストで会話するから本当に必要な業務っていうのを抽出しにくくて
だいたい新しいシステムは何かが足りなかったりする
最近言い出したのが
「社内システムはDevOps！」
って奴で要は内製とかもして自分たちで良くしていこうっていう動き
とはいえプログラム書けるやつは大企業に見切りをつけて外資・ベンチャーに移ってるし
まともに書ける人間が残ってるとは思えないからこれも上手く行かないと思う
やるなら新入社員に美味い餌をぶら下げてプログラム書ける奴をバンバン採用するとこからじゃないかな
来てくれるかどうか分かんないけど
テキストエディタが秀丸推奨。というかエディタに金を出してくれない。
OSSのエディタが増えてきたにも関わらず、意識低いので秀丸メインが多い。
前述の通りようやくSVNが導入されたけれども、Githubの提案は「英語で使いづらい」という理由で却下。
総務だろうと何だろうと全社員がrootで見ようと思えば見られる状態。
性善説に頼りすぎだろ。
ReactやAngularJSといったモダンなものは難しいという理由で俎上にすら乗らない。
既に開発が打ち切られたjQueryプラグインなんかを当たり前のように使う。
当然開発が打ち切られてるもんだから最新版のjQueryでは動かない。
結果、特定プラグインを動かすためだけに複数バージョンのjQueryを読み込ませたりする。
にも関わらず「何で遅いのか」と問題になったりする。
コード見ろよ。
Slackやチャットワークはおろか、Skypeなども使われていない。
受信するメールの量が多いため当然取りこぼしも増える。
当たり前のようにIE8対応が仕様書の必須要件に含まれている。
最新ブラウザ以外の対応に別料金でも取ればむしろ工数と金になるものを、無知なので最低要件に含めてしまう。
何度言っても理解しない。
もちろん、別にこれがダメってわけじゃない。いやダメなのもあるけど。
「これ使えてるだけまし」って人もいるかもしれない。
ただ、数え役満っていうのかな、技術力の低さがインクリメントされていって、現状の「技術に明るくない我が社」を作ってるように思う。
自分が少しずつ会社を変えていけばいいのはわかるけど、決定権持ってる人間が技術に明るくないと、枯れた技術がいよいよ朽ち果てる寸前まで現状をよしとする。
それが、うちの会社。
気がついたら「まともな技術持った人」が全員辞めていた。
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か？主語が全部theyという支離滅裂な英語なんだが。
----
TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。
以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。
TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。
TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。
そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。
TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。
TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
Analysis Whitepaper:
http://ieeexplore.ieee.org/document/7467371/
Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/
これ読んで思い出したのだが
ログインは６桁数字のIDに任意のパスワードだったのに、EメールアドレスのID利用に変更
それでも自宅PCや自分のスマホなら１度入力すれば記憶しているのでそこまで困らない
他人のIDが残ると困るから、ブラウザ記憶できないようになってる
そりゃもちろんセキュリティ上しかるべきだけど、それでぽちぽちEメールアドレス入力してまでログインするかっての
結局iPadはただの置き物になった
以前ならクラス受講後の休憩時、次の予約でもするかと予約用iPad使うこともあったけど
今となってはめんどくさいので自分のスマホでやろうと思ってしまう
館内で予約する人はカウンターのお姉さんに口頭で頼んでるようだ
同居人と外を歩いていた
某携帯電話キャリアのお店の前を通りがかったら、同居人が店の前の立て看板に反応した
「ちょっとこれ見て！これに入るとスマホでネット使い放題なんだって！パケット制限ないんだって！」
俺は同居人の意図をはかりかね、「ふーん」と流したが、なぜか同居人は食い下がった
「これ入ろうよ。私のスマホいつも十日くらいで制限されかかっちゃうし」
「だからこれに加入しようって言ってんじゃん！あなただってスマホとタブレット気兼ねせずに使いたいでしょ？」
ここでようやく俺は状況を理解した
「この光回線ってのは、うちはとっくの昔に加入してるんだよ。お前が俺の家に住み始める何年も前から」
「そりゃそうだろうな。昔うちの無線LANにお前のスマホ繋いでやろうかって言ったら、お前『絶対にイヤ』って断ったし」
「え、じゃあ私が悪いってこと？」
「まあそうなんじゃねえの？」
「信じらんない！あたしが今までずっと困ってたのを知らんぷりしてたのに？」
「お前が自分で断ったんだろ」
「教えてくれなかったじゃん！」
「知ってるから断ったんだと思ってたわ。つかなんで知らないのに断ったんだ？」
「そんなの今言われてもわかんないよ！」
「あ、そ」
「…どうしてそんな意地悪するの？私何かした？」
「逆、逆。お前が今困ってるのは、やること何もやってないから」
「ひどいよ。こんなのってあり？」
「知らんわ。でどうすんの？うちの無線LAN繋ぐの？」
「ダメなんじゃねえかな」
「どうして！」
「うちにもうあるから。同じ部屋に同じ回線を二つ以上契約ってできなかったような気がする」
「じゃあどうすればいいのよ！」
「じゃあそれやってよ！」
「えっ」
「イヤか？」
「それは、ちょっと」
「一応言っておくが、スマホにさわらずにうちの無線LANに繋ぐ方法はないからな」
「それは、やだ」
「じゃあ自分で設定するか？SSIDとパスワードなら教えてやるけど」
「そんなのいきなり言われてもわかんないよ！どうにかして！」
「O☆TE☆A☆GE」
「…もういい！」
こんなんでよくもまあ二十年以上生きてこられたな、と
「小さなショップ」と書くぐらいだからECサイトをスクラッチから作る規模だとコストがあわないだろうし、WordpressかEC-CUBEベースじゃない？
中規模以下でECサイトを自社スクラッチって聞いたことないし。
だとするとパスワード書いたファイルの場所は攻撃する側は知ってると思うよ。
うーん。それはどうかなぁ。
ログファイルは場所やファイル名が分かりやすいから最初にみられやすいけど、
DBへの接続パスワードが書かれたファイルはかなり探さないと見つからないじゃない？
最近はソースコードを直接見られないように暗号化している案件も少なくないし。
そもそもだけど、サーバのログにアクセスされてる時点で、クレジットカード以外にも情報漏洩してない？
書いてある内容だけだと詳しいことはわからないけど、
ログ見える状況だとすると攻撃者はファイルにはアクセスできてるんだよね？
ってことはきっとDBへの接続パスワードも見えちゃってるだろうしDBへもアクセスされちゃってない？
自分が攻撃者側だとするとログからクレジットカード情報さがす前にDBから個人情報抜くと思うんだけどな。
ようするにこのECショップはサーバにアクセスされてログから最低でもクレジットカード情報、
副業として始めた個人事業が軌道に乗ってきたので、調子に乗ってビジネスカード（クレジットカード）を作ってみた。
んが、まさかのネット未対応で、ご利用明細は紙（郵送）のみでオンラインで見れないわ、本人認証サービスも使えないのでオンライン決済できないわ、なんだかがっかりでした。
以下、顛末。
いままでも個人事業に使うものを個人のクレジットカードで買ったりしていたけど、
だんだん管理がめんどくさくなってきたので、事業用のクレジットカードを作った。
作ったのはポケットカードの「P-one Business MasterCard」
決してステータスの高いカードではないが、年会費が実質無料だし、どうせネット決済ばっかりで人前で見せびらかすわけでもないしと思って、申し込み。
申し込みの翌日には仮審査に通ったと電話があり、そのまま電話で事業内容や利用希望額を聞かれ、本審査に回す旨を伝えられる。
本人確認書類や確定申告書、青色申告決算書などを郵送して、２週間後ぐらいにはカードが簡易書留で到着。
さっそくオンラインで明細を見られるように登録をしようとしたけど、カード番号を何度入れてもエラー。
イヤな予感。
コールセンターに文句言れる前に、ちょっと冷静になってwebページを見なおしてみる。
んで見つけた。
-----
※7 ネットカウンターのご登録・ご利用は、法人代表者様のみ可能です。
-----
むむ。。。
このビジネスカード、実は「法人代表者用」「法人従業員用」「個人事業主用」の３種類があって、俺が申し込んだのは「個人事業主用」。
んで、ネットカウンターというカード会社のオンラインサービスが使えるのは、「法人代表者用」だけだという。。。
こんな注意書き、今更気づいても遅いわ。
クレジットカードの明細をオンラインで参照して、そのまま会計ソフトのMFクラウド会計にデータ取り込んで経費精算＆記帳まで一気通貫でやろうとしたのに。。。
うへぇ。。。紙の明細見ながら内容を手で打ち込むのかよ。いつの時代だよ。非人道的な作業だ。
コールセンターにもダメモトで聞いてみたが、やっぱり個人事業主用カードはネット未対応とのこと。
今後の予定も未定とのことなので、「ぜひ対応するよう上の方にも伝えて下さい」と丁重に言って電話を切った。
カードの利用明細の手入力ぐらいなら我慢できるけど（それすらも、カード利用明細をスキャナで読み込んでOCRかければなんとかなるか？）、
痛いのはオンラインでの本人認証サービスにも対応していないこと。
近頃はクレジットカード決済のセキュリティ強化のため、カード番号や有効期限に加えて、カード会社に登録したパスワードが必要なオンラインショップ・決済会社も多い。
だけどそれも使えないってさ〜。ほんとがっかり。
まぁAmazonとかPaypalは本人認証サービス使ってないから大丈夫そうだけど、今後「いざっ」ってときに本人認証サービスが使えなくて悲しい思いをするんだろうなぁ。
