TL;DR Go with implicit... Check Which OAuth 2.0 flow should I use? for a visualization of the decision process.

When it comes to authentication, the devil is on the details... I'll try not to forget of any.

The base OAuth2 specification introduced four grant types:

implicit grant
authorization code grant
client credentials grant
resource owner password credentials (ROPC) grant

If you exclude ROPC which was included to provide a seamless migration path for applications that used to store the username and password in order to be able to act on behalf of the user, you're left with three possible grants.

Among these three, you make a clear distinction between the client credentials (CC) grant and the other two. The CC grant is aimed at client applications that want to access resources on behalf of themselves, that is, with the identity of the client application itself.

This implies that in order to use this grant a client application must be able to perform client authentication in order to prove that the request is coming from the legitimate application.

A SPA cannot perform client authentication because any secret, key that you store in the application as a means to authenticate would be visible to anyone that wanted to look through the source code. The CC grant is then restricted mostly to server-side applications where keeping a secret is easier.

Another major point is that if you want your client application to access resources owned by an end-user and/or perform actions on their behalf then the CC grant is not applicable.

It seems the pool of choices is now half of what we started with and the remaining candidates are the implicit or authorization code grant. In general, if you have a SPA the code performing the requests requiring authentication/authorization is on the browser-side so the obvious choice would be the implicit grant because it delivers the tokens as part of the authorization endpoint response and does not require an additional request to the token endpoint which in browser-land could signify a CORS request which might or might not be feasible.

As an additional note, if the components you described (Front-end SPA and Back-end API) are seen as a single application living under the same domain, with no plans on opening the API to other applications it should even be feasible to rely on traditional HTTP-only cookie-based authentication that would be bootstrapped by an ID Token received according to OpenID Connect rules. You mentioned REST so just want to make a disclaimer that cookie-based authentication does not necessarily imply a server-side managed session; however, cookie-based authentication would require CSRF mitigations.


Brute force alphanumeric password using JohnTheRipper

lowercase + numbers

Incremental actually has a predefined mode for lowercase + numbers:

[Incremental:LowerNum]
File = $JOHN/lowernum.chr
MinLen = 1
MaxLen = 13
CharCount = 36

From the documentation:

  "LowerNum" (lowercase letters plus digits, for 36 total)

Just adjust MinLen and MaxLen.

Create new incremental mode with certain characters

If you want to create your own chr file with a customized set of characters, you would do it like this:

john --pot=YOUR.pot --make-charset=YOUR_NEW_FILE.chr --external=filter_lowernum

filter_lowernum is the filter which determines what characters will be in your chr file. It is defined in your john.conf (under [List.External:Filter_LowerNum]), and you can create your own filters there as well. The code for LowerNum looks like this:

[List.External:Filter_LowerNum]
void filter()
{
    int i, c;

    i = 0;
    while (c = word[i++])
    if (((c < 'a' || c > 'z') && (c < '0' || c > '9')) || i > 13) {
        word = 0; return;
    }
}

Then just add the incremental filter to your config.


Do human challenge-response authentication schemes exist?

I might be wrong but very spontaneously:
The password authentication scheme has an obvious flaw: The authenticating subject needs to send a secret in clear text in order to prove her identity. However, password authentication is widely accepted. Why? Because it is practical to use and easy to understand. If there were really good alternatives none would use password authentication any more. Everything that fixes the above flaw requires cryptography which requires math and computational power.

The only one I can think of are mechanisms which don't reveal the full secret in one run. Think of a 2nd-factor authentication where the server asks you for digits 2 and 7 of a 10 digit number and next time it will ask you for 1 and 3. An eavesdropper needs to log a lot of authentication attempts before (s)he has a reasonable chance to logon successfully. But this is not really what you are looking for.

A while ago, someone posted this on security@stackexchange. Maybe it is closer to what you are looking for but I don't think it can work, as someone commented

  Security at the expense of usability comes at the expense of security


What kind of security injection are these traces of, SQL, javascript, or otherwise?

injected_by_wvs is used by Acunetix Web (w) Vulnerability (v) Scanner (s) (wvs). This is a Cross (x) Site (s) Script (s) - XSS - which is being inserted into a parameter (usually a form: name, date, time, age, etc). SQL based injections will contain a portion of a SQL statement (SELECT * FROM, INSERT INTO *), which are visible most of the times but can be obfuscated. That answers what kind of attack this is.

You may want to look into using escapeshellcmd() versus exec() to prevent someone from trying to insert characters. I disagree with the statement HamZa DzCyberDeV made with regards to exec(). It is not that serious if you take the time to sanitize input.


There are a few items in addition to what you've written that I would add.

