Can a security control be both management, technical and operational?

You are absolutely correct in your first question that security controls can be categorized in many different manners, and that a particular security control could possibly fall into several of those categorizations.

There is no absolute universally agreed-to set of categories either, some are older categorizations that made sense in the 1990s and 2000s, and newer categorizations have evolved to address contemporary defense strategies against threats. The Wikipedia article on Security Controls lists two categorization schemes: {Physical, Procedural, Technical, Legal} and {People, Technology, Operations}.  The IS Handbook shows another set {Admin, Logical, Physical}.  And you can google to find even more opinions about how to categorize security controls.

I would suggest however that you not get too hung up on security control categories in the first place.  They are too high level, and not very helpful in actual design and development of a security solution for a particular system.  How they are helpful is in reminding you (the security professional) that security controls are more than just technical.

A good security solution that achieves an acceptable level of residual risk is one that has a diversity of overlapping controls, that draw from ongoing security insights from talented humans and from rout operational procedures (from those humans with less talent) in addition to security technologies.  However too many security professionals just focus on the latest technical security toys, yet forget to lock the door to the network closet (to cite a trivial example).

[One side note, if you are studying for a professional credential or a security class, then no matter what you might think otherwise, to pass you will need to parrot that credential's or class' definition of categories, and where they place security controls within those categories.]

For your second amplifying question, some examples of notional security controls that may fit multiple classifications that I can think of off the top of my head:

"Ensure doors to computer equipment rooms are locked":  this is both management/physical (the locks have to be installed on the doors), and procedural/operational (a human needs to check the locks on an on-going basis typically daily).
"Audit Logs of Security Critical Events are to be reviewed immediately": this is both technical (some software or hardware has to generate those logs) and procedural/operational (a human needs to ultimately review the events and decide a course of action).
"Admins with access to sensitive database servers shall undergo periodic background checks": management (sets up an HR security infrastructure and funds/staffs it), procedural/operational (HR staff has to periodically do these checks), technical (most background checks are now performed via online services).
"Boundary Routers shall be configured to perform Network Intrusion Detection": technical (the router hardware and its software), and operational/procedural (someone not only has to configure the router properly the first time, that configuration has to be audited periodically because admins unfortunately make undocumented and non-appropriate changes to router configuration "on-the-fly").

I'm sure that other responders can suggest many more examples.


Connecting Pendrive used by multiple users

Usually those people are not very tech-savy. Thus there is a high risk that their PCs might be infected and they might spread it unknowingly via attached USB flash drives.
When booting from a Linux Live CD and accessing the data there, the risk could get reduced as with a reboot, changes to the OS are gone and most malware is written for other operating systems. There are things like bad usb and usb killer, though.
This risk could be mitigated for example with a dedicated, encrypted flash drive (e.g. Kingston Data Locker+) that are not as easily forgeable to a bad usb device as the generic dollar tree thumb drive. Non-tech people might have difficulties to operate an encrypted USB stick. But it would also educate them how to protect personal data against theft or loosing the flash drive.
However, I would not accept USB flash media from people that I know that they are not following basic security precautions.
The perfect medium for this is a CD/DVD without autorun. Albeit a bit vintage and can be read by anyone that gets access to it.


Securely hide a directory from the OS using java?

One trick you can use in Linux is to create a file, keep the pointer/handler and delete it immediately. You can then use your file's handle to write and read to it. Linux won't show the file to nobody because you removed it from the OS's file table. Unfortunately you would have to write back the file in a "normal" file when you program closes since you did delete the file. This method is usually used to create temporary files for programs.

As for windows I don't see how you can manage that.

Hope that helps a little.


Is the HTTP method OPTIONS secure nowadays?

I would say implementing the OPTIONS method, in itself, is not a significant security risk. Yes, it nicely enumerates which other methods are implemented by a server, but it is in the handling of those other methods that the potential for danger lies, not in the reporting that they are handled.
For example, the TRACE method can be a vector of attack. If you implement OPTIONS, and it includes TRACE in its response, a potential attacker can use OPTIONS to discover that TRACE is supported then decide to try and launch an attack on TRACE. However, if OPTIONS is not implemented, or it lies and says TRACE is not implemented, the attacker could still decide to try and mount an attack using TRACE. In fact, they are probably just as likely to not use the OPTIONS command at all and simply see if an attack on TRACE will work.
You should focus on making sure that potentially unsafe methods (such as TRACE) are disabled or suitably protected, ahead of worrying whether OPTIONS tells an attacker they exist.

The OSWAP GitHub page on Test HTTP Methods starts by listing the eight HTTP methods defined by RFC 2616 (HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT) but only mentions four that should be disabled (or sufficiently protected):

More specifically, the methods that should be disabled are the following:

PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
CONNECT: This method could allow a client to use the web server as a proxy.
TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

And while it highlights how the OPTIONS command can be used by a tester to determine potential vulnerabilities:

How to Test
Discover the Supported Methods
To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

Execution of a test-script only highlights the TRACE method as risky:

The same test can also be executed using nmap and the http-methods NSE script:
C:\Tools\nmap-6.40>nmap -p 443 --script http-methods localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-04 11:52 Romance Standard Time

Nmap scan report for localhost (127.0.0.1)
Host is up (0.0094s latency).
PORT    STATE SERVICE
443/tcp open  https
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 20.48 seconds

The rest of the OSWAP page discusses potential security problems (e.g. the potential of using TRACE to exfiltrate cookies tagged httpOnly into JavaScript), but does not talk of OPTIONS being a security concern.


Are there any workarounds for CVE-2017-0561 (Broadcom Wi-Fi remote code execution) on Android?

According to the detailed report this specific problem can be triggered by specifically constructed Wi-Fi packets. From my understanding this kind of attack should possible for an unauthorized attacker and it does not matter if the victim is associated with a Wi-Fi network or not.  This means that the only workaround to protect a vulnerable device is too completely disable Wi-Fi.


Verify a user's affiliation with an organization

How about generating a special code for each user that can be entered on TicketSellingCorp's website? You can give TicketSellingCorp a list of valid codes. TicketSellingCorp can ask users for their name and other personal info when registering, and this could optionally be checked against your own database later.

The codes should be generated randomly to prevent people from guessing other people's code (impersonating them). 128 bits of randomness should be more than enough to make sure they can't be guessed. For example an easy way to get codes is to get 16 bytes of output from a secure pseudo-random number generator (/dev/urandom or in PHP openssl_random_pseudo_bytes), then convert it to hexadecimal and store it somewhere in the database.

If TicketSellingCorp is really set on logging in with the user's account, you could make the codes work as secondary passwords that only give out certain information. Also if they're so set on doing that, I'd trust them even less.


dkim passes under a different domain's dkim

For a full evaluation, it would help if you at least included the unauthorized domain.

I, personally, see this type of result fairly often when someone we send to is using a "cloud" hosted email solution.
I send a message to someone at MIT at their @mit.edu email address, but they prefer using their personal Gmail account.  On their side, they have set an auto-forward-all rule to send everything to their @gmail.com address.

The kicker is that MIT uses O365 as their email provider.  So what I end up seeing is a DMARC report from Google about an email sent out of Outlook.com .  Something like:

<identifiers>
  <header_from>[my domain].com</header_from>
</identifiers>
<auth_results>
      <dkim>
        <domain>protection.outlook.com</domain>
        <result>pass</result>
        <selector>s1_dkim.protection.outlook.com</selector>
      </dkim>
      <dkim>
        <domain>[my domain].com</domain>
        <result>pass</result>
        <selector>selector-[city_of_main_office]-01.[my domain].com</selector>
      </dkim>
      <spf>
        <domain>protection.outlook.com</domain>
        <result>pass</result>
      </spf>
</auth_results>

Notice that the report never mentions MIT.edu domain (which is where I sent the message to).

By seeing the passes in this order, along with the header_from still indicating your domain, it is a near 100% likelyhood that this report is talking about an auto-forward rule that someone has in place.  Most important for you, is that a spam report against this message would have minimal effect on your domain; by overstamping their DKIM and passing their SPF, the [unauthorized domain] has accepted send responsibility for this message.  At this point the inclusion of the DKIM for your domain is more to prove a chain of custody (we forwarded it without editing it) than to prove who is a spammer.


What precautions should I take before letting users send email through my app?

Emails are rate limited, each user will only be able to send n emails in a 24 hour period where n is based on their subscription plan.

Obvious first step, rate-limit emails per user.
Rate-limit new signups. In your case it looks like users have to pay for access, so that is an effective rate-limit. This is important if you rate-limit emails per-user. You obviously don't want a single person bypassing this by easily creating a large pool of users.

  The application itself will make API requests to a third-party mass SMTP provider and let them do the actual sending, rather than send it directly from our server(s).

Mail receivers often track sender reputation per IP address. Since you are using a third-party provider to send the emails, then it is their IP which will take the reputation hit not yours. This is important, as you don't want your all-important company Email Server to be on the same IP that sends less-vetted emails.
It may be best to throttle emails sent so you are not recognized as a DoS attacker by various mail receivers, but your provider may do this for you automatically.

  Some users may want to send from a no-reply or other corporate address, different from the email they use to log in. How should I best verify users own or have access to the address? I can't always use verification emails because if they want to send from an unmonitored address they obviously won't be able to check for said verification email.

If you cannot verify they own the email address, you must instead verify they own the domain. This is a good subject for a separate question, but in short, I would suggest you look at how SSL Certificate providers verify ownership.

