タグ付けされた質問 「security」

システムのユーザー識別/認証プロセスについて誰か（クライアント）と意見の相違があります。それの要点は、各ユーザーにグローバルに一意のパスワードを持たせることです（つまり、2人のユーザーが同じパスワードを持つことはできません）。私はこれに対する明白な議論をすべて排除しました（セキュリティの脆弱性であり、認証と認証を混同します、それは無意味です）。 私はこれについて権威のある（または半権威の、または独立した）意見を探してさまざまなGoogle検索を行ってきましたが、何も見つけることができません私が知る限り）。誰も私にそのような独立した意見を指摘できますか？ [編集] すべての回答に感謝しますが、この提案されたアプローチ/要件の問題をすでに理解しており、クライアントに説明することさえできますが、クライアントはそれらを受け入れません。 。 私はまた、デイリーWTFの記事を見つけたと思いますが、それはジョン・ホプキンスが指摘しているという問題がある-これは、それは価値が説明するように見えるしないように自明WTFであることを理由。 そして、はい、パスワードはソルトおよびハッシュされます。その場合、グローバルな一意性を確保するのは難しいかもしれませんが、それは私の問題を解決しません-それは単にクライアントが先に進まないという要件があることを意味します。実装します。そして、「塩漬けやハッシュに悩まされていません」と言う立場にいたら、「グローバルに一意のパスワードを実装していない」と言う立場になります。 なぜこれが悪い考えであるかについての独立したおよび/または権威ある情報源へのポインタは、まだ感謝して受け取られています... [/編集]

20 security  passwords 

セキュリティリスクが中〜低のアプリ（つまり、バンキングアプリなどではない）のログインを作成する場合、ユーザーが入力したパスワードを次のように入力するだけで検証できますか。 if(enteredPassword == verifiedPassword) SendToRestrictedArea(); else DisplayPasswordUnknownMessage(); 効果的であるように簡単に思えますが、それが必要なすべてであるかどうか私は確かに気にしません。ユーザー名とパスワードのコンボを簡単にチェックするだけで十分ですか？ 更新：特定のプロジェクトはたまたまWebサービスであり、検証は完全にサーバー側であり、オープンソースではありません。ドメインは、これに対処する方法を変更しますか？

20 security  passwords  validation 

この興味深い質問を読んだ後、必要な場合にどの安全でないハッシュアルゴリズムを使用するかについて良いアイデアがあると感じましたが、代わりに安全なアルゴリズムを使用する理由はわかりません。 それで、違いは何ですか？出力はハッシュされたものを表す単なる乱数ではありませんか？一部のハッシュアルゴリズムを安全にする理由は何ですか？

19 security  hashing 

ここで何が求められているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 7年前に閉鎖されました。 ELSEコンストラクトを使用することによって引き起こされるバグに頻繁に出くわします。主な例は、次のようなものです。 If (passwordCheck() == false){ displayMessage(); }else{ letThemIn(); } 私にとってこれはセキュリティの問題を叫ぶ。passwordCheckがブール値である可能性が高いことは知っていますが、アプリケーションのセキュリティを設定しません。その文字列、intなどの場合はどうなりますか？ 私は通常ELSE、の使用を避けようとし、代わりに2つの完全に独立したIFステートメントを選択して、期待するものをテストします。それ以外はすべて無視されるか、具体的に処理されます。 確かに、これはアプリに入るバグ/セキュリティ問題を防ぐためのより良い方法です。 どうやってやるの？

18 self-improvement  programming-practices  security 