Rename your admin account - Yes this might be a pain in the ass (especially if you've got services using the domain admin account) however this is a commonly attempted brute force username. Rename this account to something ambiguous that won't easily be guessed.
Don't use common names for accounts - If you audit the security logs you'll notice that a good chunk of the login names are common names (Administrator, admin, sql, sa, besadmin, guest, etc). Ensure that you are either not using these usernames, or if you need to use the username ensure it doesn't have the rights to logon to your remote desktop server
Enforce an Account Lockout Policy - With your administrator account renamed and your other service accounts renamed or not given access to the remote server, this will disable someone's attempt to login with that username. Make sure you set this as a local policy on the remote server and not a domain policy. Users will attempt the wrong password with your account for X amount of tries, get locked out and move on to the next IP address.
Investigate TS Gateway - TS Gateway allows for your RDP sessions to connect to your network via the standard SSL port of TCP 443. This will allow you to completely shut off port 3389 from the outside world. The one pitfall I've found with this technology is there is no free Mac RDP client that will allow you to utilize TS Gateway so if you have Macs you'll either need to pay for the client or disrergard TS Gateway.
Windows SSHD_Block - A talented SysAdmin by the name of Evan Anderson wrote a nice little VBScript that will block IPs attempting to Brute Force your Terminal server. Check it out HERE

Hope these little tips and tricks help you secure your network.


Will Veracrypt work on a LUKS encrypted system?

You can encrypt your USB drives using Veracrypt for as long as you install Veracrypt software on your Linux (so you would be able to access them from Linux).

You are using LUKS to encrypt partition(s) on your hard drive but once you boot-up the system, you can work on it just as it was not encrypted and use Veracrypt.

You need to distinguish the difference between the system/partition encryption and file/container/folder encryption. First is LUKS (I know, you can use Veracrypt to do it, but since you have your system encrypted by LUKS, there is no point to encrypt it again with Veracrypt), the second is Veracrypt - very good for file/container/folder encryption on a host system or portable drives. It is important to remember, that you would need to install Veracrypt OR put portable package along with encrypted files on any system that would need to access your portable (for instance USB) drives. You would also need admin rights on these systems to use portable package.
You can copy the encrypted containers wherever you like.

LUKS has nothing to do with your USB drives, Veracrypt has, you can encrypt them with any Linux compatible software you like. You can even encrypt files you keep in the cloud to protect them from being viewed by unauthorized individuals (in case of security breach) or personnel of your cloud provider.

Both types of volumes will work fine and yes, it is safe.


Can I use Truecrypt/Veracrypt to "Wipe" a partition?

Yes, you can securely overwrite an entire partition by using TrueCrypt or VeraCrypt. Select the partition for encryption, and enable a single secure overwrite. You do not even need to select a secure password, as the master key that is used to overwrite the partition is already generated randomly. Note that you would want to create a new encrypted partition, not encrypt an existing partition in-place.

The only difference between encrypting an existing partition and creating a new partition is that the former will be less efficient due to reading from the entire disk as well as writing to it, and will also require you use a secure password. The latter technique is faster, just as secure, and does not require you use a secure password to effectively destroy all the data on the partition.


Should a DNS server restrict reverse lookups from external hosts?

I've never seen a DNS server that does not allow reverse DNS lookups (PTR record lookups).  Moreover, if a DNS server didn't allow reverse lookups, I think that could cause some things to break.  For example, if one of the hosts were used as an outgoing SMTP server, and it was not possible to do a reverse DNS lookup on the IP address of that host, then this would cause mail delivery failures.  See https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-reverse-dns/

Note that the PTR record (used for the reverse dns lookup) must be stored in the zone file for the IP address, not the zone file for the domain.


When to use only biometric authentication?

I am of the school of thought that Biometrics are NEVER acceptable to use as the only authentication method, you leave your Biometric data everywhere, it is almost a security paradox. I can lift fingerprints off of your keyboard, car, or elevator panel, I can make a voice recording of you, I can take your picture, get your face off a security camera, and I am Bad Guy Bob - I will jump you at your car and cut off/scoop out whatever I need.

Some other examples/articles of people who think BMs are negligent to use:

http://www.makeuseof.com/tag/6-reasons-biometrics-not-way-future/
http://www.usatoday.com/story/cybertruth/2013/09/12/why-biometrics-dont-work/2802095/
http://www.csoonline.com/article/2891475/identity-access/biometric-security-is-on-the-rise.html

You also have to realize that there is an error-of-margin built into these Biometric security solutions, all it takes is for your to roll your finger on the scanner wrong or squint with a retinal scanner for it to scream at you and say ACCESS DENIED - making them easier to defeat, and unlike changing a password, or salting a hash, you cannot change your fingerprints easily nor change your retinas - once you are compromised, and use biometrics extensively, there is no way to quickly change.


How to disable email for a subdomain without using SPF

I have a possible solution for you. As RFC 7208, Section 4.6.4 states:

  Some mechanisms and modifiers (collectively, "terms") cause DNS
  queries at the time of evaluation, and some do not.  The following
  terms cause DNS queries: the "include", "a", "mx", "ptr", and
  "exists" mechanisms, and the "redirect" modifier.  SPF
  implementations MUST limit the total number of those terms to 10
  during SPF evaluation, to avoid unreasonable load on the DNS.  If
  this limit is exceeded, the implementation MUST return "permerror".
  The other terms -- the "all", "ip4", and "ip6" mechanisms, and the
  "exp" modifier -- do not cause DNS queries at the time of SPF
  evaluation (the "exp" modifier only causes a lookup at a later time),
  and their use is not subject to this limit.

  When evaluating the "mx" mechanism, the number of "MX" resource
  records queried is included in the overall limit of 10 mechanisms/
  modifiers that cause DNS lookups as described above.  In addition to
  that limit, the evaluation of each "MX" record MUST NOT result in...

You could make sure you put enough includes and other DNS overhead in your dangerous SPF record to make sure it fails the 10 DNS lookup standard. add the MX directive and throw in the includes for services (Google, Salesforce) until your SPF record fails SPF Survey for exceeding 10 DNS lookups. Your dangerous SPF record will then look valid but it will fail for a reason that most people don't know about, thus both SPF and DKIM will fail.

Providing I understood your question correctly, this should yield the result you want. Is this the sort of solution you were looking for or did I misunderstand something?


How to secure data before returning Macbook Air?

Found this answer on Apple.StackExchange.com.  Since you have a 2012 MacBook Air I will assume that you have Lion.  If true and since you say that you are using FileVault 2, this procedure from this answer should work for you:

If your MacBook Air supports Lion Recovery Mode, and your using full disk encryption such as FileValut2 you will not need anything else to do it other than follow the steps below.

Boot your MacBook Air into Recovery Mode by holding down Command+R
while booting it.
Open the Disk Utility Program, select the drive you want to securly
erase.
Select the "Erase" tab
Click "Security Options..."
Drag the slider to the Most Secure setting or some where in between
and then select "OK"
Then click "Erase..." and follow the remaining on screen prompts.

Note: For more information on how secure the Disk Utilities Secure Erase feature is see About Disk Utility's erase free space feature


On company intranet yet web server picked up URL scanning-type requests?

It appears that someone scanned your web server with nmap, based on the match with one of nmap's scripts:

$ grep nmaplowercheck *.lua
http.lua:  local URL_404_1 = '/nmaplowercheck' .. os.time(os.date('*t'))

which is what would cause this request:

20 01 2017 13:47:50.097:WARN [web-server]: 404: /nmaplowercheck1484938066

This is not unusual.  Under certain commands nmap will throw a bunch of its scripts against any port it finds open to see what comes out; the scripts in nmap go far beyond simple port scanning functionality.

As to who did it, and why, you should have web logs that list source IP address.  If you don't have that, given that the most likely cause* is an approved automated scan across your network, leave a packet capture running and wait for it to happen again.

*for an Internal network.  On the Internets it's a whole different story!


Tools to make a security researchers life easier - tracking vulnerability research

Any bug tracking software is the standard for this tool. Vulnerabilities you find are simply 'bugs'. Assign severity, track the vendor's response and follow-up, and detail the issues all within the tool.

Github, bugzilla, Jira, etc. Choose the tool that matches your needs and workflow.


Self Tests for cPanel Server PCI Compliance

In terms of scanning the system for compliance, it's a question of running vulnerability scans and see if they pass externally and if the risk is acceptable internally. In terms of whether the system is configured in a compliant manner takes more work as per the following list:

Is networking limited to protocols required for business purposes with no insecure protocols in use for logons etc such as telnet?
Is the system hardened according to an industry standard (SANS, NIST, CIS)?
Is HTTPS in place (transmission of sensitive data over encrypted channel)?
Is AV installed and up to date (not really necessary on *nix)?
Is the system patched up to date?
Does development adhere to a SDLC with trained developers?
Is user authorisation checked and based on roles?
Are password policies in place and enforced (length, complexity, aging etc)?
Is logging in place for authentication, File Integrity Monitoring, NTP sync, IDS/IPS, penetration testing?
Lots of policy documentation?

If you want to do a basic check, harden the system and run a vulnerability scan. If you need to be prepare for compliance, you'll need to go through each of the above and more depending on compliance requirements (i.e. SAQ/full assessment/which SAQ depending on payment channel etc)

In terms of your specific 3 questions...

Vulnerability scans are all pretty similar in that they scan and check for vulns and meaure against CVSS scoring. Nessus is good but there are plenty.

The McAfee plugin (I think) is based of their Foundstone stuff and is good.

In terms of checklists, it's a matter of going through the list above or the PCI standard or just considering best practice.


How to manage all the unlock codes for thousands of mobile devices (iPads)?

You are looking for a MDM (Mobile Device Management) solution:

  Mobile device management (MDM) is an industry term for the administration of mobile devices, such as smartphones, tablet computers, laptops and desktop computers. MDM is usually implemented with the use of a third party product that has management features for particular vendors of mobile devices. (Wikipedia)

Examples of such third-party tools can be found here.

These tools typically allow you to change/reset a user's passcode from the management console (example). However, most of these tools do not store the passcode in a central location. As administrator, you are able to change the passcode or to unlock the device, not to view the actual passcode.

In reply to the edit

These MDM policies will typically also allow to enforce passcode policies (see for example the answer here).


(I had to make some quick research for this intriguing question).
The saved passwords can be decrypted by Firefox (or any other software) as long as it is running within your windows account on the same machine where the passwords were encrypted.
Chrome encrypt stored password using CryptUnProtectData, the algorithm relies on the user logon credentials and some information specifics to the machine to decrypt the passwords.
You can check here a Python implementation that uses the same encryption function to read the saved passwords on Chrome.


Is there any mail service accepting real id?

An example is Italy's "Posta Certificata": a web mail that by law guarantees the recipient is a real person:

https://www.postacertificata.gov.it/home/index.dot

To activate it you need to go to a post office and provide an ID card.

This shifts the problem to a different domain:

ID cards and all their associated issues: how can we be sure that the Post Office operator knows how to recognize a fake ID? What if it's an insider job? Etc.
What if an attacker takes control of a citizen's web browser?

In the end your mileage may vary depending on what your definition of a real ID is.


what does "no value specified" default to in keychain on osx?

To be fair, I didn't use OS X much lately, but my suspicion is: Yes.

Not setting specific values for those usage types that supersede the system default is irrelevant, as the certificate is a CA.

With those options, you can disallow a specific usage for a specific certificate.

You can check if you are MITM'd by checking the CA of the certificate. Please also note that with PK-Pinning and HSTS, it's harder for SSL-Proxies to work without you easily noticing it, as long as the website is up for it.

There are browser plugins that check what other people get for a certificate for a given domain, further warning you of a MITM.

So the MITM when browsing can be mitigated, leaving other TLS-based services. There is DANE for that, but it must be supported by the client and the server and is not as wide spread as one would hope.

As far as "the school is forcing me to trust this CA" goes, you might also just import all leaf certificates that CA signed by hand and explicitly trust them to have access but not trust the CA. Thus, you know when something is wrong, but have to sometimes grant trust to new leaf certificates.

This would work for any other OS with a centralized and user-manageable trust store as well.

The weighing of that trade-off is ones personal opinion, while when aware you might just reduce the usage to non-critical applications or those secured by DANE.


Using MySQL 'encrypt' / crypt() to store passwords?

If you read the documentation: SHA1, MD5 and MySQL password() are only supported for legacy reason and scrypt or crypt(3) are advised. However, that would not really answer your question, so let me emphasize which one I would choose.

crypt(3) This is Unix's password hashing (some call it encryption) function. This is a modified DES cipher that uses a 12-bit salt based on the system clock, for per-user diversification. The really downside of this function is that it takes only eight ASCII characters (equals 56 bit) as the key. That key is then used to encrypt a 64-bit string of 0 and the modified DES cipher. The output is again encrypted with the key and this procedure is repeated 25 times. The repetition was chosen to slow down dictionary attacks. However, cracking crypt(3) password hashes is not really a big deal and greatly depends on the password strength of your users. Bear in mind, this solution dates back to the 1970s and all modern Unix/Linux systems use modern hash algorithms, such as SHA-256 or SHA-512.

scrypt This method was developed by Colin Percival who identified that password hashing was predominately CPU-hard, but not memory-hard. The problem when a password hashing algorithm is only CPU-hard is, that the more CPUs are present, the quicker you can brute-force it. The limiting factor is memory and CPU power. Therefore scrypt consists of a series of functions that extend the CPU-hard approach by a memory-hard approach.

Conclusion If you have the option to choose for either password protection method, I would go for scrypt rather than crypt(3). The reason being that crypt(3) is actually deprecated already and scrypt offers more protection against brute-force attacks. However, it also depends on the number of users your solution should serve. Naturally, a CPU-,Memory-hard function will not only use more resources during brute-forcing, but also during normal authentication compared to functions which do not offer this.


Is it possible to brute-force the original message of SHA-256 given the size of original string?

Given the original length L of the string, you could consider that the effort to retrieve it is 92 power L (92 is 26 lowercase + 26 uppercase + 10 digits + 30 punctuation) instead of 2 power 256.
So if your string is more than 39 chars long, knowing the lenght gives no help.
EDIT: we should consider that an opponent which tries to recover the original string will not actually bruteforce each character. He will bruteforce words.
Except if the string contains a random password, an unknown lastname or something else which is not in a dictionnary, this is the best approach.
With an upper bound of 1,022,000 words and a lower bounds of 171,476 words (words currently used) the order of magnitude can be calculated by 1000000 power N (N is the number of words in the string).
So if the sentence is less than 13 words long, it could be broken before the hash.
However, we have to consider that all the words permutations are not relevant. the opponent could use a smart approach in the building of the candidates to avoid meaningless sentences (for example testing "the" after another "the" could be avoid, testing "than" after "most" makes no sense too).
Following this approach, knowing the number of characters of the string is helpful for the opponent because it will exclude many candidates.
But I'm not sure that the time spent to test the length and the meaningfulness of the sentence is not bigger than just hash it and compare it.


Identify owner of public key certificate

In your specific case it's quite likely these keys were generated using the CLI tool for Particle (IoT software). That's because it creates key files with the same naming pattern as in your examples.

E.g.:

(hex device ID)_rsa_new.pub.pem
backup_(hex device ID)_rsa_new.der

(Relevant source code file.)

So 3d001d000851363136363935 is the ID of a device you've been working with. If you don't recall using Particle explicitly, think of (Particle-powered) IoT devices you worked with in the past and follow these instructions to find out their respective device ID to compare it with the one on the keys.

Here is sample output showing how particle creates keys with the same naming pattern:

% particle keys doctor 1a002d001547353236343033
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -l
Found DFU device 2b04:d006
running openssl genrsa -out 1a002d001547353236343033_rsa_new.pem 1024
running openssl rsa -in 1a002d001547353236343033_rsa_new.pem -pubout -out 1a002d001547353236343033_rsa_new.pub.pem
running openssl rsa -in 1a002d001547353236343033_rsa_new.pem -outform DER -out 1a002d001547353236343033_rsa_new.der
New Key Created!
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U backup_rsa_1a002d001547353236343033_rsa_new.der
running openssl rsa -in backup_rsa_1a002d001547353236343033_rsa_new.der -inform DER -pubout -out backup_rsa_1a002d001547353236343033_rsa_new.pub.pem
Saved!
checking file 1a002d001547353236343033_rsa_new.der
spawning dfu-util -d 2b04:d006 -a 1 -i 0 -s 34:leave -D 1a002d001547353236343033_rsa_new.der
dfu-util 0.8
...

(Source)


If you've sent the data over straight TCP with no application layer protocol on top, Wireshark itself won't know how to extract objects from that stream. The data is still there, though.
One approach you might take to quickly extract the data from the TCP connection is to right click a packet in that conversation, then go to Follow -> TCP Stream. In the window that pops up, change "Entire conversation" to just the direction in which the file was sent, then change the "Show data as" dropdown to C arrays. It'll create one char array per TCP packet. You can then write some code to save the bytes to a file, with whatever processing you need to include to remove packet headers or anything else that you added in your original sending program.
Another approach would be to use something like Scapy to capture packets (or open a pcap file), filter down to just the packets you're interested in, and extract their contents in a similar manner.


Why does Chrome display "Managed by Organisation"?

The chrome notification Managed by your organisation is not necessarily even a bad sign.

There are many possibilities why Chrome displays this message.

You can have a look at chrome://policy to find the causing policies.

For example, a plain Chrome installation from the Fedora 32 repo has the flag AuthNegotiateDelegateWhitelist activated for Single-Sign-On by default which leads to the same notification.


From what I could find, the lack of forward secrecy is due to the fact that multiple sessions use the same key.

This is not about using the same key inside multiple sessions.

All ciphers using the RSA key exchange lack Forward Secrecy since an attacker could passively sniff the traffic and later decrypt the sniffed traffic if the attacker gets access to the servers private key. This is not possible with ciphers using Diffie-Hellmann (DHE, ECDHE), i.e. these ciphers provide Forward Secrecy.

Or as written at Wikipedia:

  A public-key system has the property of forward secrecy if it generates one random secret key per session to complete a key agreement, without using a deterministic algorithm.

With RSA key exchange there is a deterministic algorithm based on the servers private key, with DH there is no such determinism.

  How/where are the keys persisted and for how long?

Forward Secrecy (or lack of) is not about the persistence of the keys but about the ability to recreate the keys in a deterministic way, in case of RSA key exchange based on the private key of the certificate.

  Can this compromise sessions which will happen in a relatively far future, say half a year from now?

This is about a "compromise" of a session but that the encryption keys can be recreated if the session was sniffed and later the private key gets known. This can be years after the session got sniffed.


"Web of trust" for self-signed SSL certificates?

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question.

This just is a very important part. If you don't verify, that the peer you talk to is the expected peer, than it could just be somebody else. E.g. if Alice wants to talk to Bob and does not check, that it is actually talking to Bob, than it might talk to Mallory claiming to be Bob. Mallory might then relay the messages to Bob and the connection would still look encrypted, but it would be encrypted from Alice to Mallory and again from Mallory to Bob. Mallory would have access to the plain text of the message and could also modify it.

In theory you could do your own web of trust with self-signed certificates. But, I don't think many of the current users of https would understand the concept and its implications, e.g. how to apply trust to another party, how not to trust just some stranger, how trust weakens the longer the trust chain is and how much trust they need when accessing a site (which might be different from site to site).

Which means, that at the end you might get a trust network which is too complex for most people to understand and thus they don't trust it. Or you might get a trust network with some well known and thus trusted players in it which offer to verify you and then add you to the network for some money - which is more or less what you have today.

While nobody really likes a central authority, having such thing greatly simplifies to apply trust in real life. I.e. most people don't put they money into a small bank unless they are known to be backed by a larger bank or insurance etc.

DANE might be a better way to go. It still requires a central trust network, but it does not create a new one just for SSL, but instead reuses the existing one created for DNSSec. This might be both cheaper and easier to understand - and thus more trusted.


Security of an SQL database server used in web app

You could, if you want to do extra amounts of work, have an intermediate middleware layer that brokers requests from the dmz web server. It could be as simple as a rest based api ( it might not be simple :) ). Once again the amount of work is dependent on the monetary loss associated with the data.

