How does challenge-response authentication prevent man-in-the-middle attacks? I read the wiki article but still I cannot understand.
In general, challenge-response systems do not necessarily prevent man-in-the-middle-attacks: If Alice is trying to tell Bob her bank account number, this protocol, which does implement some challenge and response, won't provide integrity or privacy:
Alice: Bob, is that you? // first challenge
Bob: Yes, Alice, it is me, is that you? // first response, second challenge
Alice: Yes! Great. My account number is 314159. // second response, and result
Mallory could answer "yes" in place of either Alice or Bob, could fake the third 'result' message, or could listen in on the third message.
Even if the challenges are improved, to something like: "Please hash 0x31415926 prepended to our shared password", data transmitted in the clear (or under weak/poor ciphers or with poor key selection) would be subject to loss of privacy, and data transmitted without any message authentication checks could be subject to modification by a third party.
Where challenge/response protocols really shine is in preventing replay attacks: if Alice just sends Bob a message along the lines of "Please debit my account $5 and credit your account $5", Mallory could record the message and replay the message to deplete Alice's account.
A good challenge/response system will generate a new challenge for every transaction or session (and make sure that previous challenges are not reused!), so that session transcripts cannot be spliced together to create new fraudulent systems.
I hope this helps, but I'm afraid without more detailed idea of where your doubts are coming from, it'll just be noise.
User sarnold already provides a good answer, I'd like to drag attention to the following.
Challenge-response solves two problems - makes sending the secret in plaintext unnecessary (hash-like product is sent) and prevents replay attacks (since challenges change every time). It doesn't do anything beyond that - it doesn't authenticate anyone to anyone on its own, it is only an improvement of a plaintext protocol where the client sends his username and password (the secret) and the server decides whether those are correct.
So if there's some party in the middle it won't help detect it or prevent it from impersonating as the client for that specific session, yet that party will not gain access the the secret, since the secret is never sent in plaintext, and that party will be unable to impersonate again by doing a replay - it can only work impersonated during that very session.
Related
First of all, let me explain u what i imagin to do:
Lets Imagin Bob want to get Authorizat by Alice (Classic Example), in my Example Alice is a Server.
Lets Imagin too that Bob and Alice already got each RSA Key (4096).
So Bobs Steps to do that would be:
Sign credits (Plaintext) with SHA512 and his private Key
Encrypt Signed Data and Credits with AES CBC 256
Encrypt AES Key with RSA
Sending Datas to Alice
So Alice would do the steps abouve from the opposite to decrypt it and verify its from Bob.
After Alice verify that its Bob, she generate a JWT Token and Sign this with her Private Key and Return it in the Response Header Authorization.
The JWT got a TTL from 3600.
So far so good but my Question is now how do we Protect the JWT from getting Stoled ?
Sure its Signed so its cannot be Modified (Except Attacker got Private Key from Server but my god then its anyways over).
Lets Imagin he would be Able to Break the HTTPS and stealing the token, put it in his Header and so he can Trick Alice to believe him untill its Expire and he need to send the Credits again.
I was thinking about two Options:
Option 1:
Always sending Credits and Decrypted to verify Bob.
But this would be costing Huge Perfomance each time of request and the benefits from JWT gets lost.
Option 2:
Sending a Unique ID and confirm its from Bobs Device (Encrypted, so same Problem like Option 1)
What could we do to protect that?
Maybe im Overthink to much, like always, but i would really like to know what in that case would be a "Best Practise".
Thank u already for ur Answers
So far so good but my Question is now how do we Protect the JWT from getting Stoled ?
As you already found out, it's https
Lets Imagin he would be Able to Break the HTTPS and stealing the token
If someone is able to break HTTPS then we have a much bigger issue then a stolen header. By default you could trust https (except special cases in some countries)
Let's assume the channel is not secure, you may for example sign every message separately (with an unsecure channel it's not enough to secure just a header).
Well, If Alice is not sure of who is sending the request then so is Bob, So its a two-way problem, No one is certain of the other's identity, You can fix that with a singed certificate from a certificate authority.Where you send with the signature a certificate, And this certificate is singed with the private key of the certificate authority (a third party), Which insures that the connection between the client server is secure and prevents any modification.
I'm doing a connection system for my users. So I decided to use Cookies to store the User ID and the password (in sha1). But I have one question. If a random user gets the value of both cookies and their names, can he creates them with for example a js function and get into the account?
Is it secure if I store a sha1 password and a userID in secure flag &
https Cookies?
No.
I suppose you want to know why? First, define "safe." What threat are you trying to mitigate?
Once the credentials are hashed, there's no way to get the plaintext back. Since you can't render the hashed string back to plaintext then we can assume that the intent is to compare them to the same hashed string held at the server, yes? That's awesome if the threat you want to mitigate is somebody discovering the password and user ID and you use something like SHA256 instead of SHA1.
But if the threats you want to mitigate include replay attack or session hijacking, then these are no better than any other fixed string. In fact they are worse. If the user is obliged to provide their password for each HTTPS request it sucks for them but at least the app can throttle login attempts and foil a brute force attack. If the credentials are hashed and exchanged in cookies, then they are exposed to adversaries and if obtained can be subjected to brute force cracking or looked up in a rainbow table so on net sending the credentials back out, even encrypted or hashed, kinda sucks.
The question doesn't mention salt or session keying. An adversary will look at the cookies to see identical values are returned over multiple sessions. To prevent replay attack you'd need to append a nonce before hashing to act as a salt so the hashed string changes each time. But it doesn't solve the problem of sending a transformed credential pair outside of control of your own server or that this is far worse than just using a long random string for the same purpose.
Furthermore, the hash of the credentials doesn't time out until and unless the user changes their password - at which point it tells an adversary that the user just changed their password which is a great piece of info with which to social engineer the IT support person who does password recovery. "Hi, I just changed my password and locked the account. Can you reset it? Employee ID? Well if I had access I could look it up. Can you just reset it? I'm really me. How else would anyone I know I just changed it?"
The support person would never guess the answer to that question is "because Victor's app design told me it was just changed" and might just reset it for the adversary. But if the session is kept alive by a session cookie or a triparte login token then the unique string representing that user's session mitigates all of the threats discussed so far:
An attacker can't reverse it or crack it to discover credentials because they aren't in there.
It can't be used for session replay since it is generated to be unique for each session.
It expires within a short period of time so it can't be resurrected from browser cache or history.
But rather than answer the question as asked, I'd like to answer the question "Is there an authoritative source for comprehensive web application security best practices?" That's a much easier question to answer and it potentially answers your initial question if you follow through with the required study.
Please see: Open Web Application Security Project (OWASP).
In particular, please see the Session Management Cheat Sheet and the Authentication Management Cheat Sheet as these cover much of what you are trying to do here.
OWASP periodically analyzes all reported breaches for a recent period and then publishes the Top 10 Vulnerability List based on the root causes that showed up most often during the sample period. When I QA new web sites on behalf of clients they almost always have several of the defects in OWASP's Top 10 list. If as a developer or web site development company you want to stand head and shoulders above the crowd and get a lot of repeat business, all you need to do is make sure the site you deliver doesn't have any defects in OWASP's list. The question suggests any application built as proposed would have at least 4 or 5 defects from the OWASP Top 10 so that's an aspirational goal for now. Aim high.
I was wondering if anyone has ever used, built or seen a password recoervy tool that was completely online and didn't require sending some kind of password reset email.
I understand the security concerns and I am completely open to the idea that this is just not a secure way to handle things but I have been tasked by my employer to look into this type of solution. I feel like I have used something like this before.
Our main concern is email spam filters grabbing lost password emails. If there were best practices on formatting these emails that would be a great thing to send over also.
Any thoughts?
THanks
Craig
Almost all security relies on varying combinations of the three things below
Crypto-graphic proof
shared secret
trusted third party
and using them, for a given level of likelihood, to verify that the counter-party in the current transaction, is the same party with whom you had the original contract.
Really thats all "online identity" is - how likely is it that the person talking to me now is the person I was introduced to yesterday.
For example, a password is a shared secret, that both parties know and assume for a given level of likelihood that the other person with the secret is who they think they are.
Thats the easy one.
The security question (Mother's Maiden name) is just a second password in case you forget the first.
OpenID is a trusted third party approach. Stackoverflow trusts google. I try to login to
stackoverflow and SO passes me over to google. All SO sees is google coming back saying "yes he is".
However, compared to email penetration, OpenID is hardly used, so its not going to work as recovery option.
The email password reset is an example of a direct shared secret involving a trusted third party - gmail is "trusted" by both parties, so one can send a shared secret to gmail, and trust that for a given level of likelihood, only the other party will be able to access that shared secret.
Finally cryptography can be used as a trusted third party. If I know your public key I can "trust" RSA and store the new password by encrypting it then putting it on my website. Only you can read it, so it could work as an instant, online password reset. But the penetration of PGP/GPG is so much worse than that of OpenID the idea is a non-starter (*)
What you need is a second channel of communication that you gather at the time of contract - usually it email, it could be openid, a mobile number or their GPG public key.
But you must collect that channel at the time of making initial contract.
Talking of mobiles, I did see a neat one at my local cellphone shop - they texted me a random password, and then the sales assisstant entered in the password when it arrived at my phone - proving the phones owner was in the shop and compliant. (for a given level of likelihood).
(*) actually I think there is a solution - http://www.itmanagerscookbook.com/Attitude/identitycrisis.html. AS you can tell trying to express the concepts above is an ongoing effort.
The only safe alternative I'm aware of is offering a password reset page after a security question (mothers maiden name, but preferably something user configurable/safer).
Most of the online sites on registration do send a link to activate the site and on any further correspondence with the end user they provide information about the site and also provide the login credentials with password in clear text (as given below)
Username - myname#gmail.com
Password - mysecretpassword
What would you do in such a case? From a usability perspective does it make sense to send the password information in clear text or should you just avoid sending this information. I was under the impression that most of the passwords are MD5 hashed before storing in the database and hence the service provider will not have any access to clear text passwords, is this a security violation?
It's a commonly-held fallacy that if you receive a password in plain-text it means they aren't stored securely - passwords like any other data can be stored using reversible encryption.
Having said that, it's pretty likely anyone that sends you a plaintext password does not have a clue about security and is probably storing them carelessly (unless the passwords are used as weak real-world identifiers, say as part of an in-store membership scheme, in which case they shouldn't be called passwords lest your customers get confused).
If you send a password plain-text you may as well assume that if it is linked to something important then it has been compromised. There are just too many weak points. You can also do a lot more unintentional damage.
The email could be intercepted giving someone else the password.
Someone could see them open the email on their screen (been at mates houses and had this happen to both of us so many times, and every time is a massive headache to go change all your passwords).
The email might be forwarded to other addresses which are not secure.
The email might bounce/encounter a server error and then you (perhaps your untrusted staff or outsourced helpdesk too?), and the email server's system admin will probably get copies of the original email.
Someone who obtains access to the user's emails through a cookie hijack or even just a briefly unattended open email account will now be able to see their password. Worse, their password is probably used elsewhere (or at least has a common stem, e.g. "password1", "password1$$" "passwordSuperSecure123") so you've now compromised more than just your own service. Worse still, it might be the password to the email account that's been hijacked and now they can steal this person's email account and thus identity for a much longer time than the expiry date on the cookie/session. (This has all happened to people I know).
Yes, this is definitely a security violation. Only a salted and hashed version of passwords should be stored.
It is common to have reset password functionality that sends either a temporary auto-generated password (which should be good for only one login) or a one-time reset link. This does mean your other accounts are only as secure as your email.
However, you should steer clear of any site that will email your actual password in clear text.
There are always trade-offs, and developers have to consider useability, the savvy-ness of the intended users, the secrecy and importance of the data, the frequency that the website will be used, and so on. Of course users don't want their privacy violated, but on the other hand "ordinary" web users may be turned off by having to remember a password, or even having to invent one in the first place (some websites simplify user registration by generating a random password and emailing it). Website developers have a responsibility to keep the users' best interests in mind when designing security.
My advice is that passwords should only be emailed in the clear when they are randomly generated. This avoids the following awkward scenario: a user registers with a password which they are already using for various other web services, and then receives a registration confirmation email containing the password they just entered. A lot of users may not be security-conscious enough to use unique passwords for every website, but they are security-conscious enough to recognize that "sensitive" passwords should not be sent around by email.
My company is developing an online HR and Payroll application where securing access is critical. I'm clear on how to lock down most of the authentication/authorization processes, except for the 'Forgotten Password' page.
My initial plan was to require the user to enter both an e-mail address and a response to a previously selected/entered challenge question, with a temporary password being mailed to the e-mail listed (assuming the e-mail is valid). But I've read here and here (both on SO) that the challenge-response approach is insecure.
If we're only e-mailing a temp password though, is it really that insecure? The only more secure option I can think of would be to require the user to call their Customer Service Rep, which would greatly burden our employees.
What am I missing ... is there a better approach? Thanks!
Don't email a temp password, email the user a URL+token to a reset-password page. That way no password is ever changing hands unencrypted. It's also immediately obvious to the end-user that their account has been compromised if they try to go to that page and the reset token has already been used.
Added from the comments:
I think challenge-response ("secret question") aspects actually make things less secure, because they are generally things that can be discovered by researching public info about the target. The fewer steps total, the fewer that can be broken without anyone knowing. Letting reset emails go early and often is a good way to let a human know the attempt is being made.
As explained in this article, Governor Palin e-mail account was recently hacked using answers to previously asked questions. From the article:
As detailed in the postings, the Palin hack didn't require any real skill. Instead, the hacker simply reset Palin's password using her birthdate, ZIP code and information about where she met her spouse -- the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search.
There are a few common ways to manage lost passwords:
The Secret Question: It is actually a weaker form of authentication, just like people above posted. User may choose something really simple and it is easy to guess. I advise against this, because it does not require any technical "hacking"
Mail a new password. To circumvent this control, access to the e-mail account is required or a Man-In-The-Middle (MITM) position is required: You either read the temporary password from user's inbox or intercept in the middle. This approach is ripe for misuse, because anybody can reset the password and force the user out of the system, if he can't read the e-mail with new password.
Mail a password reset hash, to circumvent this, you need access to inbox or MITM, just like in case before this, but no passwords are actually reset until confirmation is done. Thus, user can not be locked out of the system, even if he did not read the e-mail. Add a cooldown timer to one reset per 8 hours to prevent Your system from flooding user's inbox.
Consider some out of band communication, for example, in the printed contract, write down a PIN. Then have the user call Your helpdesk from a known phone number (check with Caller ID) and give his username and PIN.
Wouldn't it be easy/feasible to outsource the whole password management just like SO did and use OpenId or similar? Of course this would add another dependency, but you'd trade that against the need to save (and secure) passwords and deal with them as you described.
You said it is an on-line HR and payroll application. Do you have the option of a user indicating he/she has forgotten his/her password and that generating a message to an HR representative or some official in the organization who can confirm identity and then issue a password reset?
In short, challenge questions are often the weakest link. They're easier to guess than a password and effectively operate as a proxy for a password, so they actually reduce security rather than enhance it by providing another attack vector that's actually easier to break. The Web Application Hacker's Handbook has some great information on this area.