Email verify to limited set of known admin account usernames. (postmaster@example.com, etc)

Alternatively, check the WHOIS and send your email verification to the Admin contact there.
DNS verify by requiring them to add a specific random TXT rule.
You could use HTML web page verify but that could potentially be disconnected from what really needs to be verified.

  Is anyone able to explain how I should make use of SPF records (or get my users to make use of them) in this instance? I have read about them but my knowledge is still shaky in this area.

SPF records are managed by the From domain holder.

If you are sending From your domain, with a Reply-To of the customer's domain, then SPF is simple to configure, but should be a separate question.
If you are sending From the customer's domain, then it is your customer's responsibility to list your sending server IPs, so that they are not accidentally adding spam points to those emails.

For customer convenience, you should probably publish an SPF rule, so that your customer can include it. This way if you make any changes, such as switching SMTP providers, then your customers will not have to update their SPF ruleset.

The SPF rule you publish can be a simple include of whatever your SMTP provider has published on their end.

  Will there be any special precautions to take if we scale the app over multiple servers?

As I said above, receivers track reputation per IP. (in your case, the SMTP provider) I would point out that your servers should be synchronized so that rate-limiting is enforced. You don't want the user connecting to a different server to be able to bypass a rate-limit error.

  As an additional note, like the market leader Salesforce, I intend to allow my users to send an unlimited number of single (non-bulk) emails to other users, but above I am talking specifically about emails sent to non-users.

You may consider sending these from yet another IP (if your SMTP provider assigns IPs to you) so they get a separated mail reputation from the bulk emails.
You should always have some rate-limit, even if it is not advertised, to prevent robotic or user-script submission.

  Users will only be allowed to send email to their contacts or accounts already on the system, no mass emailing lists of addresses only.

This is helpful from a user perspective, but I assume that technically they can add contacts to their system using a user-script, so this probably is not relevant to the determined spammer?

  Using the "on behalf of" feature for the sender address.

I'm not 100% sure how your are doing this, but it does sound like a reasonable thing to do.


Is it possible to detect 100% of SQLi with a simple regex?

Keyword filtering for SQLi is not a good technique. There are too many ways to bypass it.

Crazy things like sel/**/ect might work, for instance. Or playing games with substr(). And then there's EXEC('SEL' + 'ECT 1').

There are many guides on how to bypass common filtering techniques.

But then you might ask if there is a superset of things to filter for (like select and /**/ and substr and EXEC), but then the list gets very, very long, and you still might not get a comprehensive list.

The better approach is to understand the range of acceptable inputs and protect those or to make it ineffective to use SQLi through proper design.


Are there security advantages gained from forcing a website to be available from just one tab at a time?

Generally, no, it's not reasonable to force users to a single tab. There are no technical security reasons for making a website available to a single tab only. This is generally common just due to poor system design.

Forcing a single tab also means that when you log out, you won't leave your sensitive information plastered in twenty other tabs. This is poor reason though, as a site that is bothered about this can use localStorage or websocket to simultaneously clear all tabs when logging out from one tab.

The human factor of security is a marginal reason why some sites might deliberately restrict itself to a single tab. By forcing a single tab, you force people to focus on one thing at a time, and this makes you less likely to forget something. IMO, this is a poor reason, as the drawbacks outweighs the advantages.