Also if you approach this from a programming perspective, that will be the methodology. But if you approach it from the inevitability of data loss, then you would go with a backup policy.


Should my company have an SSL on our email

While I personally would say that every mailserver must provide support for SSL, deploying SSL is not the only way to secure eMails; usually using some kind of end-to-end encryption is a good idea, especially with critical data.
You need SSL for...
SSL can protect eavesdropping for in- and outbound mails, given that both mailservers support it. So if a customer sends you critical information from an server supporting ssl, it will be sent in plaintext unless you set up ssl as well. Thus, all information on such eMails should in my personal opinion be considered as public information, like a postcard. Your customers should be worth the effort of setting up SSL.
You also need SSL for employees accessing their mailboxes; this may additionally improve the security of mailbox passwords. Not deploying SSL there is a rather big security risk, as an attacker would only need to redirect the traffic of an employee's computer to get access to his whole mailbox.
You don't need SSL for...
However, if you only use webmail (over SSL) or only access mailboxes from a network considered safe, emails routed internally (e.g. emails within your company) are not affected from not properly using SSL on the mailserver part.
So, I'd highly recommend SSL for any setup, and additionally some end-to-end encryption (PGP or S/MIME) for critical information like passwords.


Does analysing Malicious code in gdb pose a security risk?

It certainly does.  gdb will not isolate the process at all and will merely give you some control over it to understand what it does.

To do that kind of analysis, you should resort to a fully isolated system such as a VM with no network access.

Break points will be respected, but you should always account for human errors which can have drastic consequences.  Should you be good enough to safely debug an unknown obfuscated program, you wouldn't need to run it as you would simply read the code to know what it does, which would be risk free.


I've been doing some searches for RSA and it appears that it uses shuffling but not substitution.

RSA is a mathematical algorithm. Neither of these terms is applicable to it.

Generally speaking, the terms "shuffling" and "substitution" are generally only applicable to extremely simple, pre-electronic cryptographic techniques -- Vigenère ciphers, columnar transpositions, and the like. They are not especially relevant to modern encryption.


Fake users in database for compromise detection

Creating a honeypot is a common used technique in information security, though probably not the best of ideas for a production environment. Apart from the fact that you add potentially new risks to your application, there may not be much need for such a trap.

Failed logins can be monitored by most applications (and/or server daemons) which should give you more than enough insight without putting your application at risk.

To state the obvious; brute force attacks are (unfortunately) a common phenomenon and are likely to hit your application anyway.


Requesting an SSL certificate without a CSR, can it be done?

Normally CAs cannot issue certificate without your CSR. There are many tools to generate a key pair and a CSR. You can use any tool that you like.
If you use Windows, you may prefer GUI based tools. Then I would recommend to consider KeyStore Explorer: You generate a key pair, then generate a CSR and send it to your preferred CA.


What is the security impact of removing scripts tags in a website during page load?

I can see no benefits with doing that.

It does not hide your source code. It is still sent to the client, and can easily be read. Besides, the security of your app should not rest on the source code being secret.

I fail to see how it would have any impact on XSS, which is the exploit it seems most related to. XSS is about inserting new scripts, not about using old ones.

But who knows. There might be a corner case out there where this will save you. Just because I can't imagine it, doesn't mean it doesn't exist. But unless you have a clear idea what you are defending against with this, I would not do it. It adds complexity without delivering any clear benefit.


Methods for protecting computer systems from physical attacks

The problem with trying to detect these attacks is that their common target - desktop workstations - largely goes unobserved for most of its life.  Even if it actually sits on the desktop, users rarely pay attention to it except to push the power button, insert/remove removable media, or plug/un-plug accessories - all of which generally can be done from the front of the system, while the simplest way to hide these attacks is to plug into the rear.  You could perhaps mandate that all desktops be kept actually on the desktop, and have all peripherals plugged into front-facing ports, but that almost certainly won't gain good user acceptance.

There probably is no easy way to thwart a hardware keylogger, except to regularly check your peripheral connections.  You can include this in your end-user training, but it's unlikely to ever actually be done by them and it increases the probability that they'll have to call for help when they've inadvertently unplugged something essential in the process.  A better method, if there must be one, may be to have a team of technicians perform regular hardware inspections.

The easiest and most cost-effective way to detect breaches into the computer case itself would be to use stickers akin to the ones OEMs use for warranty validation.  Of course, this would require that you regularly check said sticker to verify it hasn't been tampered with.  Again, this is not something that would be well accepted or implemented by the end-user.  So, it will be up to your technicians to regularly inspect their systems.  You'll also have to make sure that said technicians have access to the stickers so that they can apply new ones whenever they service the systems, but then we wander into the possibility of insider attacks.