HTTPヘッダーでJWTトークンを使用して、リソースサーバーへのリクエストを認証しています。リソースサーバーと認証サーバーは、Azureの2つの独立したワーカーロールです。 トークンにクレームを保存するか、他の方法で要求/応答に添付するかについて、思いを固めることはできません。クレームリストは、サーバー上のデータへのアクセスだけでなく、クライアント側のUI要素のレンダリングにも影響します。このため、サーバーで受信したクレームが本物であり、リクエストが処理される前に検証されていることを確認したいと思います。 クレームの例：CanEditProductList、CanEditShopDescription、CanReadUserDetails。 JWTトークンを使用したい理由は次のとおりです。 クレームのクライアント側編集に対するより良い保護（クレームリストのハッキング）。 リクエストごとにクレームを調べる必要はありません。 JWTトークンを使用したくない理由： 次に、認証サーバーはアプリ中心のクレームリストを知る必要があります。 トークンは、ハックエントリの単一ポイントになります。 JWTトークンはアプリレベルのデータ用ではないことをいくつか読みました。 どちらにも欠点があるように思えますが、これらの主張をトークンに含めることに傾倒しており、これを以前に扱った人によって実行したいだけです。 注：すべてのAPIリクエストにHTTPSを使用するため、トークンは「十分」に安全であると思われます。私はAngularJS、C＃、Web API 2およびMVC5を使用しています。

18 security  http  authentication  authorization 

私はこの答えを読んで、パスワードをメールで送信しないことを主張するコメントを見つけました： パスワードをメールで取得できないようにする必要があります。これは、パスワードがどこかにプレーンテキストで保存されていることを意味します。リセットのみが必要です。 これにより、[パスワードを忘れた場合]オプションを処理する問題が生じます。 ユーザーがそれを読むことができるように、どんなUIでも生のパスワードを表示する必要があります。「パスワードを忘れた」を処理する方法は何でしょうか

18 programming-practices  security  email  passwords 

私は最近、数年前からアカウントを持っていた政府のサービスを使用しました。サービスのパスワードを思い出せなかったので、「パスワードを忘れた」リンクを使用し、この政府のWebサイトが私のメールアドレスにプレーンテキストでパスワードを送信したことに驚いた。 私はユーザーパスワードの処理方法を個人的に認識しており、フィードバックフォーム（これは政府のWebサイトです。ほとんどの人は、すべてに同じパスワードまたは少数のパスワードを使用します（私は知っています）。彼らは単に、「省はパスワード情報を保護するために必要な措置を講じており、適切な暗号化を行ってパスワード情報を保存している」と安心させました。 「私にパスワードをメールで送ることができれば、明らかに必要な措置を講じていません」と言いたいのですが、失礼になろうとはしていません。とにかく私が何を意味するかを知っている誰かに連絡してください。 だから、「（公式のセキュリティ標準）に従って必要な措置が講じられていない」と述べたいと思います。OWASPをすばやく検索しましたが、プレーンテキストストレージに関する記事しか見つかりませんでした。 取得可能なパスワード情報の保存を禁止する（おそらくそう思うと思われる）ユーザーのパスワード処理に関するセキュリティ標準はありますか？さらに良いことには、銀行や政府のWebサービスなどの機密情報を扱うWebサイトが従わなければならない標準がありますか？ おそらく何も変わらないことは知っていますが、IMOを一撃する価値はあります。

17 security  standards  passwords 

私が働いていた会社の場合、ソケットレシーバーを実装する必要がありました。ソケットレシーバーのほとんどは、特殊なセンサーハードウェアからローカル接続を介してUDP形式でデータを取得していました。問題のデータは整形式のUDPパケットでしたが、興味深いことに、データペイロードは常に残りのデータを使用して形成されたCRC16チェックサムで終了しました。 私は仕様に従ってチェックを実装しましたが、これが必要かどうかはいつも疑問でした。結局のところ、UDPプロトコル自体は16ビットCRCを伝送していませんか？したがって、UDPパケットは失われたり順序が乱れたりする可能性がありますが、OSのプロセスに到達する前にネットワークハードウェアによって破棄されることなく破損することはできないという印象を受けました。または、私が見逃している特別なユースケースがありますか？ 私が防衛産業で働いていたことは付け加えておく価値があります。想像できると思いますが、これはこのようなことすべてについて超明示的であることが好きなので、単なる「セキュリティOCD」のケースであったのかと思います。 ..