As an immediate mitigation, shut down your NTP service until you can get it secured properly.  Your computer's clock won't (or at least, shouldn't) drift too much in a day or two.  You'll still be seeing the incoming requests, but your server won't be sending replies, so the overall traffic level should drop by 90% or more.

Since you're running a home server, you're probably not providing public NTP services.  In this case, securing things is easy.  You can block all incoming traffic to UDP port 123 at the firewall, or you can use the "UNIX ntpd" template here to configure ntpd to ignore incoming requests, or (better) do both.


Where do I find more information about a given hacking attempt requests to my website?

Having a web server, I often find some of those 404 errors.

Those reflect a bot trying many URLs that, if they don't return a 404 error code, mean the targeted application exists in the server, and an exploit is possible.

  If this variant of the vulnerability exploit failed with a 404, another one may succeed,

Keep in mind that while you get 404, it means you don't have the targeted application installed, and your server is not at risk (for this application). It's when the bot will hit a 200 http status code that you will have to worry, since it means the page exists and thus a possible vulnerability is present (it now depends on the version of the application).

Now, I don't know any "Matching url to application", but since the application are usually installed in a directory of their name, say "phpmyadmin" for ... well, PHPMyAdmin, you'll be able to guess that /spaw2/spacer.gif is for the Spaw2 editor.

Now, in order to secure your web server a little bit more, I can recommand you to :

Install application in a non logic name. PHPMyAdmin should not be present at /phpmyadmin/. As you can see, bots are also trying /pma/, but you can install it at /p-m-a/ or even something opposite like /kikoo/.
For risky application, like ... PHPMyAdmin, I warmly recommend you to limit access to some IP address only, using the .htaccess if you're using Apache, or directly in the configuration of your host for others (like NGinx). If you can't, having it on some other folder (see #1) is a good start.
Even if you move or if you don't have the application installed, you'll still have the 404 errors. In order to reduce it, you can add some rules into your firewall, like for /spaw2/spacer.gif. But don't forget them in case some day, you will really have a file named exactly like this!
If you use Apache, you can configure Fail2Ban to ban bots that do unusual stuffs, like "too many password failures, seeking for exploits, etc".

Hope this helps!


Timeouts are necessary because the internet is unreliable.

We like to think of the internet as based on "connections", but that's not actually true. It's based on individual packets, which are received discretely and independently of each other.

In simple terms, when the server wants to send or receive data, the server usually can't send all the data in one packet. Instead, the data is chopped up and sent in individual packets.

In the best case scenario, the client would receive each packet, and then send an acknowledgement back that the packet was received. But what if the client never responds? This can have various reasons such as bad internet connectivity (think mobile internet), a crashed application, someone tripping over a cable, the bomb detonating on bomb site B, etc...

The server is blissfully unaware of the fate of the client. All the server knows is that no acknowledgement was received, and assumes the packet was lost, so the server sends the packet again. If the reason why the packet was received was temporary, then the client will receive the resent packet without problems and the communication will continue. If the reason is more permanent, you don't want the server to keep sending packets needlessly if the client would never answer.

As a result, the server at some point "times out", assumes the client is gone and frees the resources it has allocated for the transmission.

Why is this relevant for security?

The Slowloris Attack abuses the way how many web servers treat incoming connections. By sending requests veeeeeeeeryyyyy slooooooowly, the web server never quite times out, but instead has to keep allocating resources to keep the incoming request in memory.

The solution, or rather, mitigation to these attacks is limiting how slow a client is allowed to be. By sending them a timeout if the request took too long to complete you effectively set an upper bound on how effective such an attack can be.

What about clients just sending lots of data?

You can configure the server to set a maximum request size. Anything larger than this would be disregarded and the connection would be reset mid-transfer.


Friend received email from my name, but an unknown account

First, you cannot stop someone from sending emails from an account that they set up.

Second, if you have a common name (Chris?) then this is not unusual at all to get phishing emails (or emails with infected links). Spam has been happening for a very long time.

Third, if the email address included your last name, then it is possible that either you or your friend has had their email accounts compromised and the address books mined for contacts. If this is the case, I highly recommend changing passwords and implementing 2-factor authentication (if available).


What security considerations should be made when choosing a universal authenticator app?

I don't think there is really anything we as a group can do to contrast those in terms of security of the app out-of-hand, since they're at least all reputable organizations(though hey, maybe someone here has actually tested them, who knows!), so all other things being equal there's only really one question I can think of:

Which auth app will incur the smallest expansion of my digital footprint?

i.e. "Which app's use least results in my data being sent to new locations/entities?"

In the case of the USPTO, with a gmail account as username, we can assume that 2 entities by necessity know your gmail address(USPTO+Google), and 1 entity definitely knows you have a USPTO account, with another (Google) being extremely likely to learn it as soon as you get an account creation verification email.

So in this case, the minimal number of entities who know about you is 2.
This is before we choose an authenticator app.

Without recommending a tool, I will say that it seems clear to me which choice would not involve informing an additional entity about one or more pieces of information (i.e. that you have a USPTO account and/or your gmail address)...


What are the security benefits of reset all fields if captcha was failed?

Emptying the password field: yes, this is a standard feature for all form submissions, not just ones where CAPTCHA failure is involved. If you returned a page with the user's password in then would you have to worry about it being saved in the browser's disc/page/bf cache and being recovered by later access to the client machine.

Emptying other fields: no security benefit against an automated attacker. I doubt this is a deliberate measure. I would suspect the sites in question simply don't consider it a usability priority to ensure the form is preserved for the convenience of a user they believe to be an attacker. (They may have an inflated sense of confidence in their CAPTCHA and don't think a real user will fail very often.)


Do keyservers keep logs of who adds whom to their keyrings?

You cannot tell whether the keyserver operator logs access to his keyserver or not. Most common keyserver software is open source and can easily be changed (if logging features aren't built-in anyway).

However, it is not possible to trace which key ID / user interacted with the keyserver (the clients do not authenticate in any fashion), but keyserver operators could log their user's IP addresses.


Recommended authenticated stream cipher for minimum overhead?

Use any authenticated encryption mode.

That could be a stream cipher with built-in support for authentication (not what I would recommend; all of the candidates are still bleeding-edge), any standard authenticated encryption mode (e.g., GCM, EAX, etc.); or use encrypt-then-MAC with AES-CTR and a suitable MAC (e.g., AES-CMAC or SHA256-HMAC).  Any of those will be fine.  You have not given us any requirements that would rule any of those out.  All of them allow you to select the size of the MAC tag, so you can control the overhead vs. security tradeoff.

But really, you'd probably be better off using TLS or DTLS -- at least, most folks probably would be.  (I know you said you don't want to, but I haven't heard any compelling technical reason not to use them.)


What does ENV (“_”) do for anti-debugging?

Bash sets the environment variable _ to the path to the command that is being executed. So do zsh and pdksh. But other shells, such as fish and dash (which is the default scripting shell on many Linux distributions) don't do it. ATT ksh sets it to a value which includes the path to the command.

The idea is that a program can check the value of the environment variable _ to see what invoked it, I guess. Except that this is extremely unreliable even if the user isn't doing anything to change it. If the program is launched from a GUI or via a script, _ could be empty or could have some completely unrelated value, and that's perfectly legitimate and very common. And of course if the user does want to change it, it's absolutely trivial — just run env -u _ myprogram or env myprogram.

As “anti-debugging” measures go, this one is pretty ridiculous. Not only is it spoofable with zero effort, it wouldn't actually work in normal use. If some reading material touts it as an anti-debugging measure, I would recommend against this material as very unreliable.


Certifiable standards for server security, besides PCI-DSS?

It isn't quite "certification" but there are many go-to security baseline configuration standards available..

Some examples to get you started are:

The Center for Internet Security (CIS)

The National Institute of Standards and Technology (NIST)
csrc.nist.gov/publications/PubsSPs.html

NSA

Often times the vendor of the technology or application will also provide specific security lock-down guidance and practices. For example, Microsoft offers tons of docs ranging from threat modelling to auditing practices to secure configuration.

Some vulnerability assessment tools will benchmark check your configuration against these templates. But note, like PCI benchmarks, it may not cover all of the guidance provided.

Personally, i have favored the Center for Internet Security (CIS) ones in the past.


Rerouting domains and the need for multiple SSL certificates

You certainly need SSL certificates for both domains.   That does not necessarily mean two separate certificates, however.  While this is not a candidate for a wildcard cert, (since these are two actual domains, and not subdomains of a single domain) but the subject alternate name (SAN) field of a SSL certificate can contain multiple domain names, so you can have both domains listed within a single certificate.   This tends to be more expensive, but also  easier to manage.


How useful is Protocol Anomaly-based IDS?

The problem IDSes face today is encryption. Once you receive a stream of encrypted information, you can only try to make sense of its behaviour.

They rely on defaults (a default port or protocol for a service), on well-known endpoints and on some pre-encryption activities (handshakes for instance).

So I would say that it is more one of the few possibilities left today, rather than being "more practical".


Open exploits database, with structured data (CMS name, version, etc.)

Use the CVE database itself. They have a structured XML where you can extract all vulnerabilities you want.


Is this actually a vulnerability scan? If so, which one?

I would assume so (it's difficult to say for sure, but it makes sense).

It's also a rather practical file to scan for. With one request, an attacker can check if you have installed one of multiple applications.

Additionally, a changelog will also contain a current version number, so there is no need to additionally scan for that.

One prominent application having such a file would be Drupal, but it's a very generic file name, so many other applications will use it as well.

An attacker could also apply basic filters on the first couple of lines of the file and get a string likely containing the application name. They can then manually look it over and store it in a database or check if whatever is running is vulnerable.


Edit: October 3, 2015 An article in IT World for September 29, 2015 reveals the existence of, but doesn't describe fully, two serious flaws in the Windows driver that TrueCrypt installed.  It isn't clear from the article whether those flaws compromise the crypto or the underlying Windows OS, or both.  It also isn't clear whether that driver is installed only for full-disk encryption or at any time a TrueCrypt volume is in use.

Original answer below:

It is unknown (except probably to Microsoft and the NSA) whether BitLocker has a back door.  You cannot examine the source code to find out, either.  (And even if you could, a purposeful weakness might be very difficult to spot, even for an experienced cryptographer.)

TrueCrypt's source code is available and has (as of today) been audited.  No back doors or purposeful weaknesses were found.  So, speaking only in terms of back doors, TrueCrypt (the version before last) is "safer" because it can be and has been examined by experts.

Test it on Windows 10 before you commit because TrueCrypt is no longer supported by the original authors.


Why do PGP master keys only have a single subkey, and tie certification with signing by default?

I have two viewpoints on this issue: one is based on historical facts (and is a bit technical), while the other is purely my own, original opinion.

Regardless, it seems indeed more secure, or at the very least more convenient, to use a separate key for signatures; that way, you only use your master key for certifications (and can store it away), and you don't have to go over all the certification process again (IRL meetings) if your key is compromised.

Historical facts

After carefully reviewing the C source code of stable GnuPG versions (1.4 and 2.0), I found the function responsible for setting the default capabilities of public keys; the code (in file g10/misc.c) looks like this:

476 int
477 openpgp_pk_algo_usage ( int algo )
478 {
479     int use = 0;
480
481     /* They are hardwired in gpg 1.0. */
482     switch ( algo ) {
483       case PUBKEY_ALGO_RSA:
484           use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG
485                  | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH);
486           break;
487       case PUBKEY_ALGO_RSA_E:
488           use = PUBKEY_USAGE_ENC;
489           break;
490       case PUBKEY_ALGO_RSA_S:
491           use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG;
492           break;
...
509       default:
510           break;
511     }
512     return use;
513 }

I found this function because I first looked at how key generation was done (g10/keygen.c); it is indeed during (sub)key generation that GnuPG may give the "roles" for the keys. Once a master key is created, you cannot change its abilities.

The source code didn't tell much (except that a RSA key for signing also comes with the ability for certifying), but running a web search for the comment (line 481 above) led me to message a posted on 2005-08-03 in the gnupg-users mailing-list, saying:

  GnuPG does not yet distinguish between C and S.  So it does not make
  much sense to have a way of selecting this.

So, it seems that those default settings exist just because GnuPG used to make no distinction between the signature keys and the certification keys.

Additionally, these default settings may be in place because of DSA, as Simon Richter pointed:

  For quite some time, gpg used DSA keys by default, which can only be used for signing, and then had to attach an elGamal subkey (which can be used for encryption only) to get a fully functional key.

  For RSA, that isn't necessary, but it was kept for some reason.

  The "sign only" or "encrypt only" RSA subtypes are not technical limitations on the algorithm.

Original facts

Nowadays, I believe the only reason of that (default primary key capabilities set to SC and not C alone) is to help regular users with verifying signatures.

Let's say you have those two keys in your keyring:

pub  4096R/00000001  1970-01-01       usage: C
uid                  Alice Owl
sub  4096R/AE687A0C  1970-01-01       usage: S
sub  4096R/F77A9AF1  1970-01-01       usage: E

pub  4096R/FFFFFFFE  1970-01-01       usage: CS
uid                  Bob Penguin
sub  4096R/00FF42CD  1970-01-01       usage: E

Alice Owl is a regular GnuPG user, she is confident with OpenPGP and generated a keypair with GnuPG's --expert flag, so she could set her own key abilities. The primary key has the C flag of course, but she signs documents with a subkey.
Bob Penguin knows barely anything about cryptography. The only thing he wants is a bit of privacy/intimacy. He generated his key like any regular user would (without touching any setting he doesn't understand).

Now, let's pretend you – the reader – are a beginner too. You receive signed documents from both Alice and Bob. You know the basics of gnupg, and in particular:

Users are identified with their primary keys:

So I know that Alice is 00000001, and I also know that Bob is FFFFFFFE.

One can verify messages with GnuPG's --verify or --verify-files options.

Now, let's verify the documents they sent to you.

$ gpg --verify from-bob.txt.asc
gpg: Signature made <date> using RSA key ID FFFFFFFE
gpg: Good signature from "Bob Penguin"

$ gpg --verify from-alice.txt.asc
gpg: Signature made <date> using RSA key ID AE687A0C
gpg: Good signature from "Alice Owl"

  Wait, what? I thought Alice's key was 00000001?

Indeed, signatures on documents are not necessarily made with the master key; they are made with the key which has the signature capability (S). It is unlikely a beginner would know about that.

Maybe the actual explanation has nothing to do with this assumption ("the more beginners using SC keys, the better it is for other beginners"), but that's the only explanation I can come up with without bothering the GnuPG contributors.


You might find some helpful guidance from our free Secure Mobile Development Best Practices resource, a collection of 50+ tips to help you learn how to develop secure Android and iOS apps.

Specifically, the practice Implement Secure Network Transmission Of Sensitive Data might help you.

Disclosure: I'm Content Marketing Manager at NowSecure


Is PGP for user authentication a good idea?

You should never try to secure a "real" web application with a scheme that you invented on your own. As such we shouldn't discuss practicalities on how you would actually implement or use such a method.

Will it work?

Your scheme does not send a password over the wire. What immediately jumps out is that you send the private key to the server, which never does anything with it, for no reason. Yes, it is supposedly still protected by the password, but why?

As others have pointed out, the private key is supposed to remain with the owner.

Even if you consider the private key's password encryption, there is the following problems (at least):

Handing out the private key in your scheme is essentially the same as making the password hash public: Anyone can now do an offline dictionary attack against the key's password; and nobody can stop that.
Even worse, they can get the key for a given login, meaning that they can check if a user exists and then attack the password for the user name.

With a small modification, your scheme would be a very simple form of public key authentication:

The client creates a key pair, and sends the public key to the server
To log in, the server sends out a random string.
The client signs the string and sends it back to the server.
The server verifies the signature to make sure the client has the private key

Something like this is actually already possible in https using client certificates. The same thing is used for ssh.

The Challenge-Response mechanism mentioned by ThoriumBR is another way of authenticating, although the implementation described there assumes that the server stores the password in cleartext -- which is much more dangerous than sending it over an encrypted connection.

Will it be "better"?

No. The scenario that you want to defend against is supposedly that someone gets inside the encrypted https connection. If you assume that this is the case, they would not only be able to read the password but also steal your session cookie and all the data that is shown in your session. In that case, the attacker has already won, regardless of whether they read the password or not.

You could of course roll your own encryption and authentication, but the question is why you'd think that this will be better than the https connection?

The realistic scenario isn't that someone breaks the https connection, it is that someone breaks into the server's database and tries to "recover" the passwords in an offline attack. This is what most authentication schemes try to defend against.

The danger with passwords is not that they are interceptable, but that they can be guessed.

What should you do in real life?

For a "real" web application, use an established framework and a well-known authentication library. Don't write it yourself, because it is easy to get wrong and very hard to get right.

Don't use SHA-anything for hashing the passwords, use a dedicated password-hashing function such as bcrypt or PBKDF2 to make attacks more difficult (see this answer also). You can also use or add some TOTP mechanism for your app, which is better than just a password.

Addendum

You added the following after I wrote my answer:

  My requirement is that the only thing users ever need to provide for successful authentication is their username/password and nothing else, regardless of what device they are using or whether they were logged in on that device before.

This explains why you want to send the private key back to the server, although it doesn't change the reason why it is a bad idea.

You could still use a challenge-response mechanism, like ThoriumBR suggested. There are even advanced challenge-repsonse mechanisms such as SRP which use clever math to avoid storing the password on the server.

However, all those mechanisms, and also client-side hashing (see this answer), have one thing in common:

They need to execute code on the client side.

In a web app, this can only be Javascript sent by the server. Implementing the client side is not the problem (there is even a OpenPGP library), but since you worry about the security of the https connection, you have another problem:

Any man in the middle could therefore simply inject malicious client side code to steal the password, rendering your whole clever mechanism obsolete.


What do we do when passwords are not secure anymore?

We have no idea - yet.

Because passwords are insecure because of a combination of factors.

People choose bad (with only X bits of entropy) passwords.
Companies have bad password policy.
Passwords are stored in plaintext.
Password hashes are created with "bad" cryptographic hash functions.

All of these factors are theoretically "solvable".

We could tell people to use stronger passwords.
We could tell companies to have better password policies in place.
We could theoretically fine companies that store passwords in plaintext or when they create "easy" to brute force password hashes.

We (and a lot of other people) have been doing this for a long time and nothing or maybe little has changed. So your question is absolutely valid and has been asked before many times. The problem is, nobody has a good solution yet.

Why is that?
There are several fundamental problems: creation, storage, recreation.

Every factor that is used for authentication a) has to be created by something or someone, b) has to be stored on the client side (to transmit it to the server) and server side (to prove that it is correct) and c) it has to be possible to recreate a new one if it is lost.