Alternately, some cases and motherboards support hardware-based monitors which can alert you at boot-time if the case was opened since the last power-on.  These may or may not be easily circumvented (i.e.: Attacker covers his track by power-cycling the system to dismiss the alert before the victim uses it again.) depending on design, and again may still be vulnerable to insider threats.


Why does my TLS v1.2 handshake take 2 tcp/ip connections?

As far as I understand the aim of LoadRunner (i.e. the software which VuGen is part of) is to simulate a real client like a browser. If a browser connects first to a web site which requires a client certificate then the browser has to interact with the user to find out which certificate should be used and to get the password for the private key. In this case the browser will not stall the handshake, but close the connection, ask the user and then reestablish a new connection. My guess is that LoadRunner tries to simulate exactly this behavior.


Why do (many) TOTP devices or TFA apps use none or simple access password?

You named it - it is a bank!

Banks are finance institutions and compare numbers and probabilities. We all know that a four digit!!!!! (not characters) password is absolutely insecure. Nevertheless the bank calculates the probability and costs of a user getting breached and the probability and costs for users forgetting their more complex app password and thus creating support requests.

There would be however one reason for using a real password on the app: The app on the smartphone stores a symmetric key to generate the one time password. You could use this password to encrypt this key, when it is not used. Again, we know that a four digit PIN will not create a good encryption key.