16 security  networking  data-integrity 

私はこの記事読んで数年前ですが、あなたのREST APIを確保する巧妙な方法を説明します。基本的に： 各クライアントには一意の公開/秘密キーペアがあります クライアントとサーバーのみが秘密鍵を知っています。有線で送信されることはありません 各リクエストで、クライアントはいくつかの入力（リクエスト全体、現在のタイムスタンプ、およびプライベートキー）を受け取り、それらをHMAC関数で実行してリクエストのハッシュを生成します 次に、クライアントは通常のリクエスト（公開キーを含む）とハッシュをサーバーに送信します サーバは（提供された公開鍵に基づいて）クライアントの秘密鍵を検索し、要求はの被害者ではないことを検証（確かに私は理解していないことを）いくつかのタイムスタンプのチェックを行い、リプレイ攻撃 すべてが順調であれば、サーバーは秘密鍵と同じHMAC関数を使用して、リクエストの独自のハッシュを生成します 次に、サーバーは両方のハッシュ（クライアントが送信したハッシュとクライアントが生成したハッシュ）を比較します。それらが一致する場合、要求は認証され、続行が許可されます それから私はJWTを偶然見つけました。ただし、最初の記事ではJWTについてまったく言及していないため、JWTが上記の認証ソリューションと異なるのかどうか、またそうである場合はその方法について疑問に思っています。

16 security  rest  authentication  keys  hmac 

新しいWebサイトではあまり一般的ではないようですが、アカウントを必要とする多くのWebサイト（請求書の支払いなど）で、スペースを含むパスワードを作成できません。これは物事を覚えるのをより難しくするだけであり、パスワードのスペース、暗号化された、または（天国では禁止されている）データベースまたはプログラミングの制限がないことを認識しています。では、なぜ、サイトへのサインアップに関して、スペースバーはそれほど一般的に差別されているのですか？

16 security  login  privacy 

私は長い間Java開発者であり、最終的に、専攻した後、認定試験を受けるためにそれをきちんと勉強する時間があります。セキュリティの問題と関連するものについて読んだとき、私はそれを理解します...しかし、真剣に、誰もがその本当の例を持っていますか？ たとえば、Stringがファイナルでない場合はどうなりますか？Rubyにはないように。Rubyコミュニティからの苦情は聞いていません...そして、その動作（4行のコード）を実装するために自分で実装するか、Webで検索する必要があるStringUtilsと関連クラスを知っています。喜んで。

16 java  security 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 そのため、私は開発者としてさまざまな職場で働いてきましたが、データベースへのアクセスレベルはさまざまです。通常、本番データベースへのアクセス権はありません。 ほとんどの場合、テストデータベースにアクセスできますが、さまざまです。データベースとデータを自由に変更できる場合もありますが、通常は他の方法もあります。私はデータへの読み取りアクセス権しか持っていないように。 私はDBAチームがデータベースを管理する1つの場所で働いていましたが、「検査」するSQLスクリプトを含むフォームを送信しない限り、まったく変更できませんでした。彼らは通常、プロジェクト自体とはあまり関係がなかったので、ほとんどの場合、F5を押すだけでした。 正直なところ、なぜprodをロックダウンする必要があるのか​​は理解できますが、開発環境とテスト環境でデータベースにできるだけ多くアクセスすることを好みます。ほとんどの開発者は、データベースをどのように使用するかを合理的に把握できていると思います。しかし、私は意見を聞きたいのですが？開発者にはどのくらいのデータベースアクセスが必要ですか？そこに何かを壊さないと信頼できるでしょうか？