All "new" proposals have at least a weakness in one of these categories. Take biometrics for instance:

creation: relatively easy, almost everybody has a fingerprint/veins/a face
storage (client): easy, on your body
storage (server): easy, either plaintext (several pictures are stored) or a hash is derived (both these solutions are suboptimal)
recreation if lost on the server side: not possible

There are other fundamental problems like usability, factor reuse, privacy etc. You can take every new proposal that is in the following list and is the topic of authentication research today and it will fail to solve at least one of the named problems.

What other solutions are discussed?
These: More biometrics (heart rate, voice, walking pattern), n-factor authentication, OTP everywhere, web of trust-like schemes, trust score system (scary!) and others.

In conclusion: We do not know what will come next, but there is a lot of research going on, because not only scientists but also companies are getting tired with all the problems that good old passwords have.


Reflected XSS attack via POST request and XML payload

Attacker can use to auto submittable remote form with the default values. like this :

<form name="x" action="http://site/index" method="post">
<input type="hidden" name='search' value='<script>alert(/XSS/)</script>'>
</form>
<script>document.x.submit();</script>

<form name="x" action="http://site/index" method="post">
<input type="hidden" name='<?xml version' value='"1.0"?><query><script>alert(/XSS/)</script></query>'>
</form>
<script>document.x.submit();</script>

And add a script with XHTML namespace, it will run.
Example