The device you linked with the key pad is probably a challenge response device?
I assume you do not always enter the same PIN in the device!? The PIN is the challenge - it should contain some kind of information of the transaction. Your device also has a secret key and will create a response based on this challenge/transaction data. If it is implemented right, it is a rather strong mechanism. They could however have created this based on the OCRA algorithm (RFC6287 https://tools.ietf.org/html/rfc6287).


What does two IP-addresses using the same MAC-address mean?

I would read your logs as follows:

192.168.1.64 is the IPv4 address the physical interface with MAC 00:1f:f3:5a:77:9b is using. I would tend to assume the IP was handed out via DHCP, but you would see a similar IP <-> MAC map if it was statically assigned (you simply would not be likely to see it from a DHCP server)
169.254.90.183 is a link-local address (https://en.wikipedia.org/wiki/Link-local_address), which in effect means it is an autoconfigured address the machine assigned to itself when all other IP assignment mechanisms failed (typically, this would happen when a node cannot get a DHCP assignment, potentially because the DHCP server has no free IPs to hand out, or because it is busy).

If the first two columns in your output are a reasonable proxy for timestamps, I would take all this to mean DHCP failed temporarily, before working again and providing the host with an address.

As a link-local address, traffic from 169.254/16 will not leave the broadcast domain, so in a forensic context, unless something happened within the broadcast domain, I would disregard it.

There is one specific use of this range that would possibly be worthwhile worrying about, which is a host announcing itself as 169.254.169.254 within a cloud environment (see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)


What are the shortcomings of the following bank transaction authentication scheme?

Some thoughts in no particular order.

It requires good math, reading, and reasoning skills; although it
would be great if everyone could perform these tasks we can't (nor should we) expect
that everyone with a bank account will be able to do this. This will result
in false failed logins, decreased usage, and increased support calls.
It requires standardization about how to write the questions.
Ideally these questions should be able to be algorithmically
generated, not written by a human, and verifiably correct and free of ambiguity.
The scheme requires the ability to read the language the questions are written in. A scheme that just has a token card or passcode list does not have this limitation. Bank accounts are mostly numerals which are cross-linguistic.
Given the required standardization above, now we must be able to verify that
it is indeed not trivial to work backward from password to the
generating algorithm. It's not clear from your description that this
is provably true.
The resulting number has to be both long enough to provide
sufficient entropy and short enough to make the calculation step
feasible. E.g. a 10 digit number might have sufficient entropy
depending on the calculation scheme and the rest of the security;
but 10 digits might be too long to expect someone to follow all your
steps.
What problem are you trying to address that you feel current schemes fall short at?


It's something I've seen but seems to be most common with either larger companies or those serving markets that particularly need/value certifications (e.g. finance, government).

In terms of which ones to look at there's a couple of options that I'm aware of, some of which are geographic in nature.

ISO27001.  General InfoSec one, but very useful as evidence of security processes for a lot of companies
SSAE16 (Formerly SAS70).  US focused service organisation certification.  Again some US companies might well look for this
FIT 1/94 - Bit niche and UK based, only look at it if a customer asks.

The advantage of these certs can be that you can avoid customers who have audit requirements from coming and bothering you a lot (i.e. they can rely on the cert and don't need to prove control levels themselves)


can the iteration number of pbkdf2 be a security flaw?

The iteration structure of PBKDF2 looks like this (https://tools.ietf.org/html/rfc2898#section-5.2):

U_1 = PRF (P, S || INT (i))
U_2 = PRF (P, U_1)
...
U_{c - 1} = PRF(P, U_{c - 2})
U_c = PRF (P, U_{c-1})

Where:

PRF is the Pseudo Random Function (i.e. the underlying hash function)
P is the password
S is the salt
i is the block number

Given U_{c - 1} and U_c, I could try to find P such that U_c = PRF (P, U_{c-1}) rather than having to iterate 1000 times as you'd normally have to with PBKDF2.

This essentially defeats having multiple iterations in the KDF, reducing the number of calls to the PRF from 1000 times per try to the smallest difference between any two hashes' iteration count.

An improvement if you need multiple PBKDF2 with different iteration count from the same password, is to vary the Salt.


Keyboard sniffing through audio recorded typing patterns

In a similar vein, but slightly different.  Rather than using audio recordings this link shows that you can point a laser at the back of a laptop monitor and determine what is being typed based on the vibrations of the screen.

Here is the original presentation slides


In order to capture network traffic for other hosts you need to put your wireless device into monitor mode.

I would check out the following project on github - MonMob. If you update your question with some more specifics on your iOS/iPad and jailbreak information I will try to provide some more specific resources.


Each encryption mode has its own requirements for the IV.

For CBC, the IV must be random, uniform (all block values have the same probability of being selected), and unpredictable for the attacker. The latter is necessary to defeat attackers who get to choose part of the data which is to be encrypted. This is the mechanism of the BEAST attack on SSL: in SSL 3.0 and TLS 1.0, the IV for a record is the last block of the previous encrypted record, so it can be predicted by the attacker (he saw it). Note that this IV is still, from the point of view of the attacker, random and uniform (the MAC and encryption of the previous record act together as a random number generator). Unpredictability is thus crucial.

Some other modes are less picky. For instance, EAX only requires a non-repeating IV: for a given key, you should never use the same IV twice. But there is no need for randomness, and a simple counter will do the trick.

The safe IV generation method is to use a cryptographically strong PRNG (/dev/urandom, CryptGenRandom(),... all decent development platforms offer one) to produce the full IV (all 128 bits for a 128-bit block cipher like AES). This produces adequate and secure IV for all modes. You cannot get it wrong that way. CBC, PCBC, CFB and OFB require such a random, uniform and unpredictable IV.

If you want to use something else than a fully random IV, then you must take care of the precise needs of the encryption mode. Not using a random IV may have the benefit of not requiring a PRNG, which can be a nice thing on some embedded platforms which do not have a good source for random numbers. To some extent, CTR can use a predictable IV, but you must be cautious. CTR works by encrypting successive values of a counter, and the IV is just the starting point for that counter. You must never reuse the same counter value twice (with a given key), so when you use an IV for CTR encryption, you actually "burn" a range of IV values.

Your method:

is overly complex,
does not completely fulfill the uniformity and unpredictability requirements that most block cipher modes require,
and still needs a secure PRNG to be available.

As such, it is weak and pointless. If you have a secure PRNG, just use it for the whole IV. This will give you the best you can hope for: it will be fine for 128-bit block ciphers, and mostly fine for 64-bit block ciphers (and you cannot really get anything better for 64-bit block ciphers: weaknesses implied by the short block size when you encrypt more than a few dozen gigabytes with the same key are structural). Don't throw additional algorithms and structure and other gimmicks at your protocol; in cryptography, complexity is your worst enemy.


The method looks like a transport key approach to securing the data using three independent parts which are each secured by something that the user knows.  The combination of each of the component keys provides the unlock/lock functionality.

One of the weaknesses of this model is that if you loose one of the
components then you will not get your data back - but in this case
there does not seem to be any data persisted that can't be
re-produced by re-setting up the accounts and so on.
A strength and weakness of this model is that the more components you
have of the key, the better the security at the cost of usability.
i.e. there is a greater chance of loosing one of the keys if one of
the sources is unavailable.  So, you could be more easily locked out
of your accounts if one of the independent data centres is having a
bad day - or an attacker is denying you access by blocking your
access to one of the keys.   Again, given it is just account
information - it's not the end of the world if you have to wait a
short time but every situation will have different tolerances.
(please don't use this method on a life support machine for example).
Another strength and a weakness is the fact that a lot of this is relying on infrastructure outside of your control. i.e. you don't even have a contractual relationship with the 3rd parties.  For this applicataion, this is probably OK - but not if you are a company using this app.  Again, it depends on your own personal risk appetite (personally, I wouldn't touch it with a bargepole)
The notes are a bit rubbish.  Yes, they use SSH for admin - but it is easy to use SSH in a really poor way.  I have a few alarm bells ringing because they've even chosen to say this publically.  It indicates that they think this is the second most important thing to say which is quite worrying.

Are you in breach with your bank?

Perhaps most importantly, are you in breach of your terms and conditions with your bank by using this application?  Indeed, if you are a UK customer (which i am guessing you are) then you most certainly will be so if this does all go wrong then you will be help personally liable.  If you have insurance against identity fraud etc, then it is unlikely to pay out if you have willingly used a service like this...


Are there any free static analysis tools for C# / .NET code

Roslyn Security Guard is now available and is free. https://dotnet-security-guard.github.io/

Update: This project is no longer maintained and has been forked here and improved here: https://github.com/security-code-scan/security-code-scan.

By the way, be sure to enable it for the full codebase by choosing Tools > Options -> Text Editor -> C# -> Advanced -> "Enable full solution analysis".


How should I audit and monitor shared TCP ports in Windows?

I think the only real audit you can do here is to actually turn the service off. Besides that I think the only limit you can set are the authorized security identifiers (SIDs) which can be configured (as described here on msdn).


I think you meant tokens, not cookies. As far as I know, CodeIgniter antiCSRF mechanism inserts unique random tokens in every form. These have nothing to do with HTTP cookies, which as a best practice should not be accessible from JavaScript code.

Regarding your actual question, it has been discussed in other threads if using one anti CSRF token per session is a bad thing (example). Your case is between using one token per form and using one token per session, so as long as you are using SSL you should be ok.


What is the meaning of .ini file in startup folder?

This is a typical Desktop ini file that normally saves the folder view settings such as the background image etc. If suspect some malware is executing on the Windows startup, it might be executing from

Run and RunOnce keys in the registry
Windows Services
Windows drivers
DLL hijacking (placing itself in a path that comes before the
legitimate DLL)
Registry key of the registered shell extensions
Hidden file or shortcut in the startup folder

There might be other locations as well so your best bet is quarentine the machine and follow the standard procedure of malware cleanup. You will find plenty of examples on how to cleanup a malware infected machine on SE and other forums.


How to know what personal information companies know about myself

Depending on the applicable data privacy law in your country, you might have the right to request a company to send you all the personal information it collected about you. This usually works fine, though you have to send this request to each company you think is storing some data. Also, data privacy authorities often provide standard letter for this.

There are also some international legal frameworks for data protection, such as:

European Data Protection directive
Global Privacy Enforcement Network

The key point for those national or international frameworks is: The data subject has the right to be informed when his personal data is being processed.

Now, you will also find different situations where it's hard or impossible to obtain this information. This includes companies that don't comply with data privacy laws, or information that is stored without the knowledge of the company (this can happen when a company purchase a large data set for marketing purposes, but only use part of this data set and don't look exactly at what it contains).

You can also perform simple search-engine searches based on your personal information and see what comes up.


Why would a scammer ask for creation of a new email account?

Well, where did you receive this e-mail? If it was a corporate/business domain, then they're probably trying to set up a side channel so they can lure you outside the "protection"/oversight of your infosec team.


Should I trash my router if it still runs OpenSSL 0.9.8p and OpenVPN 2.2.2 in 2017?

You may disable all the features you don't want to use on your router. You can enable SSH only when needed and keep it disabled at all other times. Port forwarding and connection over VPN to your local devices is very good approach. Also make sure there is no way to connect to your router from the internet - allow access only from your local network and always via SSL if possible. Use UPS to power your router and if you have to REBOOT it do it offline, then connect the internet wire once fully rebooted. Routers tend to be vulnerable during the boot sequence, typical attack might be to force the user to reboot the router and then attack it.


The story makes sense up to the point you mentioned Firefox. Certificates are shared between applications by the operating system, this is the case for both Linux and Windows. Firefox has its own certificate store, because they have their vision to what is trusted and not. However Firefox can be configured to trust the OS shipped certificates as well. This would make sense since you have to install the certificate in order to connect to a network. Firefox then accepted the HTTPS because it was already present in the OS.


Secure HttpOnly Cookie or Header field for auth token securing an API?

I don't think there is a big difference in security between cookies or headers, if properly used.

Cookies are meant to maintain server state. So if you have a login call which starts a session, cookies make sense. If you use an API token that is distributed outside of the API, cookies don't make sense.

In the end, cookies are also sent in headers, so there is little distinction between how they are transmitted. The difference is in how browsers handle cookies:

It is possible to set cookies as HttpOnly, making them inaccessible from JavaScript;
Cookies are included in every request by the browser.

HttpOnly provide some protection against XSS. However, an attacker can call your API any way he wants when he gets XSS, even if he doesn't obtain the cookie.

That cookies are included in every request makes it vulnerable to cross-site request forgery (CSRF): another webpage can trigger a request to your API, and the cookies are included by default.

In a SPA, an alternative to store the token is in a JavaScript variable. This is only kept while the tab is open, and may be secure against XSS if the variable is limited in scope.

Storing tokens in localStorage keeps them there forever, since localStorage is not cleared when the application is closed. However, this isn't so bad, since you can expire tokens on the server. Even if the token is exposed after a while because it was kept in localStorage, the token won't be valid anymore.

There is also the possibility to use two tokens, one in a cookie and one in a header. You would need both tokens to successfully use the API. Since the cookie is HttpOnly, you are protected against XSS. Since the header is not sent on every request, you are protected against CSRF.


logging requirements for PCI for web applications

You are expected to log:

All individual accesses to cardholder data
All actions taken by any individual with root or administrative privileges
Access to all audit trails
Invalid logical access attempts
Use of identification and authentication mechanisms
Initialization of the audit logs
Creation and deletion of system-level objects

These must be logged with a verifiable date & time (proper time sync enabled) in an immutable manner. You should, "Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up)."

You'll want to look at the whole document and understand all the sub-requirements that make up the big 12. https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

To answer the Jeff Atwood theory, though, and maintain your own sanity, you should keep PCI DSS related logs separate from application activity logs. I would suggest that exceptions be copied into a separate log facility so that from a developer standpoint, logs are readable and sparse. From an auditor standpoint, your comprehensive logs can be, well, comprehensive and used to reconstruct activity.


How to identify Encryption algorithm for data coming in field/attribute values of an xml

This is just straight ASCII represented in hexidecimal.  I removed the newlines and the following python code will display it:

>>> from binascii import unhexlify
>>> ascii = "7b5c727466315c616e73695c616e7369637067313235325c64656666305c6465666c616e67313033337b5c666f6e7474626c7b5c66305c666e696c2054696d6573204e657720526f6d616e3b7d7b5c66315c666e696c5c66636861727365743020417269616c3b7d7b5c66325c666e696c5c6663686172736574302054696d6573204e657720526f6d616e3b7d7d0d0a7b5c636f6c6f7274626c203b5c726564305c677265656e305c626c7565303b7d0d0a5c766965776b696e64345c7563315c706172645c6366315c66305c667332305c7061720d0a5c6366305c6631204c6f74204e696e65202839292c206f66204245415220435245454b20504f4c4f2052414e43482c20616e206164646974696f6e20696e20456c6c697320436f756e74792c2054657861732c206163636f7264696e6720746f20746865206d6170206f7220706c61742074686572656f66207265636f7264656420696e20436162696e657420432c20536c696465204e6f2e20343535206f662074686520506c6174205265636f726473206f6620456c6c697320436f756e74792c2054657861732e5c6366315c66325c7061720d0a7d0d0a00"
>>> unhexlify(ascii)
'{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033{\\fonttbl{\\f0\\fnil Times New Roman;}{\\f1\\fnil\\fcharset0 Arial;}{\\f2\\fnil\\fcharset0 Times New Roman;}}\r\n{\\colortbl ;\\red0\\green0\\blue0;}\r\n\\viewkind4\\uc1\\pard\\cf1\\f0\\fs20\\par\r\n\\cf0\\f1 Lot Nine (9), of BEAR CREEK POLO RANCH, an addition in Ellis County, Texas, according to the map or plat thereof recorded in Cabinet C, Slide No. 455 of the Plat Records of Ellis County, Texas.\\cf1\\f2\\par\r\n}\r\n\x00'

Things to recognize are the 0x0a, 0x0d ASCII characters at the end that represent a line feed and carriage return respectively.  Also a lot of the text is between 0x41 to 0x5A (A-Z), and 0x61 to 0x7A (a-z).

To address your question about recognizing encryption.  Unless the communication protocol or file format provides you with the algorithm type there is generally no way to tell one encryption algorithm from another just based on encrypted data.  For files it can be provided in a file header value.  You'd still have to know what value in the header represent an encryption algorithm, and then further you'd have to determine which algorithm the value represented.  For secure communication protocols the algorithms are generally negotiated during the protocol's initialization.


It appears that the CVSS "Integrity" metric is "N" for None:

AV:N/AC:L/Au:S/C:P/I:N/A:N

http://cve.circl.lu/cve/CVE-2017-12419
Even though this exploit provides read-only, it is unclear what remote files are accessible. At the very least, any passwords stored in PHP files are likely compromised.
Under Linux, you will want to verify which user is running PHP on behalf of the web server, and what permissions that user has.
The proof of concept in the vulnerability report tries to read /etc/passwd which is a common root access check.
https://www.mantisbt.org/bugs/view.php?id=23173
It would be unclear if you could trust server logs if root access was possible.


Why one should prefer EST protocol instead of SCEP?

What is SCEP?

Simple Certificate Enrollment Protocol is a certificate enrollment protocol originally defined by Cisco in the 2011 IETF Internet-Draft draft-nourse-scep, and more recently in the 2018 IETF Internet-Draft draft-gutmann-scep out of the University of Auckland.

What is EST?

Enrollment over Secure Transport (EST) is a certificate enrollment protocol defined by Cisco, Akayla, and Aruba Networks in RFC 7030. EST can be thought of as an evolution of SCEP. Cisco provides a nice guide to understanding EST, which is spun to favour EST.

SCEP vs EST

Similarities

Both protocols are very similar in that the client sends CMS (aka PKCS#7) and CSR (aka PKCS#10) messages to the Certificate Authority, signed with a pre-existing certificate in order to enroll for a new certificate with the given CA.

They both support the following methods for the client to prove its identity to the CA (though the exact details differ):

CMS / CSR messages signed with a previously issued client certificate (e.g., an existing
certificate issued by the CA). This is typical for a certificate renewal.
CMS / CSR messages signed with a previously installed certificate that the CA has been configured to trust (e.g., manufacturer-
installed certificate or a certificate issued by some other
party). This is typical for IoT devices, mobile devices, etc, that have a certificate injected during manufacture, and where the CA has been configured to trust the manufacturing CA.
A shared secret that has been distributed to the client out-of-band.

Differences

The main difference between them is that EST uses standard TLS as the transport security layer, requiring that the certificates above be provided for TLS client-authentication in addition to signing the CMS and CSR messages.

In SCEP, the shared secret auth method is done by including the secret in the challengePassword field of the CSR, and creating a disposable self-signed certificate to sign the CMS message with.

Since EST uses standard TLS, it has two methods for enrollment using a shared secret:

Server-only TLS with HTTP username/password basic auth, where the username and password are the shared secret distributed out of band.
Mutual-auth TLS using a Pre-Shared Key (PSK) cipher suite. Neat side-effect is that this allows the client to authenticate the CA without needing to know in advance which CA it will be getting a cert from (ie no need to distribute the Root CA cert in advance).

Summary

Both are acceptable protocols for automated certificate enrollment with a PKI and offer similar security characteristics.

The advantages of EST are that it outsources its transport layer security to standard TLS, and therefore will continue to pick up security and performance improvements as new versions of TLS are released. This can also be an downside for constrained devices that do not want to dedicate code-space to a TLS implementation.


According the the documentation the current implementation is a subtractive generator.

The code for Random is easy enough to browse. It keeps an array of the 55 previously generated values, and uses two values 21 places apart to generate new numbers, The InternalSample() method shows exactly how each new number is generated.

If you have raw output, you can easily replicate this logic and start filling the history array until you have enough values to reliably predict new values. If you don't get raw values, you will need to estimate the raw value from the values you get, in much the same way you would with other methods.


Sql injection union select giving 500 internal error

Just to be clear, are you using the "order by" to get the number of columns and then using that number in your "union select"?

As an example, if there were 7 columns then the correct "union select" would be something like this:

' UNION ALL SELECT 1,database(),3,4,5,6,7 -- -
' UNION ALL SELECT 1,database(),3,4,5,6,7#

Also, the "order by" is used to get the number of columns in that you will increase the "order by #" until you get an error and the number before the error is the number of columns. You probably know this, but wanted to add it.


What is the difference between certified and non-certified drives for Windows To Go?

From the Windows Blog:

As well as being teased with a variety of PCs, Certified drives must:

Be built for high random read/write speeds and support the thousands of random access I/O operations per second required for running normal
Windows workloads smoothly.
Have been tuned to ensure they boot and run on hardware certified for use with either Windows 7 or Windows 8.
Be built to last. Certified drives are backed with manufacturer warranties and should continue operating under normal usage.

This means that:

They will have fast random reads and writes, and not just fast sequential reads. Normal drives generally have fast sequential reads/writes and agonizingly slow random small reads/writes.

They will have high durability, and have the ability to sustain large amount of reads and writes.


The impact of the Sony attacks on the security industry

Jan 2, 2011
GeoHot releases Root Signing key for the PS3.

Febuary 16,  Bret (Trixter) McDanel pokes around in the PSN trying to reverse engineer connection protocols and chat protocols. Essentially breaking the trust model of PSN by issuing a self signed cert and bouncing off a proxy he controlled.
http://173.255.232.215/logs/efnet/ps3dev/2011-02-16
(Wired Details some of that)
http://www.wired.com/threatlevel/2011/04/trixter/

Rebug Released Late March (3.55.1) allowed access to the Dev-PSN using the RootKey
http://attackofthefanboy.com/news/playstation-3-hackers-using-developer-network-to-access-psn/

SOE Fires 205 Employees the same day Rebug 3.55.1 is released.

DDOS Performed against Sony by Anonymous for filing Suit against GeoHot.  Claims by many, including Sony, was this was used as a great distraction by the malicious attacker.
http://www.eweek.com/c/a/Security/Sony-Data-Breach-Was-Camouflaged-by-Anonymous-DDoS-Attack-807651/

PSN goes offline April 20th.

a Week later, Sony says  happened.

They announce:
April 26th
PSN and Qrocity data exposure (77 Million Customer Records including 10 million Credit Card numbers)
http://www.h-online.com/security/news/item/PSN-hack-Personal-data-of-millions-of-customers-stolen-1233209.html

SOE Announces "No Breach Has occured"

Days later, SOE announces, we're sorry our bad, 24.6 million accounts were actually compromised.
http://www.geekosystem.com/sony-online-entertainment-hacked/

Lots more came after that:
So-Net, Sony Greece, Sony Erikson Canada, Sony Thailand, Sony Music Japan, Sony Music Indonesia, Sony Pictures


The server should never allow a duplicate nonce. This is what protects from a replay attack. Someone can capture and try to re-send your message but it will be denied because that nonce has been recorded and can't be used again.

If you have a timestamp and deny requests older than say 5 minutes, then you can clear cache of used nonces every 5 minutes. You can clear your nonces because even if they replayed one at this point it will see the timestamp is expired and fail anyway. This means you don't have to keep every nonce ever used until the end of time which results in less storage space and faster lookup times.


E2E encryption for web app - two passwords vs encrypting data with login pass and sending only hash to server

It's not clear what you are really asking.

From an usability point of view, requiring a single password is preferable.

More than "too much hassle" I would describe it as "users being confused". I wouldn't consider users using the same password for both fields as a failure in the schema. Plus, you could always make the app not allow using the same password in those two fields on registration.

On the other hand, from a security point of view, it's preferable to use two passwords completely unrelated.

First of all, note that in the use-same-password-scenario you clearly want to use different password derivations, so the two different operations cannot actually be linked (suppose that the first step of the local encryption started by hashing the password in the same way as for authentication, oops!). You could perhaps use two HMAC with different keys, or PBKDF2
Even then, having something that can be used to validate the data password could be considered a weak point. Suppose a dictionary attack, the attacker checks if it would be possible to use the login-algorithm to log in with the password "Password1". It succeeds. Then then attacker knows that Password1 using the encryption-algorithm would recover the data.
You mention as a con that resetting password would lead to data lost as those old data can't be decrypted. But that's already the case in the prior scenario. If the user loses the data encryption key, he won't be able to access his data.

An intermediate solution might be to provide both options. By default, use a single password for both actions, but let an advanced setting let the user set a second, different password, for encryption.

That way you could please those that wanted a separate encryption password while not bothering too much those users that would be confused / not benefit from it, such as your typical that would use Password1 and Password2.

Finally, I would like to question your premise that you want to use passwords.

What's your need for passwords? It would be more secure to use certificates. If the user registers using an application, it creates both secrets and handles them separately. In order to enroll a different client, a backup option produces two files (or a single file combining both secrets) with the relevant files.
A password might be "simpler" to backup (there is the chance that the user would remember it with no copies), but produces weaker security.
You mention that it is a "web app". If the user needs to authenticate every time on a web page, it may be simpler to introduce 1 or 2 passwords rather than uploading a password file. Webs are quite bad framework for E2E applications, though, since the attacker could provide a malicious web page that stole your data or encryption. In that sense, a native application would be preferable.


How does an attack on a digital signature work?

A digital signature, like all cryptographic algorithm, does not solve problems, it just moves them around.

Take care that signatures are NOT encryption. If someone tried to explain signatures as a kind of encryption, then go find them and hit them in the teeth with a wrench, repeatedly. Tell them that they are unworthy, and I am disappointed with them. This flawed explanation does not work, never worked, and spreads only confusion.

In a signature system, there is a message m, a public key kp, a private key ks, and a signature s. The signature generation algorithm computes s from m and ks. The signature verification algorithm takes m, s and kp, and returns either "true" or "false". When it returns "true", what this means is that whoever owns the public key (i.e. knows the corresponding private key) was involved in the generation of signature s on the specific message m.

The important point is in the key ownership: the signature verification algorithm does not tell you "yep, this is signed by Bob"; it only tells you "yep, this is signed by whoever owns that public key". This guarantees that the signer is really Bob only if you have a way to make sure that the public key you see is really Bob's public key. If Bob simply sent his public key along with the signed message, it would be easy to impersonate Bob by simply saying "hello, I am Bob, here is my public key, and here is my signed message". It would prove nothing at all. The attack here is simple, it is called "lying".

While signatures are useful (indeed, they reduced the problem of verifying the provenance of several messages to the problem of associated a single public key with its owner), they don't magically guarantee ownership out of thin air. This is where Certification Authorities come into play. The CA is an organism whose job is to make sure that Bob really owns his alleged public key; presumably, the CA does that by meeting Bob in person, or some other mechanism of that kind. When the CA has duly verified Bob's ownership of his key, the CA puts Bob's identity (his name) and his public key in a certificate. The CA then signs the certificate.

Alice's machine can then verify the signature on the certificate, thereby making sure that the certificate contents are really from the expected CA. At which point Alice has some guarantee about the fact that the public key she sees in the certificate is really Bob's key, and she can use it to verify signatures which have purportedly been computed by Bob.

At this point you should say: "But how can Alice verify the signature on the certificate by the CA ? She would have to know the CA public key !" And, indeed, the problem has again been moved, to the question of CA key ownership. We can move it yet another time, with another CA. And so on. But it must stop somewhere. That "somewhere" is the root CA. A root CA is a CA whose pubic key you already know, absolutely. That's the magic part. In practice, your computer comes with an operating system that already includes the public key of a hundred or so of root CA, who made a deal with Microsoft to the effect that their public keys are inherently known (and trusted) by all Windows systems.


Is IP restriction enough or should I SSL my web authentication?

The OSI layers are a model which was not meant for IP but for an older, competing protocol. IP does not fit well in that layer, especially when envisioning SSL (which must be both in layer 6 and layer 4, which is logically impossible). These layers are just confusing, so don't use them.

IP restrictions means that your server will refuse to pursue connections which are tagged with the wrong IP address. This does not protect the data against eavesdroppers.

Let me take an analogy: suppose that your connections are good old letters, with a destination address, and a sender address. The envelopes are transparent. The equivalent of IP restrictions is when the recipient refuses to even open, let alone respond to, envelopes which are not tagged with a "known sender" address. But nobody guarantees that the sender address written on the envelope is genuine; sending a letter with a fake sender address is easy. Of course, if I, an attacker, send a letter with your address as alleged sender, I won't see the response (unless I plunder your mailbox). But the recipient may have already have acted upon the letter contents, believing them to originate from you. Moreover, since the envelopes are transparent, every postman may read the contents of the letters.

For real protection, you need opaque letters, entrusted to armed conveyers in an armored vehicle. In the Internet world, this is called SSL (aka HTTPS in a Web context).


Is information still being sent from a discarded tab in my browser?

It really depends on the code in the site you had previously loaded.  If that site had code to call back to it's servers every few seconds (not too uncommon these days), then yes, that traffic would pass through your corporate routers and your boss would have access to it in theory. Just because you didn't click on the tab and hit the "x" without opening it, doesn't mean that the page tab is not able to communicate with a server just as it is able to when you are viewing it.


MySQL brute force attempts from localhost

From our conversation in the comments, it looks like someone (either at the IP that you posted, or proxying through it) may be trying to compromise your system by exploiting your phpmyadmin.  If you are not using phpmyadmin, you might want to uninstall it or disable it.  If you need it, you might want to follow the steps described here to better secure it.


Why do some ransomware executables run on VirtualBox?

These days with prevalence of virtualization in organizations, a good deal of production systems are setup as virtual machines so it is not a good strategy anymore to skip virtual machines and not infect them.

For example this old report from Symantec shows that the malware is infecting virtual machines (Symantec Report).

Malware authors try to incorporate other mechanisms to bypass automated analysis and detection and these days being run on a virtual machine on its own is not a pointer of a sandbox or analysis environment being present.
For example by sleeping for long periods of time before starting the operation or waiting for user interaction you can evade sandbox (or Detonation Boxes) in some intrusion detection systems, and of course this  is a cat and mouse game where we try to design sandboxes and analysis environments that can't be detected by malware and malware authors try to come up with new methods to detect these systems and prevent detection. (Detecting Malware and Sandbox Evasion Techniques by Sans)


Is there a way to verify the identity of a router over WiFi?

Two options:

Use a VPN on the client so any man in the middle is avoided and you connect to your network that way. Even if it does go through a bad actors.

Use RADIUS in a EAP-TLS configuration to offer authentication to radius clients and servers. The client in this configuration would be the AP and not the end users device (a common mis conception in RADIUS for new admins)


Maximum number of certificates generated by a CA

RFC 5280 states that "Certificate users MUST be able to
   handle serialNumber values up to 20 octets.  Conforming CAs MUST NOT
   use serialNumber values longer than 20 octets."
Of course one doesn't have to conform...

Edit: an octet is 8 bits  so if you have 20 octets that's 160 bits...for binary we have base 2 bits => 2^160 = 1.4615016e+48  AKA a really really big number...


How do HTML5 DRM addons protect their output?

According to my reading of the specification, this is not a problem that Encrypted Media Extensions are designed to deal with. Once it is verified that your User Agent is allowed to access the media and the media is decrypted, the CDM doesn't care about it anymore. It is then up to the User Agent to handle media protection from there (such as with the Windows Protected Media Path you mentioned).


MAC address spoofing is possible, but a) requires knowledge of existing, valid, not used MAC address b) tools - not that widely available for cable modems as for ethernet routers.

Certificate based authentication and encryption is available (Baseline Privacy Inteface Plus - DOCSIS 1.1 and DOCSIS 2.0, Security in DOCSIS 3.0) - see http://bit.ly/1iJMbNM for some more details.


Will using Tor make any difference if using mobile internet to connect?

I does not mather how you connect to the internet if you use Tor. The traffic will be encrypted anyway, so whoever controls the network you use - be it your ISP or your cell phone provider - will not be able to read it.

However if you do it by tethering, your cell phone company can see that you are using Tor and could potentially block it (just like your ordinary ISP would if you connected with your ordinary broadband).

Do note that MAC spoofing has nothing to do with this. Your MAC address never leaves your local network so there really is no point in spoofing it to stay anonymous on the internet.

Also, I would not call using Tor a form of IP spoofing.


Is there a security risk running web apps in debug=“true”?

I've had some interesting feedback on this question both here and on Stack Overflow. There have been lots of responses related to stack traces (a custom errors issue, not a debug issue) and performance (not [directly] a security issue).

The most compelling response is that conditional compilation constants (#if DEBUG...) could cause unexpected behavior, but this again is more of a functionality risk (unintended code being executed in a live environment), than a security risk.

I suspect debug mode may open some pathways to other exploits based on the performance overhead it places on the app and the ability to remotely detect it (service continuity risk, perhaps). I've written up my conclusions as part of OWASP Top 10 for .NET developers part 6: Security Misconfiguration.

So for the sake of completeness, the answer appears to be that there is no clear security risk from running in debug mode, but it certainly isn't a good idea for production apps given the factors mentioned above.


The general ways that a rogue access points are found:

An enterprise wi-fi access point spends some of its time not just serving clients, but listening on various channels for other wi-fi traffic. (This works best for the 2.4Ghz band where there are fewer channels. Fortunately this is also where most run-of-the-mill, non-targeted attacks are going to be. You can also use a dedicated sensor instead of an AP. You can also configure one radio of a two-radio access point as a full-time sensor radio.)

This information is typically reported to a centralized system (a controller, the controller-managing software, etc) through some mechanism (snmp trap, snmp polling, proprietary notification protocols, etc). You could probably write a centralized system yourself if you really felt like it, though in practice third-party interfaces with wireless equipments' SNMP can be a little bit hit-or-miss, and the data is not available in any standardized format. There are also patent-related implications, such as this one which is the one that I happen to know about.
The central system will perform checks to see whether that BSSID belongs to a known, valid access point that belongs to your organization's network.
The central system will analyze the reported rogue for security. (For instance, a rogue access point broadcasting MyCorp's SSID on an open network is a threat to MyCorp employees, but something broadcasting a different SSID, e.g. PANERA or NEIGHBORCORP-GUEST, or a peer-to-peer wifi connection, might not be a threat.)

Devices in the packet path, such as wi-fi controllers, can try to see if they have seen a MAC address on the wireless network which is also present on the wired network in an unexpected way. If they do, that's a sign that the wired network has been connected to the atmosphere, and you know what controller port it is connected to.
An active scan can be run on the organization's network, requesting web pages on port 80 or 443, and/or running a tool such as nmap, to look for indicators of common consumer-grade networking equipment (e.g. a Linksys login page).
The wired infrastructure (switches, routers) can be polled for bridge forwarding tables, which contain MAC addresses. These MAC addresses can be analyzed to see if they belong to an OUI of a manufacturer of wireless network equipment (e.g. Linksys).
You can install software on your organizations' laptops or other computers that report back many of the same types of information that the access point would detect (SSID/BSSID lists, etc) and report those to the aforementioned centralized system, or report what SSID the computer is actually connected to. It helps to be able to tell whether that laptop is in the office at home, or you'll potentially see many other access points.

Actions that can be taken against these devices include:

shutting down the network port at the switch (if the attacker is on your network)
forging 802.11 packets to disassociate clients from that access point, especially for wireless clients which your system recognizes as belonging to your organization (often called something like "rogue containment")
using a network-visualization tool that can trilaterate the location of the rogue access point from its signal strength (as reported by your access points) and your wifi network layout, then walking to that location and finding it in person

or using another signal-detection tool to track it down

The top 3 enterprise wireless vendors (Cisco, Aruba, Motorola) will all offer a wireless IPS with several or all of these capabilities, and some smaller vendors do as well. This is one of the many reasons they're more expensive than your cheap home Linksys wifi router.


How does entering "a" phone number help Google "verify it's me?"

Although it's strangely worded, it does make sense from Google's point of view, because:

If your account credentials are ever compromised, an attacker would be less willing to continue at this point, unless they are willing to use a throwaway number every time they hack someone's account. (Which probably isn't cost effective.) They certainly can't use their actual phone number as then law enforcement could potentially track them down. This could basically work to "verify it's you".
It enables Google to start using 2FA with you in the future. But since forcing 2FA might be frowned upon, perhaps they decided they'll only force it if you ever login from an unknown device.
This reduces the number of new email addresses created for spamming purposes. It's harder to get working phone numbers than it is to get email addresses, so by forcing a user to associate a working phone number that they personally have access to with their account, it cuts down on the number of newly created spam email addresses. I assume if you try to associate too many email accounts with the same number, you'll get shut down.


Why don't you put it to the locked cabinet or locked drawer in your desk? Keep it simple.


Why does not appear the public key from certificate?

(Updated with some background information)

For RSA operations, the public key consists of a modulus the product of two large primes, p and q, which are to be kept as secret, and an exponent, which is typically 65537.  Not always, but the binary representation of the latter (only two ones in 17 bits) allows for more efficient operations, so it's very common.

Since the key consists of two numbers, various techniques are available to make sure both are available for processing.

The original question was what this two different format means.  If you look carefully, the modulus quoted above is part of the "Public Key" hex string, starting at byte number 8.  Also, the ending in binary is 010001, which is 65537 in decimal, therefore it seems that "Public key" is indeed containing both of the values with some binary framing.

With X.509 certificates, most data is encoded with ASN.1 representations.  The ASN.1 representation is a very versatile (and complex) representation standard, most commonly encoded in two different formats: DER or PEM.  PEM is very easy to recognise as it's using a PGP like BEGIN/END framing, and DER is the raw, binary one.  PEM is actually the Base64 encoded DER, with the BEGIN/END lines around it.

To manipulate this data, the three most useful openssl sub-commands are "openssl x509", "openssl asn1parse", and "openssl rsa" (described respectively in the x509(1), asn1parse(1) and rsa(1) manual pages).

As the hex encoding above does not look to represent text, so it seems better to look at it with the asn1parse(1) tool, after converting to binary.  I did the conversion by hand, to be used by the xxd(1) tool, usually supplied with the vim(1) package; the "xxd -r" command is used to reverse the hex display of the same command.  Again, as this example is quite short, so I simply added the prefix lines, and broke lines at the 16 bytes boundary:

 % cat pub.txt
 00000000: 3081 8902 8181 00CC CB64 54C2 FAA3 7A81
 00000010: 365F 1BD5 1081 75B7 4202 3183 B1D5 5A76
 00000020: 726A 77BE 6269 16AB EB39 66B5 2039 33D1
 00000030: B401 7D23 4024 9E60 1CA8 3283 EA9D F1F2
 00000040: D9F0 1885 9DE1 C0E2 99FF 89A4 F915 BD5D
 00000050: BA3F 392E 2614 4880 75EF B5C0 946E 2A62
 00000060: D242 342C 4A15 1758 B055 9811 6E91 FD28
 00000070: 0D80 C521 C23E FB78 6F38 314A 78F2 812D
 00000080: 85C9 B82B F186 C902 0301 0001

Now's time to convert to binary, and check if it's really an ASN.1 encoding:

 % xxd -r <pub.txt >pub.bin

 % openssl asn1parse -inform der <pub.bin
     0:d=0  hl=3 l= 137 cons: SEQUENCE
     3:d=1  hl=3 l= 129 prim: INTEGER           :CCCB6454C2FAA37A81365F1BD5108175B742023183B1D55A76726A77BE626916ABEB3966B5203933D1B4017D2340249E601CA83283EA9DF1F2D9F018859DE1C0E299FF89A4F915BD5DBA3F392E2614488075EFB5C0946E2A62D242342C4A151758B05598116E91FD280D80C521C23EFB786F38314A78F2812D85C9B82BF186C9
   135:d=1  hl=2 l=   3 prim: INTEGER           :010001

It indeed is - and we can see the two integers described above.  Just as an example, we can convert it to PEM, which may look more familiar.  We know it's an RSA key, so we can check the rsa(1) tool, and after making sure we specify DER format, and one(!) of the RSA public key variants, it indeed parses the binary successfully:

% openssl rsa -RSAPublicKey_in -inform der <pub.bin
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMy2RUwvqjeoE2XxvVEIF1t0IC
MYOx1Vp2cmp3vmJpFqvrOWa1IDkz0bQBfSNAJJ5gHKgyg+qd8fLZ8BiFneHA4pn/
iaT5Fb1duj85LiYUSIB177XAlG4qYtJCNCxKFRdYsFWYEW6R/SgNgMUhwj77eG84
MUp48oEthcm4K/GGyQIDAQAB
-----END PUBLIC KEY-----

(There is another format actually, which would show up as BEGIN RSA PUBLIC KEY, but the above is usually how the key is represented inside the certificate.)

This all is just an excercise to see what the data supplied in the question actually is.  The raw RSA public key is only theoretically useful, as it's handled during the SSL/TLS handshake, and that requires most of the certificate data as well.  In theory, you can try following/debugging the handshake, but it's generally more complicated - with PFS, it's not even possible, even if you have the public and private keys. PFS - Perfect Forward Secrecy means there's a random Ephemeral key agreed during the handshake that only the two endpoints know - not even us observing the handshake.

The only useful purpose I've seen that needs actually looking at the public key is to compare the modulus of the public key with the modulus computed from the private key.  This is necessary if you want to check which, or if the, private key is corresponding to the public key in the certificate.

The commands to do this are somewhat different, as you usually have the key as part of a certificate (in PEM encoding), and the private key in the RSA format in PEM encoding as well:

% openssl x509 -noout -modulus -in myserver.crt
% openssl rsa -noout -modulus -in myserver.key

The two numbers should match if you want to use them together (sometimes you just compute the md5 for the above outputs, which makes for an easier comparison).


Where to put private files on a shared web server

If it's that important, there's not much you can do. Any steps you take can easily be thwarted by a misconfigured server. If the file must be within the Web root, then your only option is to use whatever mechanism your server allows to disable access to these files (e.g. .htaccess for Apache).


RSA fingerprint automatic change or have I been hacked?

The first thing I will say is ouch.  The typical reasons for a finger print change are the ssh server key was re-generated (by someone), the sshd reinstalled (not just updated from yum or apt-get), your local ssh client reinstalled or --- the real reason for the check --- there is a man-in-the-middle.

In the key update scenarios, either you did it or someone else did it.  If it wasn't you, then you are likely compromised.

In the MITM scenario, everything you typed was captured and is now replayable by an adversary.  In which case you are likely compromised.  Nothing is hidden from the MITM.

So, before you assume you are compromised, please check to make sure Dig O does not manage your service for you and does not make these changes on your behalf.  Also, if you updated your local ssh client then they key could have been stomped on.  Look for logical reasons not to expect the worst --- but you are very very correct to be paranoid.  [personally I always expect the worst.  I have worked many many dozens of very significant intrusions.]

In the worst case you merely have to scratch the OS and restore your data (not executable files, libraries, passwords or ssh_keys from a potentially corrupt backup, but just your data.  If you restore services you have a race condition ... update the authentication passwords instantly.

All this assumes that any intrusion doesn't start with your local client and have propogated to the remote server -- :).

In general you should understand where that message came from and if it wasn't you -- time to get to work.


DOM based XSS using window.location.hash

Is there a way to bypass this URL encoding

No, modern browsers correctly URL encode this value, and that cannot be bypassed.

But that's not the only problem. There's actually no double-quoted string here which you could escape with " (nor a single-quoted one which you could escape with ').

There was a jQuery vulnerability in earlier version where $('#') would lead to XSS, but that is fixed in recent versions.

$('') still leads to XSS, but there is no way to get rid of the # (and the URL encoding would also still be in the way).

Given all of this, I would say that the code isn't vulnerable.


Is there a Standard Verification process for Certificate Authorities to follow?

This document can give you an historic overview of how standardisation for CAs has evolved.

EDIT:

A fragment of the document that gives a well overview:

  The first requirement imposed specifically on CAs as a group was in
  2000 when an annual security audit under the WebTrust for CAs
  standards was mandated by browsers and others with trusted root
  stores. See the original WebTrust audit standards available at
  http://www.webtrust.org/homepage-documents/item27839.aspx. These
  standards have been updated from time to time, so the current WebTrust
  audit standards are reflected in the detailed v.2.0 requirements found
  at the same link. Even before the first WebTrust for CAs standards in
  2000, most CAs also underwent annual performance audits under SAS 70
  standards (later replaced by SSAE 16 / SOC 2 / SOC 3) – and many still
  do in addition to WebTrust. Nearly all CAs in North America follow the
  WebTrust standards, but CAs in other parts of the world may be audited
  to the equivalent ETSI (European Telecommunications Standards
  Institute) audit standards – see www.etsi.org. Government CAs must
  submit equivalent government performance audits on a periodic basis as
  well.


If the attacker is good enough to make me submit a form (as mentioned
  by OWASP) what would prevent him from getting the token before
  submitting?

The only skill an attacker needs to have is the ability to write HTML and javascript and know what the request they are trying to attack looks like.  These are all things that are easily accessible and are not secret in any way.

So your assumption that the ability to create a form somehow means they can predict random tokens is incorrect.

Each token is unique to an authenticated user and unless there is another vulnerability, there isn't a way to figure out what that token is.

Based on how your question is phrased I'm not sure you have a full grasp of how CSRF works.  This isn't meant as an insult - it can be a difficult concept to grasp initially.

My suggestion would be to create a form that is vulnerable to this type of attack and then execute an attack against it.  This is an excellent way to get a thorough understanding of how this attack works.  Once you do this - I suspect you will understand this answer better.

Cheers!

UPDATE:

It seems like you might be assuming that CSRF and XSS are the same thing.  Just to clarify - in a site with only a CSRF vulnerability, a malicious user cannot insert any javascript.  So there is no way to use javascript to get the token.  If a site has an XSS vulnerability - then there is no need to execute a CSRF attack, because it would be much easier to simply inject javascript that does what you want.  Also - a CSRF is a "one way" attack, meaning you can send a request as someone, but you can't read the result.  Does this make sense?

UPDATE 2:

regarding your comment:

  Thanks for clarifying, I was looking at the OWASP page linked in the
  question, section POST scenario, the submit onload, isn't that a CSRF
  attack with javascript injection?

Ahh - I see your confusion.  No, the javascript they are showing is on the site controlled by the attacker.  So if the attacker controls evil.com the javascript would be on there, and it is simply used to launch an HTTP request to targetSite.com using a users existing session.  CSRF is an attack on existing sessions that takes place at the HTTP request level.  It might use javascript to launch this attack, but the attack is still an HTTP request.


Would an offline-authorized EMV transaction use offline PIN validation?

Generally true. It depends of Cardholder Verification Method (CVM) List of terminal and card. Offline pin would perform if both support offline pin and if it has highest priority in CVM lists.


Someone is using my email to create online accounts; what should I do?

Nothing much you can do. Check this very interesting chain from Google: https://support.google.com/mail/thread/6055937?hl=en

  I have tried working with them, but they claim they were able to register the email, with the identical name (no dot). As this "bug " is now sharing that person's PII with me, and Google is located in California, I would think they would want to resolve this issue. However, there is no way listed of speaking/contacting someone at Google to resolve this.

Claim, being the keyword here. You will see this is a recurring pattern of phishing information. People will contact the other side, which claims that they get the same emails and when you ask them to forward one then communications stop.

Not much point changing emails, it can happen for any addresses, like other spam does. The bothersome thing is that those emails get through your provider's filters whereas spam doesn't.

My suggestion is to whitelist addresses for your account instead of blacklisting. This way only certain people can get to your inbox and when you want to register, you can always access your junk mail and add this new domain to your whitelist.