16 database  security  access 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 信頼できるWebサイトでは、「すべてのデータは暗号化されています」または「すべてのパスワードは128ビット暗号化を使用して暗号化されています」などのクレームが常に表示されます。 私のウェブサイトでは、SHA-512（ほとんどの場合）ハッシュをランダムソルトで使用した後、すべてのユーザーパスワードをデータベースに保存します。パスワードが必要であるためにWebサイトの使用を妨げないように、パスワードが安全であることをユーザーに保証するスニペットを追加します。ユーザーに安全を感じてもらいたいのですが、ハッシュとは誰もが知っているとは思いません。 私の質問：「すべてのパスワードは暗号化され安全です」というメッセージを提供しても大丈夫ですか？平均的なユーザーはハッシュと暗号化の違いを知っているとは思わないので、見ているだけで安全だと感じる可能性が高い慰めの言葉「暗号化」？または、提供する必要がある代替メッセージはありますか？ ちなみに、私は暗号化とパスワードハッシュが初めてであり、サイトを立ち上げた時点でこれで十分であるかどうか疑問に思っていました。安全でない場合は安全だとユーザーに伝えたくありません。どんな情報でも大歓迎です。ありがとう。

15 security  ethics  encryption  passwords  hashing 

私は多くの、多くの、読んだ多くの「あなたはおそらく間違ったパスワードを保存している」方法についての記事を。これらは常に、ユーザーがログインしているサーバーにパスワードを保存することを指します。基本的に、パスワードなどを確実にソルトするなど、ユビキタスなアドバイスを再ハッシュします（ただし、クライアントがログインする必要がないように、パスワードをクライアントに保存するためのベストプラクティスに関する記事を見たことはありません）ログインするたびに手動で。「私を記憶する」機能。 ブラウザからDropboxなどのプログラムまで、多くのソフトウェアにこの機能があります。 最近、DropboxがコンピューターにIDを保存する方法に関する古い記事を読みました。別のコンピューターにコピーして貼り付けてDropboxを起動し、IDを取得したデバイスとしてログインできます。ログインもなし、Dropboxアカウントへのフルアクセスもありません。これは本当にばかげたデザインのように思えますが、それを行うより良い方法は考えられません。 クッキーのようなものをプレーンテキストで保存しないようにする方法すらわからない。暗号化する場合、暗号化を解除するためのキーはどこに保存しますか？ セキュリティの脆弱性を導入しない唯一の方法は、自動ログイン機能を削除し、ユーザーがサービスを使用するたびにパスワードを入力するようにすることですが、それは使い勝手が悪く、ユーザーはそうする必要がないことを期待して甘やかされています。 自動ログイン機能を実装するために、資格情報を安全にローカルに保存することについて何を読むことができますか？原則が記事全体に対して単純すぎる場合、それらは何ですか？問題のソフトウェアは、すべてのプラットフォームに存在しない機能（一部のLinuxディストリビューションにある「キーチェーン」など）に依存すべきではありません。

15 security  login 

モバイルアプリがサーバーとデータベース（ASP.Net MVC 4にありますが、それはほとんど関係ありません）とやり取りするために、WebサービスAPIを構築する必要があります。ほとんどのアクションではユーザーをサービスに登録する必要はありませんが、アプリのユーザーのみにアクセスを制限したいと思います。 他の場所（たとえば、すべてのデータを必要としている人や非公式アプリを作成している人）からの呼び出しを拒否するための方法は何ですか？ 私の最初のアイデアは、デバイスがサーバーにトークンを要求することです。トークンはランダムに生成され、そのまま送信されます。他のすべてのメソッドは、ソルトされたトークンのmd5ハッシュになる特定のヘッダーがリクエストヘッダーに含まれていることを確認します。サーバーはトークンとソルトを認識しており、ハッシュを計算して送信されたものと比較できます。さらに、トークンは限られた寿命であり、デバイスは1時間おきに別のトークンを取得する必要があります。 これは実装が非常に簡単で、おそらく100％の証拠ではありませんが、良いアイデアのようです。どう思いますか？

15 security  web-services