sajjad@xxx:~$ curl http://www.securation.com/files/2013/09/script.xml -v
* About to connect() to www.securation.com port 80 (#0)
*   Trying 5.144.130.33...
* connected
* Connected to www.securation.com (5.144.130.33) port 80 (#0)
> GET /files/2013/09/script.xml HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: www.securation.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 16 Sep 2013 06:01:57 GMT
< Server: Apache
< Last-Modified: Mon, 16 Sep 2013 06:00:14 GMT
< Accept-Ranges: bytes
< Content-Length: 169
< X-Version: Securation 0.0.2 Beta
< Connection: close
< Content-Type: application/xml
<
<?xml version="1.0" encoding="UTF-8"?>
<Query>
    <SearchTerm>
        <script xmlns="http://www.w3.org/1999/xhtml">
            alert('Hello');
        </script>
    </SearchTerm>
</Query>
* Closing connection #0


What is the limit of the number of keys an HSM supports?

I talked to our HSM expert in house. His answer was:

  Errhmm, that's not what HSMs are designed for.

The use-case that engineers had in mind when designing them is like a root certificate authority key, or high triffic web server TLS key; something where a single key needs to do a large number of signature operations.

HSMs will have a finite number of "slots", and each slot can have a finite number of "objects" (ie keys). On really big HSMs you might get up to 5,000 slots with up to 100 objects each.

Because this is a software limitation, not a hardware one, it would be possible to get one big slot with an unlimited number of keys in it, but you may need to place a custom order with one of the big HSM manufacturers to get customized software.


I can suggest the following options based on provided information:

Define data domain (North America, Europe, etc.) according to your criteria and grant roles within that domain only.
E.g., grant Role 1 within data domain A or account S1.
Simple enough, but depends on your data structure.
Add additional conditions in ABAC style, i.e. grant or deny access to specific role if case some conditions are true (e.g., if user allowed Regions = current resource Region)
This approach adds complexity to the solution and its security matrix, but ABAC policies are very powerful and can cover variety of cases.


You have a server which has a secret key. You want to give another party some type of claim (for example, you could give a user a token saying they're authenticated), so you sign it and hand the signed claim to that party. Then they can present that claim at a later time and you can verify:

Authentication: that you signed it, assuming you didn't share your secret, and...
Data Integrity: that the data has not been altered.

If you're sending a claim that another party needs to verify, then use an asymmetric digital signature algorithm, such as RSA. This is called Non-Repudiation and is not a property of HMACs.

Another example: You're sending another server some data that you expect that server to return to you at a later date, but you need to make sure that server didn't tamper with that data. You can sign it with an HMAC.

Ultimately this question is equivalent to: "What's the difference between MACs and DSAs?" and there is lots more reading under that topic.


Validity of a WAF as a Compensating/Alternative Control for CSP, X-XSS-Protection, etc

Content-Security-Policy is an actual instruction to the browser of how a site should behave, specifically where potentially dangerous content can be loaded from and if potentially dangerous actions like inline script are allowed on this site.
A WAF is not a replacement for a strict Content-Security-Policy. A WAF will only apply heuristics to request and response in order to detect potential problems. How good these heuristics are depends on how good the WAF is tuned to the specific application it should protect, but they will usually not be as good as a strict Content-Security-Policy.
A WAF can never protect against attacks which cannot be observed within the HTTP request or response, specifically things like DOM XSS which only run inside the browser. Such things though can be prevented with a strict Content-Security-Policy.
A WAF can help in protect attacks, where the CSP cannot help though, like SQL injection. Still, it is based on heuristics only and proper input validation in the web application itself can be more correct simply because more information are available of what "correct" means.
Still, a WAF can be a valuable tool in a Defense in Depth strategy. But it should not be considered the ultimate and only defense.


Which mobile phone OS implements or plan to implement data protection using keys derived from passwords per NIST SP800-132?

iOS 3 and 4 used PBKDF2 for internal encryption. iOS 5.0 and later provides the CommonCrypto/CommonKeyDerivation.h PBKDF2 library supporting key derivation through CCKeyDerivationPBKDF.

Android 3.0 and later uses PBKDF2 for filesystem encryption.

Windows Phone 7.1 and later provides the Data Protection API that contains PBKDF2 functionality.

Blackberry provides it also but had an issue in the past.

  In September 2010, ElcomSoft announced a password cracking utility for
  Research In Motion BlackBerry device backups that takes advantage of
  what Vladimir Katalov, ElcomSoft's CEO, described as the "very strange
  way, to say the least" in which the BlackBerry uses PBKDF2.
  BlackBerries encrypts backup files with AES-256. In turn, the AES key
  is derived from the user's password using PBKDF2. However the
  BlackBerry software uses only one PBKDF2 iteration, thus not taking
  advantage of the key security features of PBKDF2.


What reputable site should I download Putty from?

The official site is www.chiark.greenend.org.uk/~sgtatham/putty, you can find the download in the download section. If you want to play it safe, you can verify the signature of the download.

In my opinion compiling it from source is as safe as downloading the binary and checking the signature (make sure to also verify the key itself with at least one trusted signer). Unless you review the source code (including all needed libraries) there is no point in spending the added effort of compiling it yourself since both parts, the source code and the binaries, are signed with the same key.

The only advantage you gain by compiling it yourself is the opportunity to review the code so as to mitigate the risk that the authors of PuTTY could have add some backdoors or malware to it.  But again, you would have to thoroughly review the code and all needed libraries to actually gain that benefit.


Hashcat currently (Nov 2018) only supports unsalted PeopleSoft hashes - there's no way that I know of to get Hashcat to apply an arbitrary salt to them at speed. I also haven't been able to determine what the actual algorithm is yet, and neither John the Ripper nor MDXfind appear to have support yet for salted PeopleSoft hashes.


Dangers of passing Oauth 2.0 client id and client secret in the request uri

Should the server not provide an access token to the client if these parameters are in the request uri instead of the body?

This probably makes sense in order to educate programmers (if they don't get an access token, then they'll learn to do it the right way), but it wouldn't make the system more secure if it was under attack. If the client id and client secret were stolen, then the attacker could impersonate the client and get a valid access token by sending a correct request (with the id and secret in the message body).

  What are the possible dangers of posting these parameters in the request uri?

If you use https to communicate with your endpoint and you trust your access token provider, the danger would probably be small.

The client id and secret can show up in your browser history if you're sending them directly from the browser and could probably be stolen from it via malicious javascript, which I'd think would be the greatest risk. (But note that if you entrust browser javascript with your client id and secret, then they are already unsecure...)

The id and secret could also be stolen at the other end of the connection, since they show up in the web server logs of the server you send it to, but because you're sending your client credentials to a provider who already has them, and who hopefully knows how to keep his systems secure, I'd think this wasn't a likely point of compromise.

If you use unencrypted http, then the client id and secret might end up in logs of caches and proxies. Whether somone who sniffs your traffic can see the URL is only midly relevant; since in order to do that he has to look at the request, and therefore could also see the id and secret if they were sent in the request body.


When i check the pcap file of my test run and check my AP it was probing some unknown devices (which can be seen from the pic below). what does this mean?

If I understand your image correctly, you are showing captured data sent by your AP (data removed) to the shown wireless clients. If I am wrong, please let me know.

These entries all show probe responses and this is part of normal 802.11 operation.

When a wireless client is looking to join a wireless network (or check for the possibility of roaming to a new one), they send out probe requests. Often these are general in nature and how a device discovers which networks are around them. Think of it as the client device yelling, "Can any wireless networks hear me?"

Probe requests can also be directed to particular networks. "Can network ABCXYZ hear me?" This is required with the SSID is "hidden" and is the default way many mobile devices try to reconnect to stored networks.

When an access point hears a probe request, if the probe request is either general in nature or for the configured wireless network, it responds with a probe response. This behavior is defined by the IEEE standards for 802.11 networks. So your AP will always respond to any general probe request from a wireless client.

You have likely experienced this yourself without realizing it. When you want to join a wireless device to a network, you have likely been presented with a list of wireless networks and selected the one you wanted to join. This listed was generated largely from the probe responses the wireless client received from APs in the area when it sent out probe requests.

All APs also advertise themselves with beacon frames periodically, which is the other way that clients can find wireless networks in the area. However this is a slower process for discovery, so the vast majority of clients use probe request/responses primarily for discovery.


Yes you can.
This example uses openssl smime with the default RC2 CBC with a 40-bit key. The newer cms sub-command behaves slightly differently, and uses 3-DES by default. You probably shouldn't be using either of those algorithms to encrypt important data ;-)

There are two minor caveats: firstly, I'm also going to use a couple of other tools (though OpenSSL is used for all the heavy lifting), and secondly I'm going to make some assumptions about how the email was encrypted.

The en/decryption is along the lines of most RSA-using methods: use (slow, expensive) RSA to en/decrypt a symmetric key, and use the fast symmetric key to en/decrypt the real data. (See this question or this for more background).

Take your email, extract the P7M part, and decode it. If you have a single .p7m part that is base64 encoded you can do this easily with metamail:

$ metamail -wy enc_mail.eml

Save the P7M file. This is an ASN.1 DER encoded CMS (PKCS#7) file, so we can peek inside:

  $ dumpasn1 -tilda  smime.p7m
   0 1946: SEQUENCE {
   4    9: . OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
         : . . (PKCS #7)
  15 1931: . [0] {
                  [ .. certificate details and whatnot omitted ...]
 188   13: . . . . . SEQUENCE {
 190    9: . . . . . . OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
         : . . . . . . . (PKCS #1)
 201    0: . . . . . . NULL
         : . . . . . . }
 203  256: . . . . . OCTET STRING
         : . . . . . . A0 DA EA FB EA 1A 0F 81    ........
         : . . . . . . F4 30 9F 78 5C 9B A7 27    .0.x\..'
                       [ ... blob snipped ...]
 463 1483: . . . SEQUENCE {
 467    9: . . . . OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
         : . . . . . (PKCS #7)
 478   26: . . . . SEQUENCE {
 480    8: . . . . . OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
         : . . . . . . (RSADSI encryptionAlgorithm)
 490   14: . . . . . SEQUENCE {
 492    2: . . . . . . INTEGER 160
 496    8: . . . . . . OCTET STRING 3E EA 0E 12 37 A8 56 70
         : . . . . . . }
         : . . . . . }
 506 1440: . . . . [0]
         : . . . . . A5 FF A1 70 2C AD 82 6A    ...p,..j
         : . . . . . C7 F0 84 E8 9E 93 8F 53    .......S
                     [... blob snipped ...]

I'm using dumpasn1 because openssl asn1parse is disinclined to display or dump the various blobs we're interested in. The structure of your email will vary from the above of course. Columns 1 and 2 are the offset and size of each (possibly nested) sub-structure.

The interesting parts are at offsets:

188 the RSA encryption details, followed at offset 203 by encrypted data
463 the S/MIME encryption details and parameters (RC2 CBC)
506 the encrypted blob

At offset 188 we can see RSA is used, followed by 256 bytes of data, so extract that data blob (offset 203) and convert it to binary:

$ dumpasn1 -a -203 smime.p7m | tail -qn +2 | xxd -r -p > rsa.bin

(Note starting offset -203 and the use of tail to skip over the first line of output. This is a little convoluted, but unfortunately both dumpasn1 and openssl asn1parse leave the type-length prefix intact when you try to slice and dice objects.)

Decrypt this data using RSA:

$ openssl rsautl -inkey recip_priv.pem -in rsa.bin -decrypt -out rc2key.bin
$ xxd -u -p  rc2key.bin
92F6EB53B1

In this case we get 5 bytes (40-bit) output, the symmetric key we need. The input was PKCS#1 v1.5 padded (see §8.1) for various reasons, hence the size disparity.

The main payload (email) is in the blob at offset 506, extract that to a file:

$ dumpasn1 -a -506 smime.p7m | tail -qn +2 | xxd -r -p > email.bin

Now here's the slightly tricky bit, for RC2 refer to section 6 of RFC 2268:

rc2CBC OBJECT IDENTIFIER
 ::= {iso(1) member-body(2) US(840) rsadsi(113549)
      encryptionAlgorithm(3) 2}

RC2-CBCParameter ::= CHOICE {
  iv IV,
  params SEQUENCE {
    version RC2Version,
    iv IV
  }
}

RC2Version ::= INTEGER -- 1-1024
IV ::= OCTET STRING -- 8 octets

This explains the data structure at offset 490:

 480    8: . . . . . OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
         : . . . . . . (RSADSI encryptionAlgorithm)
 490   14: . . . . . SEQUENCE {
 492    2: . . . . . . INTEGER 160
 496    8: . . . . . . OCTET STRING 3E EA 0E 12 37 A8 56 70
         : . . . . . . }

(You can confirm that RC2Version 160 (0xa0) matches key size 40 bit (0x28) in the EKB table.)

So, putting it all together: the S/MIME encryption algorithm (RC2 40 bit CBC, offset 480), the RC2 key (decrypted from blob at offset 203), the RC2 IV (not encrypted, offset 496) and the encrypted payload (offset 506):

$ openssl enc -d -rc2-40-cbc -in email.bin -out email.txt -K 92F6EB53B1 -iv 3EEA0E1237A85670

and email.txt should be what you're looking for.

Tips:

make sure not to use an ancient version of xxd, it may mangle input hex data
the structure, sizes and offsets will of course vary by message, keys and algorithm
I find openssl enc -kfile ... does not work, stick to -K
openssl smime may have modified your message before encryption (CRLF requirements)
berdump is a handy tool as its output is more amenable to further processing. Since DER is a subset of BER, you can point it directly at a PKCS#7 DER file


SQLinjection prevention: parser + blacklist?

Your approach could probably be bypassed as well, maintaining a blacklist is a "why not" but is definitely not efficient.
Depending on the technical stack you use, I'd suggest you use an ORM which will reduce your risque (but is not risk-free neither)
The best thing you can do is trust no-one: Assume all user-submitted data is evil and validate and sanitize everything:  Escape all user-supplied input; almost every programming language has a bunch of functions to sanitize user input.
Checking the length of the given pram before using it could help also. You can as well, in cases where params are ints, try to cast the string to int before using it.


Flash ignores Content-Type header, allowing XSS?

It means that the standard defenses against XSS when serving user-uploaded content are not sufficient.

The standard defence against XSS when serving user-uploaded content is to serve it from a different address (ideally different domain and IP address completely, but a subdomain stops some attacks at least). That is, you allow it to fall victim to XSS, but isolate it so that such a compromise doesn't hurt the main site.

  For instance, if you want to allow the user to upload an arbitrary text file and serve it to anyone who asks, a standard approach is to make sure to set Content-Type: text/plain on the response. It's widely believed that this is sufficient to be secure

A lot of things that are completely untrue are widely believed.

Content-Type/Content-Disposition was never a sufficient defence, in the face of type sniffing (from both the browser and plugins). text/plain is the worst possible case: because it was (inadvisably) included as a default Content-Type in Apache, most browsers will completely ignote that type in favour of sniffing magic words from the start of the file.

  Has Flash been patched to fix this?

No. Though there's a worse one with crossdomain.xml syntax being buried inside other filetypes and loaded through getPolicy() that has been mitigated somewhat.

  Are there any mitigating factors?

The kind of interaction allowed from Flash under its own variant of the Same Origin Policy doesn't necessarily allow you full scripting into the JS origin. But yeah, it's pretty bad.

Java and Silverlight have similar problems.


Is it safe to use TFTP on a local network

I think you've answered the question yourself mostly: unless there are protections against sniffing inside the network an attacker could be able to see the configuration.

But if this is a problem in your specific environment cannot be decided, because it is unknown if you have protections against sniffing or if the configurations are free from sensitive data.


What prevents ISPs from tracking chain of proxies' (or Tor relays') IP addresses?

So, what prevents ISP from seeing IP address of the first relay I'm connected to?

Nothing. This is the whole point of Tor: this is part of the security model and it doesn't matter that your ISP can see you talking to a Tor node.

  Similarly, what prevents other ISPs of each Tor relay nodes/chain of proxies to see where they route traffic to and from, even when they are located in different countries?

There are two questions here, and one is a legal one which I will ignore as it's off topic here. On the technical side, the idea is that Tor nodes are continuously forwarding traffic for a range of other Tor nodes, so the traffic all gets mixed together and you can never be sure which nodes are initiating a new connection to a new endpoint, and which ones are just forwarding someone else's traffic, or at what point in the chain a node is for a particular conversation. Even if you analyse the traffic, you can't read it, as it's all encrypted in a way that prevents even the individual nodes (apart from the exit node) knowing what the destination is. The exit node itself knows the destination of the traffic, but not the source. The intermediate nodes only know who sent them the traffic and where they should send it next. So, at any point no node knowns both the sender and the destination (and message).

  What stops authorities to contact those ISPs for that information and just connect the dots? It won't give them the data transmitted, but they will know which original IP address was connected to what website/server at specific time over Tor network/chain of proxies.

Same thing as above, mostly. Nation states, however, do sometimes have the capability to identify Tor traffic flow using packet shape analysis. The idea is that you can look at the size of traffic from one person, and look for another outbound packet from the relay that roughly matches the size, all the way to the target. This requires the traffic of all nodes in the chain to be simultaneously monitored, which is quite difficult even for a dragnet solution like PRISM. It's also made harder by the fact that lots of people are passing data between individual Tor nodes, so there are so many packets being sent/received that the "shapes" of the conversations in terms of packet size are obfuscated by the volume of other traffic.


exploiting Heap Overflow in gdb segfaults

There was some very carful algebra done on this site on the variables that manage a doubly linked list of addresses.  Have you investigated the source code in for malloc.c and unlink to see that the code has not changed in some way?  I believe you will find your problem in there.


How to educate users about the dangers of social engineering?

I work as a technical/customer support representative and have to be aware of Social Engineers on a daily basis. The thing is it's hard to explain why it's effective to a group of people that have not done Customer Support. So, here's what I'd have you do:

Have everyone that has worked a customer support job recall that experience (raise their hands and tell stories about pleasing the customer and how that eventually becomes the goal of the position; try to get them to express the mindset of not wanting to let a customer down and specifically if they've ever broken policy for a customer)
Then, transition to how people take advantage of that desire to help the customer (which is typically by pretending to be a person they're not)

That's brief, but basically prepare customers by telling them that
malicious people will pretend to be someone (or something, such as an authority or business partner) to gain information. And that they'll often use information that's freely available to make their story more convincing.

One good activity might be to have people play a game like "two lies, one truth." Ultimately, from my experience, it comes down to having a sound business policy that limits the damages of Social Engineering and prevents it.


Email sender appears to know friend's name?

This is a simple attempt at phishing. It is not hard at all to spoof an email and make it appear as it came from whatever address you want. If you don't open the email you are fine. If you open it but do not click any links or allow to run any scripts you are fine.

How serious it depends on exactly what the email content was and what links they tried to get you to click.  If you clicked a link and it looked like your bank's page, then yes call your bank and put extra security measures on your account.

How this comes about would be if one of your facebook friends has security set to allow anyone to view their friend's list, or their account was compromised.  That si how they learned of your connection to the person whose address they spoofed the email. The reasons for doing this is because if you think if the email is from someone you know, you are more likely to open it and handle it as trusted.

How they got your email address is another thing to think about. If your facebook friend has their friends list set to public, that still would not reveal your email address unless you have your email address visible to everyone. If your email address is set to be visible to only friends, then one the attacker friended one of your facebook friends ( which isn't hard to do) and that made your email address visible to the attacker. I set my email to visible only to me. This is what I recommend because you cannot control the security practices of your friends or keep them from accepting friend requests from attackers.

Another possibility is they had your email address to begin with, from some other means, and perhaps your friend list is set to public, so they started with your name, then got your email, and then got your friends list so they could craft an email that looks like it is from someone you know and trust.


Are DTMF tones decoded by the DTMF producer?

DTMF signals have no inherent meaning - they just transmit the pressing of a key on the phone. It makes though only sense to decode these if there is an application which actually expects to interpret these key presses in a meaningful way and then acts on the extracted information. And it makes no sense to decode these information on the senders side since there is nothing gained from decoding these.

That said, it might of course be possible that DTMF decoding is part of some software library or chipset which gets also used on the senders side and which due some misconfiguration or bad design will always attempt to decode potential DTMF signals, no matter if some applications expects to make use of the extracted information or not. It is only unlikely, i.e. either is not done or is uncommon.


I assume you're talking about a challenge certification; any other route would provide you with all the courseware you need.

As per the GIAC FAQ:

  Please review the course descriptions at http://www.sans.org to gain
  an understanding of what material is covered in each course. Please be
  sure to look at each day of training. While we certainly recommend the
  SANS training as the best method of preparing for the GIAC
  Certifications since that is what they are based on, other resources
  can be purchased at most book stores.

The exams do track the courseware closely, so it really is the best guide.  That said, I don't believe they sell the courseware alone, and selling used copies is likely against the license.  I do recall that once upon a time they would sell off extra courseware in the bookstore at conferences - e.g., they ship in 100 copies of GPEN, 90 people show up, they have 10 copies to either sell to conference attendees or box up and ship back.  So there was a legitimate sale method at least at one point.  (I purchased the GCUX set at a conference intending to challenge, but never got around to it).

You do also get two practice exams if you sign up for the challenge, which gives you a chance to figure out what topics you should study but haven't yet.  If you already hold a GIAC certification and are on any of the related mailing lists, people often give away practice exams they didn't need, maybe that would let you figure out if you want to try this before spending $1,050 to get your own practice exams.


What considerations do I need to keep in mind when enforcing passphrases?

It is not necessarily a bad idea. The attacker can know the password is in that format, considering the 4 words are random enough. But here is the thing, there are other good ways to make a memorable strong password. Limiting your users to the one you like is not very nice. For example I use password manager with truly random long passwords, which is even better than what you propose, but I could not do that on your site.

More importantly, if the reason you want to do this is to force users to use strong password, then generate the 4 words password for them. You can generate such password by having a dictionary, then choosing random number between 1 and the number of words in your dictionary and taking that word. Do this 4 times and you have a password. You can get inspiration here. This is important, as most users may not choose 4 truly random words, but instead 4 easily guessable words. In such scenario, this would be worse then letting them choose any password.


Using BITMAIN AntMiner L3+ for cracking password

You cannot crack passwords using a cryptocurrency ASIC. These ASICs are extremely limited in what they can do. This is especially true for your miner, which is designed for Litecoin, a cryptocurrency that uses scrypt, which is not commonly used for hashing passwords (though it is useful for doing so).

A cryptocurrency mining ASIC is not simply hash-acceleration hardware, where your computer prepares the data to be hashed and the device returns the digest. What actually happens is that the device does everything by itself, preparing the data to be hashed and verifying the block's integrity. Think of it like a car. While a car has a reciprocating engine, you could not take a car and turn it into a propeller airplane, despite both using the same type of engine. You would need to strip it and remove each component, throwing away a lot of what makes the car a car. The same is true for a mining ASIC, except that the components are so small and tightly integrated that it cannot be disassembled and re-purposed.


How often do brute force attacks find the password or key in a much shorter amount of time than the theoretical max?

What are the chances that the key is the very last key for the brute force attack to check?

If there are N keys, the chance is 1/N. If you have n bits of entropy, that means the chance is 2-n.

  ...if it's one of the keys in the first 10% of all keys to be checked by the brute force attack?

Given that the key is random, the chance of a brute force search finding it within the first X% of tries is X%. So the chance of finding it among the first 10% is 10%. If a full search would take 10 years, the probability of the key being found within one year is 10%.

Forget about the crypto here, this is just statistics. If you have 1 000 cookies, and one is poisoned, how big is the probability that you die if you eat 10?

  Does the huge size of the search space (for 128-bit, 3.4*10^38) reduce that possibility to an acceptable risk level?

Yes. If the keyspace is large enough, the risk of an attacker getting lucky is neglible. A full search of the AES-128 keyspace would take about 100 times the age of the universe. If you had spend all the time since the big bang brute forcing a key, you would still only have a 1% chance of cracking it. And if you only give yourself 100 years, the odds drop to 1 in 1010.

  Has this ever been tested? Has anyone ever generated hundreds/thousands/n of keys and then tried to brute force them for a short time to see how often the key is found in minutes/days?

For small time periods, you  have just a big a chance of finding a match if you try to crack one key all of the time as if you divide the time over multiple keys. So again, if you spend 100 years trying billions of keys for a little while, the chance of you getting a hit is close to zero.


A block cipher like AES is deterministic: for the same key and the same input, you get the same output. Since real-life data tends to exhibit redundancy, this makes ECB, the most basic cipher mode, quite weak. CBC tries to avoid that issue by "randomizing" the input blocks, through a XOR with the previous encrypted block: the idea is that the output of a block cipher should look "random enough". The AES is still deterministic, but the randomization ensures that the risk of collision will remain very low (AES has 128-bit blocks, so the first collision should be encountered after encrypting, on average, about 264 blocks, which is 256 exabytes, aka "an awful lot of data"; this will not happen often). Since the first block has no previous block, we need an "artificial previous block" and that's the IV. Therefore, the IV should be "random looking".

A first basic observation is that a simple +1 policy on the IV may fail to be random enough. Imagine that you encrypt messages which contain some data as a list of "key = value" pairs (e.g. the standard encoding of a Java Properties object), and that all the messages begin with userPassword = thepassword (for various user passwords). With AES, and its 16-byte blocks, note that the first block ends immediately after the first letter of the password. So the successive first blocks will be almost identical, save for their last byte. Suppose that the IV and messages are:

IV                                  message
--------------------------------------------------------------------------------
5c17eacc047fd32fdecc2e0f226e4e86    userPassword = mypassword
5c17eacc047fd32fdecc2e0f226e4e87    userPassword = PaSSwo3D!
5c17eacc047fd32fdecc2e0f226e4e88    userPassword = bob
5c17eacc047fd32fdecc2e0f226e4e89    userPassword = z!Ghj0$.\+
5c17eacc047fd32fdecc2e0f226e4e8a    userPassword = anotherpassword
5c17eacc047fd32fdecc2e0f226e4e8b    userPassword = correcthorsebatterystaple

If you work out the values for the first block passed as input to the AES for each message, you will find that for the first and fifth message you end up with the same block (29648fbe541ea05ca9a35c6b02536ee7). So the first sixteen bytes of the two encrypted messages will be identical. By spotting that equality, the attacker will then deduce exactly which bits differ in the first byte of each password. By observing many successive messages, the attacker may accumulate quite a lot of such equations on the unknown data. This is exactly the kind of leakage that good encryption should avoid.

The situation is made much worse in the presence of chosen-plaintext attacks: these are attacks where the villain gets to choose part of the plaintext. In the example described above, suppose that the attacker is one of the user, and his password is in the first message. Thus, the attacker knows that his password begins with an 'm'; by observing the encryption of the successive messages, he then infers that the password in the fifth message begins with an 'a'. Moreover, the attacker may change his password and have another go, getting information on other passwords, and so on.

The recently advertised BEAST attack builds on a CPA, in a more realistic scenario involving a Web browser, an HTTPS connection, and a "secure" Paypal cookie. The cornerstone of the attack is that data in a SSL connection is broken into "records", each record being encrypted in CBC mode, and the last block of a record is used as IV for the next. The attacker then forces some data of his own into the connection, observes the first record, and computes from that the data he then adds (which will be encrypted as the second record), so that the first block of that data XORed with the IV yields a predictable value. The details are intricate, but end up with revealing the secure cookie. For the attack to work, all the attacker needs is a predictable IV, which he gets by observing records (TLS 1.1 fixes that by adding per-record random IV).

To sum up, the BEAST attack demonstrates that CBC with an IV that can be predicted by an attacker who can do chosen-plaintext attacks, is weak. A +1 policy for IV management leads to IV that can be easily predicted. Therefore...

One shall note that while CBC requires random, uniform, unpredictable IV, not all block cipher modes of operations are that picky. Many cool newer modes, especially those which combine encryption and integrity check, can live with non-repeating IV even if the IV values are totally non-random (e.g. EAX or GCM); for them, a +1 on IV is perfectly fine. In some protocols, this allows for an implicit IV (a sequence number, for successive messages sent over a wire) which may save a bit of bandwidth.


For establishing the message integrity, yes, HMAC-SHA should be fine.

The one concern you might have is in the case of a man-in-the-middle attack where the message might be intercepted, the counter changed, the HMAC regenerated and the modified message passed on to the original recipient. In this case you could look at using a public key algorithm to sign the HMAC hash(effectively a digital signature) to authenticate the sender.

Edit: not a concern unless your keys get into the wrong hands.


CISSP Cert: can an IT sales pro pursue CISSP?

The CISSP is certainly useful to have.  You may have to apprentice under somebody in order to meet the experience requirements.  You can do the course and pass the exam, but make sure you are within 9 months of the experience requirement so you can get your endorsement when you meet that.

Companies, particularly start-ups, should be willing to hire security interested, but uncertified people for this kind of work.  It will come at a discount base pay wise, but if you can afford that it's a good stepping stone.

Another alternative would be to join a security-products or services company as a technical sales person or product manager and make a point of getting technically involved to bridge the experience gap.

You could also start security consulting for small businesses without certification on the side if you have time.  You can build experience there.


For "impossible to recover" you need to physically destroy the disk, I´m afraid.

Of course, depending on your threat model, you may very well be comfortable with something less drastic. In which case, you probably have at least one of shred, srm, or wipe bundled with your Linux distro.


Email headers from messages sent via Gmail online client contain private IP addresses. What are these addresses?

When reading a raw email message including all of its headers, the Received: headers are best read from bottom to top. Here, I'll show an example of an email I've received on my GMail account

Delivered-To: MYEMAIL@gmail.com
Received: by x.x.x.x with SMTP id xxxxxxxx;
        Tue, 3 Sep 2013 xx:xx:xx -0700 (PDT)
Received: from a.b.c.com (a.b.c.com. [x.x.x.x])
        by mx.google.com with ESMTP id xxx;
        Tue, 03 Sep 2013 xx:xx:xx-0700 (PDT)
Received: from localhost (127.0.0.1) by a.b.c.com id xxx for MYEMAIL@gmail.com>; Tue, 3 Sep 2013 xx:xx:xx +0000 (envelope-from <bounce-xxxxxxxx@c.com>)
From: xxxx<xxxxx@xxxxx.com>
Sender: xxxx <xxxx@a.b.c.com>
Subject: xxxxxxxx

When you want to send an email, you give it to your service provider who will attach the first Received: header, and as the message passes through different relays and mail servers, each one of them attaches its own address until the message reaches its final destination - the recipient's service provider.

So what you're seeing there in the first Received: header is actually GMail's server. That's why you have it in all of your messages, because that's where all the messages end up in your case, in your account on GMail's servers.

Please note that there's really no way to reliably identify the IP address of an email sender. However, Received: header chain can give you some idea.


Does splitting RNG into "private" and "public" entropy sources reduce risks of compromise?

Let's look at how such a thing might play out:

A classic example is the Dual-EC DRBG which employees a back-doored RNG to create a general attack against TLS. The other half of this attack beyond the vulnerable RNG is a mechanism for revealing to the attacker the state of the RNG at the time of use to allow the attacker to predict the remaining "random" content as produced by the victim's RNG.

So there's a non-standard feature implemented in TLS called Extended Random, through which a TLS server just dumps a bunch of output of its RNG into the TLS negotiation, which is revealed to anyone eavesdropping on the conversation. In fact, it's been calculated that this feature improves the Dual EC attack by a factor of 64000X.

So a system which uses a different RNG for the "Extended Random" component than for key derivation would be significantly (64000x) better protected against this attack.

But not completely immune. The RNG is vulnerable in itself, even if you keep your "high-value" randomness separate. A second RNG instance is useful, but not foolproof.

The goal of such a system is to protect against the unknown, so measuring its usefulness is difficult at best. And other protections may work better.

For example, random values XORed with anything is still random. So if your application runs multiple RNGs and XORs their output, then the quality of the randomness you get is equal to highest quality of all the input RNGs. So if an application XORs a whole list of RNGs of varying quality, then if any one of the RNGs is safe, then the output will be safe as well.

So how good would this technique be in protecting against unknown threats? We don't know. But what we can say is that it would protect against known threats such as the Dual EC backdoor mentioned above.


From your description, it looks like all you need is the timestamp, process name and the source port (since you identify the malicious traffic externally and have access to the timestamp and ports used). This can simplify things tremendously.

Run netstat with a grep every second and capture the processes and source ports to a log (export log to central logging server). Log contents are smaller this way, although you risk missing a short-running process if it fires in between your capture times. A little hacky, but effective, and I've done it.

You can also try logging aggregators or endpoint protection programs that log into the workstations to poll for this info. The performance, cost, and complexity will depend on the number of workstations in play, though.


Deriving and storing an AES key for SQLite DB on iOS

Put it in the keychain.   This is exactly what it's there for.  What it does, is to encrypt the keys when they're not being used by your app, and to limit access to them to your app alone.

Simply have the application securely generate a new random key on first use, and store in the keychain for re-use on subsequent launches of the application.  This way you're using systems designed for these purposes, every device has a unique, high-entropy key, and you're not limited by the inherent weaknesses of password-bases systems or the pitfalls of roll-your-own-key-storage mechanisms.


Eavesdropping on WPA2 networks are not that trivial as in WEP or Open networks. Certain conditions need to be met (such as distance to the AP, frame rate and lack of beamforming) to be able to really decrypt the traffic. More information can be found here.

Also, you need to check if your POP and SMTP are sending information in clear text. Most of the email solutions nowadays support SSL, so your credentials most likely would be encrypted. You can check that on your email client configuration.


Is Qt framework is under attack or it has something suspicious (only in free version)

Before going brief ,I have noted the following things from your question :

You were visiting the mirror site of some malicious website
The official link differs from the url which you have downloaded

I was able to reproduce the problem while analysing the mirror site and it was flagged as malware as per the virustotal report

Now as you haven't downloaded the image[my rough guess] ,you might be safe from the vulnerable file ,if you have accidentally downloaded it try to remove the file completely and run some AV Scans.

Other than that there were less chances for you as MITM victim,If you still doubt it run a quick traceroute to your router ,if it shows external IP you might be a victim,Also have a look at the MITM question which was asked before over here .Also download the file from official site and verify by generating its checksum.


The IP you connect from will be available to the computer you access.  The sites you access in a web browser from that computer will only see a connection from that computer, and will not be able to determine the IP you used to connect from on Teamviewer.  If you run any applications outside the web browser, it would be possible for them to detect the incoming connection, but only if they are specifically looking for it.


Is it ever safe to open a suspicious HTML file (e.g. email attachment)?

Editors, and common libraries used by editors, may have vulnerabilities like buffer overflows. Your attacker would need to know (or guess) what editor you use and craft an exploit specifically for that editor (different editors are unlikely to have the same vulnerabilities unless the vulnerability resides in a library they have in common). An attack may be aimed at a popular editor and send out to as many people as possible, essentially turning it into a "spray-n-pray" attack.

Attack Surface

A very simple editor like Microsoft's Notepad has a smaller attack surface than a more advanced editor (like Visual Studio Code). More code generally means more potential vulnerabilities.

Mitigations

Certain mitigation techniques like Address Space Layout Randomization (ASLR), Data Execution Prevention and having an anti-virus with an "exploit blocker" (these are generally capable of recognizing basic overflow attacks, among others) may help to render certain attacks useless.

Software Updates

All of these techniques are of course no substitute to keeping your software (ALL your software I might add) up-to-date. Keeping your software updated is the best security strategy one can have. This is sometimes overlooked or trivialized due to its lack of feedback. An anti-virus yelling at you that "You are protected!" sends out a much stronger signal than a software update that silently patches vulnerabilities in the background. I tend to compare an anti-virus program with a person sticking their fingers in the holes of a dike to prevent the water coming through. It does its best to keep the flood out but chances are it's not going to have enough fingers to fill all the holes (or miss a few altogether). Software patches fixes those holes.

Bottom Line

You can never be sure you aren't going to have a bad day by opening any type of file in any type of program. However, some programs (like editors) are much harder to attack due to their small footprint or secure design and therefore are less likely to be targeted for mass attacks (especially because an attacker is likely to assume their evil .html file is going to be opened in a browser, not in an editor).


Unfortunately, this seems to be a poorly done configuration on the school's part. I also have a Gmail account managed by the school that is tied to the school's SSO. The only thing you can do is talk to your school's IT department, and hopefully they will fix their mistake.

In the mean time, enabling 2-factor sign-on will protect your account from compromise until you can get your passwords sorted out.


I would say as a generalization that bare-metal hypervisor is more secure.
As with any system when you add more software you add more attack surface.
So let's take any hosted hypervisor out there. Instead of just dealing with the hypervisor attack surface you also have the OS vulnerabilities to worry about.


Are keys or RFID tags more secure access control solutions?

Conceptual view: there is authentication, and there is authorization; these are distinct activities. Authentication is about making sure of who you are talking to; authorization is about deciding what some individual is allowed to do. You actually want to keep them separate.

RFID tags implement authentication: through the electronic conversation between the tag and the reader, the reader ascertains the identity of the tag, so (presumably) the identity of the tag holder. Authorization is performed by the reader, that can be linked with some central authorization server. On the other hand, with a key, authentication and authorization are conflated in the same device: having the key in hand automatically grants access.

The need for separation of authentication and authorization is made most visible when you want to revoke an access. With RFID tags, that's easy: simply flip some flag in the authorization server database. With keys, you cannot do that: to revoke an access, you must either recover the key itself (and you cannot do that if the reason for revocation was that the key has been lost or stolen), or change the lock (and that's expensive, not only for the lock itself, but because you must distribute a new set of keys to the other users). In a similar vein, with RFID tags you can enforce time-based access control (access granted only at some times in the day), and you cannot do that with keys.

Another good property of RFID tags is selective cloning. When a new employee must be granted access, issuing a new tag for him is easy for the system administrator; but users themselves will find it hard to clone their tag (good tags are like smart cards: they are tamper resistant). This means that authorization management remains in the hands of the sysadmins. With keys, either keys cannot be duplicated, in which case granting access to new users is hard, or keys can be duplicated, in which case preventing rogue cloning by existing users is hard.

Summary: RFID tags are superior to keys because they allow for fine-grained access control with immediate revocation, and centralized authorization and administration.

The most salient point which would make keys preferable over RFID tags, in some specific contexts. is that keys don't need to be powered. A padlock which has been locked, remains locked even after an extended power outage. However, in most cases, RFID tags are better.


Doesn't HPKP become useless after the max age has expired?

Yes, after the timeout is reached, the pin is no longer effective. But the expectation is that you will eventually visit the page again before your pin expires, thus refreshing the timeout again and updating the pins. It can be dangerous to never let a pin expire because you could lock out previous users forever if you accidentally let them pin the wrong key just once.

  Isn't it obvious that an attacker will wait until their max age is expired and then perform the attack?

Such an attacker has to be very patient and make a few assumptions. The victim may not visit the site regularly since that would extend the timeout on each visit. Additionally, the attack has to be still feasible after that time. Two months can be long for a CA breach to remain undetected.

Ultimately it's a trade-off which RFC 7469 ("Public Key Pinning Extension for HTTP") explains in the section on Security Considerations:

  4.1.  Maximum max-age

  [...] There is a security trade-off in that low maximum
     values provide a narrow window of protection for users who visit the
     Known Pinned Host only infrequently, while high maximum values might
     result in a UA's inability to successfully perform Pin Validation for
     a Known Pinned Host if the UA's noted Pins and the host's true Pins
     diverge.

(UA = User Agent, meaning your browser)

The RFC recommends an expiry time around 60 days (which is exactly the time Github uses):

  There is probably no ideal upper limit to the max-age directive
  that    would satisfy all use cases.  However, a value on the order of
  60    days (5,184,000 seconds) may be considered a balance between the
  two    competing security concerns.


What are the risks of just clearing cookies instead of logging off?

Can I just log out by wiping cookies instead of hitting logout?

Frequently yes, for the reasons you supplied in your question: Without the session token in your cookies, a typical web application won't know who you are.

  What are the issues of just wiping cookies versus clicking the logout button?

Web applications that manage authentication following the OWASP session management guidelines will invalidate the session on the server side when you log out explicitly.  If you simply discard the cookie with the session token, the session may be subject to session hijacking.

Using door locks as an analogy for those who are not familiar with best practices of developing web applications (thanks to discussion in the comments):

Your account can be seen as a room in a building. When you log in, the building's owner creates a door and puts an automatic lock on it, so that only you can enter.  Your session token is your key, and is typically stored in your browser's cookies, but can be stored in other places.

Discarding your token by deleting your cookies, clearing cache, etc., is simply destroying your copy of the key.

Explicitly logging off is asking the building owner to brick up the doorway. There's nothing guaranteeing that they'll secure your account, but as the user, you're explicitly making your wishes known.

There are various ways that an attacker can get a copy of your key, known as session hijacking, that are the responsibility of the site owner to mitigate, not the users.

First, the attacker can just guess. If the site generates session keys sequentially, or uses a low entropy pseudorandom generation method, this makes guessing much easier. Sites mitigate this through using high entropy tokens and periodic session recycling. Recycling sessions doesn't prevent access, but it makes it obvious when unauthorized access has been granted.

Second, the attacker can use session fixation: They give you a key before you log in, which you continue to use after you've logged in. Sites mitigate this by explicitly recycling the session when you log in.

Third, a Man-in-the-Middle attack. The attacker can see your key directly.  TLS mitigates this. It is possible to decrypt TLS traffic through downgrade attacks, insecure implementations, and zero-day attacks, but these are far outside a user's domain, rare, and zero-day attacks against TLS tend to raise a LOT of noise when they're discovered (Heartbleed, et al).

As a user, your responsibilities are to log off and to hold the site accountable when they take shortcuts with security, much as your responsibility with your car in a public parking lot is to lock your doors.  If the door locks are trivially bypassed, then its the manufacturer's fault, not yours.