Using Two Different Brands of Security Tools To Block Backdoors

Funnily enough I have seen this technique recommended in some NSA best practice documentation pre-Snowden. See #1 under Network Recommendations in Best Practices for Keeping Your
Home Network Secure. It refers to routers and not firewalls, but most routers are also operating as firewalls.

I believe this is mostly academic though as I would like to point out that while yes deliberate back-doors in both products will be difficult to exploit without knowledge of both back-doors, you're neglecting the more simple occurrence that it's possible there's vulnerabilities in both, some perhaps even yet to be discovered that are just down to sheer coding error like buffer overflows or as complicated as the shellshock vulnerabilities. With enough expertise and time I'm sure some vulnerabilities could be discovered in either product, back-door or no back-door.

A lot of routers/firewalls will end up using Linux and likely some version of OpenSSL. So any vulnerabilities discovered in both will still likely be exploitable in both devices.


Feedback for Study Plan (Kali Linux & Penetration Testing)

It looks good to me but I can recommend you also to learn at least one or two programming languages (Definetely Python, JavaScript and maybe C/C++ at least you sholud know basic knowledge).

You can also download vulnerable application like DVWS http://www.dvwa.co.uk and test in your local environment. You can also download metasploitable linux vulnerable operating system.

I recommend also to download BurpSuite and learn as much as you can about HTTP protocol.

Obviously if you have some spare money you can go for practical certificates like OSCP or at least subscription to SecurityTube.

You can add to the list also some books about cryptography (I recommend B.Schneier books).

I suggest also to use this forum because you can learn a lot from here.


Thoughts on creating unscalable conditions to brute force even small passwords?

I won't mark this a duplicate (in fact, I'll kick you a +1), but I will primarily answer by pointing to Do any security experts recommend bcrypt for password storage?

The accepted answer there is from our resident cryptographer. The concept itself, mentioned in another answer, is key stretching. For that, there are RFCs, NIST-suggested algorithms, and papers published as references on the Wikipedia page as far back as 1978.

Reading up on those materials should give you a good understanding. See also our sister site crypto.stackexchange.com where algorithm internals are discussed.


What are best practices considering the use of Apple data protection?

For the passcode, you just need to use something that's not easily guessable by the attacker, who only has 10 attempts before access via passcode is disabled.

So no 0000 or 1234 or the year your kid was born or such like.

As well as this, other best practices would be:

Turn data protection on in the first place.
Protect the backups - this is way more important than protecting the device.
Train your users to report lost/stolen devices immediately so you can remote wipe them ASAP.
Don't assume all apps encrypt their data.


Interesting thought.

What you need is a digital signature.

  A digital signature is a mathematical scheme for demonstrating the
  authenticity of a digital message or document. A valid digital
  signature gives a recipient reason to believe that the message was
  created by a known sender (authentication) and that the
  message was not altered in transit (integrity). Digital signatures are
  commonly used for software distribution, financial transactions, and
  in other cases where it is important to detect forgery or tampering.

See more at http://en.wikipedia.org/wiki/Digital_signature.

  Is this assumption correct and is this method secure?

I believe your method is secure, but use digital signatures instead, they were made to this.

  Stealing the private key (tampering it from the app), can an attacker
  generate cypher texts like with the public key?

Using the private key you can't cypher a text like using the public key.


Is there any good reason to move files outside webserver document root?

I think that by including it in the webroot, you may leave yourself vulnerable to some bypass if you do not write the .htaccess correctly.

If you keep important files outside the webroot in a directory such as /opt or /etc/web_program_folder/data, there's no way they will be able to access that data without a local file inclusion vulnerability as apache or nginx (whatever you're using to serve the application) will not allow them to traverse up into the /opt, /etc directories.


It's definitely supported, and definitely one of these format names (one for CPU, and the other for GPU):
$ john --list=formats | tr ',' '\n' | grep PBKDF2 | grep SHA1
 PBKDF2-HMAC-SHA1
PBKDF2-HMAC-SHA1-opencl

At this point, it sounds more likely that your method of generating PBKDF2-HMAC-SHA1 is the issue here. Have you tried your attack against a "known good" hash? One that's easy to grab and almost certain to work is the example that ships with John itself:
$ john --list=format-details --format=PBKDF2-HMAC-SHA1
PBKDF2-HMAC-SHA1    125 16  128 01020003    22  PBKDF2-SHA1 128/128 AVX 4x  0x107   20  192 iteration count 0   $pbkdf2-hmac-sha1$1000.fd11cde0.27de197171e6d49fc5f55c9ef06c0d8751cd7250

... which should be crackable by dropping it into a file and running john against it:
$ cat test.hash
$pbkdf2-hmac-sha1$1000.fd11cde0.27de197171e6d49fc5f55c9ef06c0d8751cd7250

$ cat wordlist.txt
3956

$ john --format=PBKDF2-HMAC-SHA1 --wordlist=wordlist.txt test.hash
-rwxr-xr-x 1 royce royce 24690360 Jun 16 14:50 /usr/local/src/sec/crack/john-latest/run/john
Using default input encoding: UTF-8
Loaded 1 password hash (PBKDF2-HMAC-SHA1 [PBKDF2-SHA1 128/128 AVX 4x])
Cost 1 (iteration count) is 1000 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 16 needed for performance.
3956             (?)
1g 0:00:00:00 DONE (2020-07-25 05:40) 4.347g/s 4.347p/s 4.347c/s 4.347C/s 3956
Use the "--show --format=PBKDF2-HMAC-SHA1" options to display all of the cracked passwords reliably
Session completed.

One common error is that, if you're trying to crack the hash on the command line directly and not attacking hashes within a file, depending on your operating system and shell, the '$' has special meaning to the shell (variable substitution) and results in the hash being mangled. Putting the hashes in a file, or putting appropriate quotes around the hash, or escaping the dollar signs (usually with a backslash), will address this issue.
If that's not it, then it's most likely that there's something wrong with how your hashes are being generated.


First off, I'd consider calling support:
https://support.skype.com/en/faq/FA109/i-ve-forgotten-my-password

Secondly, a recovery process has been outlined here: http://insecurety.net/?p=427

It is NOT as simple as running JTR on the conf.xml file ....


The Defensive Security Podcast put together an article on that topic - Entering The Infosec Biz.


Properly implemented, load balancing can be totally transparent; you may need to rely on other means (such as hunting though job ads for the company) to try guess at likely products.

However there are a few things you can check that at least imply the existance of a balancer:

The HTTP headers may reveal the presense of a proxy server or other balancer.

Check here for different timestamps as well, implying slightly different clocks.
Check the order of the headers as well.

Observe the system under load

Generate a ton of traffic; see if your requests start going somewhere else, or if the headers change, etc.

General reconnaisance

The DNS response may reveal multiple IP addresses, implying balancing.
They may give it away in the hostname (cdn.xyz.com)
You may be able to get some more info from netcraft.com that leads you in the right direction

The manual  for halberd contains a good list of concepts that it uses (Date comparison; MIME header ﬁeld names, values and their order; Generating high amounts of traﬃc; Using diﬀerent URLs; Detecting server-side caches; Obtaining public IP addresses).

Using halberd or ldb is likely your best option in a practical situation - a lot of these tests are time consuming and finicky, so you likely want to automate all the busy work.


Is it possible to improve brute-force guessing of a password with a picture of the keyboard used to enter it?

In some cases yes, you can guess the most frequently used keys by the wear marks. That's how I know that apparently I use the L, M, N, A and E keys a lot - the keys are now just black, the letter is faded.

And one special key being significantly more used than the others - unless it's "{", "}" or ";" and you happen to be a programmer - could allow to include that in a bruteforcing, or exclude others (this is definitely NOT my keyboard, but still):

But most people don't use the keyboard for just their passwords, and the wear pattern is also influenced by the stroke direction, angle and pressure - keys farther down the keyboard will be pressed differently from those nearer. The keys I wear faster appear to be exactly under the hand that controls them, and now that I noticed, I hit them harder than the rest (OK, also I'm a horrible typist).

The keyboard might hint (weakly, at that) at what the most frequent typed word, or anagrams thereof, might be. But that's not the same as your password except in very specific cases (e.g. an entry keypad).

In even more specific cases such as heat-conducting entry keypad, FIR or strong UV picture taken immediately after typing so that residual heat or fluorescence or phase interference from skin oils may be appreciated, you might be able to get something. But an ordinary picture conveys no such information.

So my opinion would be that keyboard pictures are mostly harmless.

On the other hand, I sometimes see Post-It with letters and numbers on them attached to monitors and on woodboards behind selfied people, so I'd also say that it's always a very good idea to review the photos (as well as whatever else) you post to the social media, looking at the goods with an attacker's eye:

inside view of (broken/defective/jimmied?) locks and/or brand names useful to research approaches
hints about location (this might be relevant to determine whether you're holidaying abroad, and estimate how long your home will be vacant)
valuable items (might give people ideas either about them, or about your wealth, which also could give people ideas)
discrepancies between what's shown and what you told anybody who might get to know, such as employer, insurance company, significant other(s), etc.

At least once, some months after this answer was posted, the last case actually happened.


How Secure is Microsoft ASP.NET Core Identity?

"How Secure is X" is a subjective question unless you are talking about something which is provably secure (like a randomly generated one time pad) or undeniably secure by today's standards (like AES-256). Unfortunately, this is not one of those cases. For most uses I think it would be fair to say that Identity version 3 is "secure enough", but there are those that still advocate taking it a step further by increasing the iteration count or using a different hashing algorithm.


I do not see any public key being "attached" into the CSR.

It's there. Here's where:

When you generate your key like so:

$ openssl genrsa -out server.key 1024
Generating RSA private key, 1024 bit long modulus
....................................++++++
......++++++
e is 65537 (0x10001)

And you generate your CSR like so:

$ openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:dummy.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Then the public key will be inside the both the:

Private Key file:

$ openssl rsa -in server.key -pubout
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4IPFCBOLLyJWtx37bibBKhKvE
9MbfD0MV8bXU544dVXvWZwLQwluyrsYebpl+4K1aLNmh01qUwBsm4GxESZo4mF3L
13Yki7Xlw95KJVgDBN0i1j96LgaxV/4K8z4RQ1MryGw+EHYFK/5pwtLxGN7Rn7kB
L9HOPEkwfwWbenUikQIDAQAB
-----END PUBLIC KEY-----

CSR file:

$ openssl req -in server.csr -noout -pubkey
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4IPFCBOLLyJWtx37bibBKhKvE
9MbfD0MV8bXU544dVXvWZwLQwluyrsYebpl+4K1aLNmh01qUwBsm4GxESZo4mF3L
13Yki7Xlw95KJVgDBN0i1j96LgaxV/4K8z4RQ1MryGw+EHYFK/5pwtLxGN7Rn7kB
L9HOPEkwfwWbenUikQIDAQAB
-----END PUBLIC KEY-----


Is it safe to mix authentication methods?

If entering a valid username+password pair grants access to a "token" which is used to authenticate with regards to another server, then you are mostly propagating the first authentication. It then really depends on the specifics of your setup.

For instance, suppose that you have a certificate-with-private-key file (as a PKCS#12 file, aka "PFX") available on a server. The server will send it to any user who successfully authenticate with a password. The user can then import the certificate into his own machine, and use it to connect to another server which requests a client certificate. For the overall system, you are using password-based authentication, because an attacker just has to guess the password to obtain the certificate, and then be granted access to the second server. However, the attacker could also try to hack into the first server, and will get the certificate, and then will be able to authenticate to the second server.

As the example above illustrate, this is a generic rule: when you link authentication methods as a chain of successive steps, you tend to obtain something which is as weak as the weakest of the links (for once, the "chain analogy" works well).

There are other ways to combine authentication methods, and are known as multi-factor authentication. This is what happens when a server requires several authentication: you may access the data if you type a valid password and you show a valid certificate. Contrary to the example above, the second authentication method is not unlocked by the first one; instead, the server requires both, independently of each other. In the "chain analogy", the authentication are not successive links in a single chain (the attacker just has to break one link), but nested reinforced tubes (the attacker must pierce them all).


Provide subjectAltName to openssl directly on the command line

Based on link from DarkLighting, here's the command I came up with using nested subshells.

openssl req -new -sha256 \
    -key domain.key \
    -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com")) \
    -out domain.csr

All one line:

openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com")) -out domain.csr

Example use:

user@hostname:~$ openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com\n")) -out domain.csr
user@hostname:~$ openssl req -in domain.csr -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=CA, O=Acme, Inc., CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a8:05:50:86:49:98:c8:05:01:e9:50:18:7f:2f:
                    b4:89:09:29:d1:c1:58:d8:14:bb:58:1d:25:50:11:
                    bb:43:d8:28:03:a5:de:59:49:bb:d2:f7:d3:79:5c:
                    c6:99:2c:98:ff:99:23:8c:df:96:7c:ea:4b:62:2a:
                    a4:c2:84:f5:5d:62:7f:7d:c4:7c:e2:c3:db:e6:58:
                    03:c2:26:9d:02:da:bb:84:d9:11:82:fe:38:12:9b:
                    c7:b6:ff:b2:40:30:38:b1:44:d8:47:1d:43:4a:29:
                    58:6b:49:ec:33:d7:dc:a7:1b:90:05:3a:f5:e6:16:
                    98:08:5d:2d:7e:b4:ea:a2:a4:b1:84:89:f7:f1:c4:
                    67:a6:a1:06:70:dd:4e:6b:0c:f8:b5:9b:bc:3f:06:
                    ee:90:d6:86:29:52:d3:af:f6:d4:2f:c6:cf:4b:5a:
                    b8:cd:01:74:6d:5c:25:a8:02:1c:7c:e8:66:3d:46:
                    07:b1:9d:ef:cc:eb:90:b6:bf:7b:33:e0:5f:b2:9b:
                    e8:b4:12:67:2f:8d:0d:9b:54:9d:95:6e:09:83:cb:
                    f3:5b:1f:31:8e:3b:ca:4e:08:e0:40:c0:60:40:72:
                    dd:0d:3e:99:ec:7c:ac:c4:3c:ba:85:9d:d9:d9:6b:
                    02:2e:bf:a8:a3:02:1d:eb:c8:58:e3:04:b3:a5:f1:
                    67:37
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:www.example.com
    Signature Algorithm: sha256WithRSAEncryption
         a2:1d:1a:e8:56:43:e7:e5:c7:c1:04:c1:6a:eb:d5:70:92:78:
         06:c1:96:fa:60:e2:5f:3c:95:ee:75:ed:70:52:c1:f0:a7:54:
         d2:9f:4a:2f:52:0f:d4:27:d8:13:73:1f:21:be:34:3f:0a:9c:
         f1:2a:5c:98:d4:28:b8:9c:78:44:e8:ea:70:f3:11:6b:26:c3:
         d6:29:b3:25:a0:81:ea:a2:55:31:f2:63:c8:60:6d:68:e3:ab:
         24:c9:46:33:92:8f:f2:a7:72:43:c6:aa:bd:8d:e9:6f:64:64:
         9e:fe:30:48:3f:06:2e:58:7c:b5:ef:b1:4d:c3:84:cc:02:a5:
         58:c3:3f:d8:ed:98:c7:54:b9:5e:50:44:5e:be:99:c2:e4:03:
         81:4b:1f:47:9a:b0:4d:74:7b:10:29:2f:84:fd:d1:70:88:2e:
         ea:f3:42:b7:06:94:4a:06:f6:92:10:4c:ce:de:65:89:2d:0a:
         f1:0f:79:90:02:a4:b9:6d:b8:39:db:de:6e:34:61:4f:21:36:
         a0:b5:73:2b:2b:c6:7e:2f:f2:e5:1e:51:9f:85:c8:17:9c:1a:
         b6:59:b0:41:a7:06:c8:5b:f4:88:92:c9:34:71:9d:73:f0:2e:
         31:ae:ed:ab:35:0e:b4:8a:9a:72:7c:6f:7a:3e:5d:66:49:26:
         26:99:e1:69


Recover the prior contents of RAM from a turned-off PC?

There is an element of truth to this one - an attack was discovered which took advantage of data remanence in RAM, allowing an attacker to grab data from the RAM in a machine. There was a very short timeframe (a matter of seconds or minutes) in which to do this, but it wasn't a hack of the PC as such.

Simple Wikipedia link to Cold Boot Attack here

And the McGrew link here giving more detail


Attack Challenge/Response Authentication by requesting challenges

The two concerns you've raised are:

The server's copy of the server nonce can be altered by an attacker who doesn't know the password.
As the server's list of client nonces grows without bounds, it can be used in a DoS.

A common technique is to time-limit the nonces. Say, for M minutes for an appropriate M.

For the first problem, by time-limiting the nonces, the server can maintain multiple authentication sessions with the client, each one keeping track of it's own nonce. This isn't a large resource drain on the server as these sessions are automatically deleted after M minutes.

The second problem is resolved by time-restricting client nonces. For this to work, the client nonce must include a timestamp. Otherwise you're open to post-timeout replay attacks, when the server cleans out its expired nonces, thereby "forgetting" used nonces. So the client's nonce should be timestamp + secure random number. By including the timestamp in the nonce, it ensures that the nonce cannot be used post-timeout.

WHen determining the value of M, it needs to be large enough to handle network communication times and clock differences between the server and the client. M needs to be small enough to sufficiently lower your resource requirements. M being 1, or even less than 1, may be appropriate if no user interaction is required during the authentication process. If there's user input required, a larger M will be needed.

A well-resourced attacker may still be able to execute a DoS upon you as there is still a window of M minutes for this to occur. But this is a small window and would require a lot of attacker resources. That is, it would be a DDoS and not a straight DoS. Surviving DDoS attacks are a problem of their own.


Do security questions pose threat to the user?

You should absolutely lie!
Security questions are only looking for a match, answers needn't even be in context to the question (usually). Not only should you lie you should lie differently everywhere.
Favorite Food:  A Red Bicycle

Of course this puts the onus on you to keep track of your lies.
Two Factor Authentication (2FA) should be used if possible/practical.
An aside on lying:
My wife was working as a librarian and was dealing with children signing up for a summer reading activity. The sign up asked for Birthday as an age determinant. My wife told the children not to put down their actual birthday, just their actual year. The children were slightly aghast at an adult telling them to lie, but it was the parents that occasionally became irate at the suggestion that their child should ever lie.


Is a VPN really secure at the VPN providers side?

If this is the case, am I not just pushing my data further along?

Correct. A VPN is designed to give you a secure connection to the VPN provider; it essentially simulates your being physically on their network. For instance, a corporate VPN simulates being in the office physically connected to the corporate network. This is great when there's some reason to trust the VPN network more than the network you're on for the things you're doing; however, all it amounts to is substituting the VPN provider's network for the network you're on.


There is another big risk: SSH agent forwarding. If you use agent forarding, anyone who is root at the server you SSH into, can use your ssh private key to establish new connections. See http://unixwiz.net/techtips/ssh-agent-forwarding.html for more info on agent forwarding.


Why would I need to use the PRIVATE key to verify a file signature?

I was able to sign with private key and verify the signature with public key, and I want to share with you.

In SignXml() function I exported public key from private key:

Dim publicKey as String = tmpRsa.ToXmlString(False)

Then in the same function I call verifyXml() function:

Dim verifySign As Boolean

verifySign = VerifyXml(doc, publicKey)

In verifyXml() function I took public key on this way:

Public Function VerifyXml(Doc As XmlDocument, Key As String) As Boolean

     Dim tmpRsa As New RSACryptoServiceProvider()
     tmpRsa.FromXmlString(Key)

     Dim signedXml As New SignedXml(Doc)

     Dim nodeList As XmlNodeList = Doc.GetElementsByTagName("Signature")

     If nodeList.Count <= 0 Then
        Throw New CryptographicException("Verification failed: No Signature was found in the document.")
     End If

     If nodeList.Count >= 2 Then
        Throw New CryptographicException("Verification failed: More that one signature was found for the document.")
     End If

     signedXml.LoadXml(DirectCast(nodeList(0), XmlElement))

     Return signedXml.CheckSignature(tmpRsa)

End Function


What do I risk if I use CSP header style-src-attr 'unsafe-hashes'

CSS can dramatically alter the way a page looks and even add content to the page.  It's possible to hide content, such as privacy or security notices; show content, such as phishing information; or alter content, such as by forcing elements to the foreground or background.  You could also use it to insert hidden or nearly hidden content to try to game search engine rankings, or to make the page into a totally different looking page.
If you're using unsafe-hashes, then you've by definition hashed the content and know what's in it.  If it's just doing something innocuous like adjusting the list type marker or setting a relative font size, then it's probably fine.  If the page is doing something more questionable, you have to decide what the tradeoffs are.
You may wish to think about what the consequences would be if the script added that style to many elements, nested elements, or unexpected elements.  If you're pretty sure that the only consequence is making the page look ugly or unreadable, then the risk is low; users will alert to you cases where your page looks hideous.


I'm not able to understand how can the malicious domain access facebook account from a different tab and how does SOP protect against this?

Tabs are not isolating entities. That is, cookies are shared between every window a browser has open, including all tabs on those windows. The only exception to this are private/incognito windows. Therefore, if a tab open on evil.com makes an AJAX request to facebook.com, your auth cookies from facebook.com will be sent along with the request. The Same Origin Policy prevents evil.com from reading the response from facebook.com as the domains do not match.

  The malicious domain is free to send a GET/POST request to facebook.com, and the browser will attach a cookie for facebook if available. But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case?

CSRF protection should only prevent unsafe methods - actions with side effects. That is:

  the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

So if the site has been implemented with respect to this convention, CSRF protection should only be active for POSTs (technically PUT and DELETE too, but these are rarely used).

As said, the SOP does not stop requests from being made, only the responses from being read. Even with the SOP, evil.com could make a POST request to facebook.com's "Delete Account" page, and if the user was logged in to Facebook, cookies would be sent.

However, if Facebook have implemented CSRF protection using tokens on the Delete Account page then a CSRF token will need to be submitted with this POST. evil.com can make a GET request to facebook.com to the page containing the CSRF token. However, the SOP prevents the response from being read. The SOP protects Facebook's CSRF tokens and prevents CSRF attacks from happening when protected by tokens.


Can Signal encrypted voice calls be listened into by other apps?

At the moment

Currently, the best way is to kill apps in the background that have microphone permissions, which is a bit of an ugly hack, and if you do not kill the apps fast enough they will be able to record snippets of your call.

https://stackoverflow.com/questions/17467120/exclusive-access-to-the-microphone-in-android

In the future

Android P appears to fix this, by making apps in the background act as if the microphone is silent, along with several other sensors.

https://www.theverge.com/2018/3/7/17091104/android-p-prevents-apps-using-mic-camera-idle-background


Stealing document.cookie from Google domain, is this a privacy breach?

Well, even if Google was vulnerable to XSS, this still wouldn't be a breach.

Why? Because of the HTTPOnly flag. It is the big reason for XSS's downfall.

You can say there are two kinds of cookies:

those that your browser gets when it recieves an HTTP response from a remote server (like google.com). They are in the Set-Cookie part of the response.
cookies set by JavaScript dynamically after you've opened the webpage, which can then be read by your browser.

What's the HTTPOnly flag? It is a flag on a cookie which means that it strictly falls into the first category only, and not the second. I.e. HTTPOnly cookies can be read by the browser only as part of the HTTP response, JavaScript has no access to them.

That is why, when you use document.cookie, be it an XSS scenario or not, you only get the not-HTTPOnly cookies. There is usually nothing important stored in these; all adequate and security-savvy webmasters keep the session cookies as HTTPOnly.


How can I ensure higher levels of privacy when hosting others' emails?

If you are the administrator and have full access, there is no practical way you can protect your users from you going rogue. You can encourage them to use PGP encryption or S/MIME, but you simply cannot protect them from yourself while still supporting standard, plaintext emails to arbitrary email providers. However in the end, it is unlikely that you will be much of a threat to them. One moderately popular email service provided a quote explaining the situation perfectly:

Administering a mail host is sort of like being a nurse; there's a brief period at the start when the thought of seeing people's privates might be vaguely titillating in a theoretical sense, but that sort of thing doesn't last long when it's up against the daily reality of shit, piss, blood, and vomit.
Now that I think about it, administering a mail host is exactly like being a nurse, only people die slightly less often.

You may want to put yourself into a privacy mindset. You can do this by communicating to your users that you take their privacy seriously using more than a privacy policy with the tired old staged claims of taking your privacy "very seriously". For example, you may want to consider publishing all subpoenas you receive. You may want to encrypt the database and advertise that fact to show that you are trying to protect from HDD theft. You may even want to have an FAQ on the privacy problems inherent to email, in which you can and should explain that they need to trust you. Doing all of this will not only improve other people's trust in you, but will put you in a mindset where violating someone's privacy transitions from a mildly rude offense to an unthinkable violation.


This depends slightly on what type of wireless networks you're authenticating too.  If it's practicable to have the client only authenticate to the Corporate wireless network then you could use 802.1x and server certificate validation to ensure that the client is connecting to an authentic AP.

For home Access Points, the best bet would be to set-up WPA2-PSK authentication and then only connect to the encrypted network. Attacks like Karma are primarily targeted at open networks (e.g. coffee shop wi-fi)

Without that for unencrypted networks there's nothing that I'm aware of at the wireless layer that would guarantee that the AP you're connecting to is authentic (the only identifiers (SSID and BSSID) are spoofable).

So really at that point you need to head higher up the stack for an answer.  What I'd say for situations where you're connecting to hotspot networks or other general wireless networks is that the answer is to establish a VPN connection with validation of the servers authenticity (e.g. SSL certificate validation) as soon as the connection is established (and ideally with a security suite which prevents all outbound connections apart from over the VPN tunnel)


Recommended practice for laptop encryption: nested encryption?

Nested encryption is usable as an access-control, but doesn't help against all the other problems you get with sharing identities/systems which is something you may want to consider as well.

Handing an unlocked laptop over to someone else is pretty much always a bad idea, if only for attribution. Don’t share accounts, including computer accounts. Pretty much all modern systems allow for easy multi-user computing with fast user switching. If you both need to work on the same file, Apple, Microsoft and Google support this using iWork, Office and Docs.

Computers and user accounts are personal items. Treat them like your underwear: you should be the only user.

To elaborate on the 'handing over an unlocked system' part, this basically means that you are no longer in control of what happens from that point onward. Even without malice in mind, this is not something you should accept. Because the system is 'yours' and your account is 'you', this means that everything that happens on that system is attributed to you. At the same time, many external systems might still assume that if it is your system accessing or doing something, it must mean it is 'you' doing the thing or accessing the stuff. It cannot differentiate who is at the controls, only what requests are made and served.

A scenario:

You hand over your unlocked system to someone else and need to do something somewhere else where you no longer have the machine and its user in sight. At that point, the (non-malicious) user might be doing the intended thing, like looking up some data or filling in some forms. A popup might appear, or a site might be visited which after interaction or sometimes even without interaction persistent malware is introduced to the system. The user might not know this, or might not care, or forget about it or even assume this is intended as your system might be setup in a way that is different from what this user is used to. You return and after the user is finished, you get to work on your machine. The persistent malware now tracks all activity and some NDA'ed information gets leaked. This information just happens to be watermarked with your identity, and turns up somewhere. Now you're on the hook for leaking information that should not be publicised and they can prove it is yours because of the watermarking. Now it is up to you to prove that it was stolen/extracted/leaked and not something you intended to have happen.

While this often can be resolved, it will still take a lot of time, resources and attention which could have been spent on other things of your choosing.

Instead of having anything like this happen, you could also just setup the system in a way that prevents this from happening in the first place, but still retain the possibility to work together on the same data or applications. This can be done in a number of ways, for example:

Work on separate accounts, share data as needed
Work on systems that are intended for collaboration
Use the OS-provided guest account and share data using the guest-accessible storage methods (i.e. the read-only Public and write-only Drop Box directories on macOS)

Many of the security-related issues translate into possible wastes of resources/time in case something does go wrong, and not immediately loss of resources/life/access. Preventing something from happening by using a suitable method of collaboration is the key in most cases. While this answer is rather large and possibly contains duplicate information from other Q&A posts, I hope this describes enough reasons to look for better ways to achieve your goal.


Is it OK to use a part of an e-mail as a master password of my password management?

Yes, there are a number of flaws with doing this:

All of the mail admins have access to your mail file and therefore can read this email.
Chances are the mail file is not encrypted at rest, which means potentially sysadmins have access to it.
If DLP tools are run against your mail file they will likely pick this up and store it in their database.
Not sure if you have an offline copy of your mail file on say your hard drive and if you do, those with access to your local drive, would have access to it.

Best option would be to combine multiple passwords that you have memorized for your master password and use that.


Is there a way to find the SSL certificate used for one specific browser-server SSL communication?

Currently there is no way yet for a Chrome extension to get access to SSL fingerprint information. According to this SO thread support for this was recently added to Firefox 62 and there is code yet to be merged in Chrome to allow this.

Once this code is merged into Chrome it would be possible to update the enhanced-history chrome extension to store and display this information.


Can automatic-reply emails be used to find a home address?

For this to be a risk there has to be an appreciable likelihood that someone receiving an out of office e-mail from the user has the motivation and skills to want to rob their house.

Also it discounts the possibilty that someone else (e.g. a pet sitter) might be present in the house whilst the owner is away (i.e. the out of office alone doesn't provide certainty that the property will be vacant).

If we have a targeted attacker who wanted to burgle this specific target, they would likely need to take further steps to establish whether the poperty was vacant, in which case the out of office isn't that relevant.

If we have an attacker who just wants to burgle any person and isn't too bothered who, then they're unlikely to go around sending mails, looking for out of office messages and then work out where they live.


Is it possible to create a truly private user account in a public computer?

No it's not!

The closest you can come is your own bootable drive and reboot the computer to run from your drive. In that case it's not a public computer, it's just yours with their hardware.

Even an encrypted VM would not work, as the running decrypted VM image is fully accessible from the underlying host system, albeit with some work.

You can protect individual files and directories via encryption, but that protection is for "dead files". When opened, the keys and accesses are in running memory.

Bottom line is, if you are running someone else's operating system controls, they have access.


Could a router protect our network or need we use an hardware firewall?

Many routers - even in the consumer-segment - have basic network filtering capabilities based on protocol, port and IP, which means that they can also be used as a basic firewall. Dedicated firewall appliances often offer additional features, like deep-packet inspection to detect certain known threats on the protocol-level or automatic attack detection based on heuristics (they can warn you when someone seems to be probing your network for vulnerabilities). Whether you need this or not depends on how secure your network needs to be and how much this security is worth to you.

The manual of that router shows some screenshots of the web interface where a button "Firewall" is visible, even though it is missing any written documentation about that feature. But I own an even cheaper Asus router, and it can do port- and IP-based filtering, so I would assume that this one can too (contact ASUS support when you need to know details).

But keep in mind that consumer-grade routers are rarely sufficiently hardened. The news about critical vulnerabilities in home-routers are numerous. There is a hard price-war on that market, and the support in form of fast security-patches for existing products seems to be one of the first cost-factors to cut down on.

When you use a consumer-grade router, you have to be aware that a skilled hacker which targets you specifically will likely find a vulnerability and use it to compromise it. Doing a risk analysis of this scenario is up to you. You need to estimate how likely it is that a skilled hacker gets interested in your data and how large the damage would be when your data would get stolen.


Using chip and pin credit card for authentication?

First, have a look at [this question].

Based on that question, my understanding of bank cards is that the chip card puts it's own accNumber+PIN into a signed message encrypted for the bank's server (probably with some challenge data from the POS to avoid replay attacks) and asks the Point-of-sale (POS) terminal to send this on its behalf. The POS terminal can't read the message, but can send it off to the bank. The bank validates the message, checks the signature, and compares it to the accNumber+PIN in it's database and returns a YES/NO to the POS terminal. (disclaimer: this is how I imagine it could work, I don't know if this is how it actually does work.)

There are other challenge-question-based approaches commonly used in the security industry (for example, for ID badges to get into your office building). They work as follows: when you hold the card up to the reader on the wall the chip card, the card reader, and the database have the following exchange:

Chip Card to Reader: "I am John Smith and my public key is pub_key."
Reader to Database: "Does pub_key belong to John Smith?"
Database to Reader: "Yes."
Reader to Chip Card: "To prove you have the matching private key, sign this message: rand_32bit_msg."
Chip Card to Reader: enc_msg = encrypt(rand_32bit_msg, priv_key), "Here's enc_msg."
Reader: does decrypt(enc_msg, pub_key) == rand_32bit_msg? "Ok, I believe you own the private key, in you come!"

Presumably you can buy a set of chip cards and readers from various manufacturers, but I have no idea if this is within the budget of a hobby project.


Is there an encryption algorithm that is fully secure?

Yes, it's called One Time Pad, and we don't use it in SSL/TLS because key-exchange is problematic at scale.
I will point out that with the rapid decline in the price of various types of storage, One Time Pad's use for smaller communications such as e-mails is more practical now than it ever has been simply because the cost of giving someone something like a large USB Flash Drive with a large "pad" on it didn't exist in a practical sense a few years ago. Still, as the price approaches zero, this becomes trivial to do. As storage costs continue to approach zero, this could become more useful for a wide variety of uses in the future, but the key-exchange problem will still exist.


Is HMAC required when using TLS communication?

TLS protects the communication between client and server.
It is unclear, what specific attack vector this hash is trying to mitigate since not much is known about the application. But if it tries to only mitigate tampering between data between client and server by some malicious attacker then it is not needed with TLS.

It might though that the hash is trying to mitigate manipulation  by a "friendly" man in the middle, i.e. one which is explicitly trusted to intercept and manipulate the TLS connection by having its CA imported as trusted in the device. In this case it might make sense to make it more complicate to successfully tamper with the traffic by having some application specific secret to protect the data in addition to TLS.


There are 2 ways to achieve your goal.

Safer and easier way:

Use an anti-malware solution that will help you to block the phishing links. Keep the signatures of this anti-malware solution up to date.
Risky and harder method:

Jailbreak your mobile phone, then write a script that collects IP/domain feed from Open Threat intel sources like OTX alienvault, VirusTotal, etc. Then block the connections to this IPs/Domains. You may want to use it in cron to make it dynamic list.


Best Approach for removing XSS Vulnerability

There is a good resource from OWASP: XSS (Cross Site Scripting) Prevention Cheat Sheet

Basically you should validate all input data using white list approach (define valid patterns not invalid patterns as you are trying to do at this moment) AND you should encode all data on output using encoding scheme correct for given context (HTML, JavaScript, HTML attribute).

Correct encoding is quite difficult and you shouldn't be doing it by yourself. Instead you should use library like Microsoft AntiXSS Library or OWASP ESAPI.

You can also use ModSecurity (or other WAF) with correct detection rules (i.e. ModSecurity Core Rule Set), but be aware that this should not be the only solution you use.


How do I make my drive fully protected with bitlocker?

Prevent someone from gaining physical access to your system while it's running.

Seriously, the linked tool works by searching through an image of your system's memory for the key for the encrypted volume and using it to decrypt the encrypted volume.  The only way to prevent this is to make sure an attacker can't read the memory of a running (or suspended or hibernated) system.  There are a number of ways to get this memory image, ranging from connections via FireWire or PCIe to extracting hibernation images from the disk.  Of course, even when the system is off, you're not completely safe, thanks to cold boot attacks.


How can I protect a WordPress installation?

There is actually a really good guide to this on the wordpress website - Hardening WordPress.

However my personal short check list is

mod_security - @atdre already mentioned mod_security it is a very good step. However it does require a lot of tweaking of the core ruleset in order to allow wordpress to operate correctly. You will also most likely need to customise the ruleset depending on the plugins you use.
File Permissions - see here
Administration Over SSL - Use SSL for the Admin area see here.
Update - the most critical in my opinion keep wordpress up-to-date. By using the built tools, by patching manually or by using an update script (I wrote this one).


PoisonTap works on the same level as ARP or DHCP spoofing or a rogue access point. This means that the same restrictions apply (i.e. HTTPS can not be decrypted and thus the plain text not sniffed or modified) and the same possibilities (HTTP can be sniffed and modified).

This also means that enforcing the use of HTTP instead of HTTPS using SSL stripping will work with PoisonTap the same as it does with the other attack vectors, i.e. it works as long the connection does not start as HTTPS but there is an initial HTTP request which can be hijacked and modified to remove any HTTPS and HSTS headers from the response. But there is actually nothing specific to PoisonTap here compared to the other usages of SSL stripping.


Can Passpoint X.509 certificates be used to MITM SSL connections on Passpoint networks?

The certificates in your linked images are commercial certificates, therefore your device trusts those already by virtue of the fact that the commercial root CA certificate is in its trust store.

The certificate you installed is probably a client certificate, which you use to authenticate yourself with the system.

It's my (limited) understanding that Passpoint systems must use pre-defined certificates as dictated to by the WiFi Alliance, and not ask you to install an additional root CA certificate in your trust store.


Is it secure for a company to allow you to display your Wi-Fi password when signed onto their site?

It seems you are talking about factory assigned WIFI router WIFI password.
The default factory WIFI password is meant for the user to connect during initial setup, as well as after hard hardware reset.

You should always change the default WIFI password when you setup the router. After changing the password, the internet reference will be utterly useless unless somebody adjacent to your get the password and able to hard reset your router modem.


On the help page you link to it states to go to https://myaccount.google.com/security/signinoptions/two-step-verification

When I go to that page under "Your second step" there is a section called Backup Codes with a big "Show Codes" button.


How are hardware wallets and other hardware-based security devices audited?

This is exactly the common problem of root trust in computer science.
You must trust someone/something to behave as advertised. It can be reworded "putting an anchor on trust", from which "trust anchors" are a common concept.
Basically you must trust both that Satoshilab, the maker of Trezor, sends the correct firmware to factory, and that the factory is not voluntarily altering the manufactured device (which is a problem for Satoshilab themselves).
There is no definite answer, as you wouldn't just be easily auditing yourself your own Intel/AMD-based computer. As @schroeder commented, you can ask the very same question about basically every single piece of hardware you buy and every single ISO image of binary software you download, open source fully included.
So external audits come into. An increasing number of companies are relying on trusted third parties to audit their code and their design process, and publish those reports without disclosing industrial/trade secrets. In this context, there is no trade secret in open source, but think about WhatsApp...
About Trezor, the best I could find is the CTO's answer on Reddit to the same question

The code is continuously being reviewed and improved by independent (e.g. Saleem Rashid, Sunny) and semi-independent (Jochen Hoenicke and Christian Reitter) security researchers. Even our competitors are looking at our every move and have sent us some reports and ideas for improvements.

Here is a report from security researcher Saleem Rashid about Extracting TREZOR Secrets from SRAM.
It's the company business to verify that neither firmware nor hardware circuits are altered by the factory.


Did changes in Google Chrome 80 weaken cookie and password encryption?

Just going off what you describe: I can see no legitimate reason whatsoever for Chrome to use the Local Machine scope, and I would call that a security vulnerability.

I'm not sure how secure the local machine key is, but at minimum it can be decrypted by any user with authenticated (login) access to the machine. It might be possible even without any log in access if the key is stored in a retrievable way (to an attacker with unrestricted read access but no passwords, such as somebody who stole a hard drive that wasn't using full-volume encryption). By contrast, the user DPAPI master key is wrapped using a key derived from the user's password and through a fairly expensive key derivation function.

I'm also just not really sure why to make this change in general. Yes, AES256-GCM might be a bit more secure than DPAPI's default (AES128-CBC + HMAC-SHA2-512, I think) but for practical purposes adding more crypto implementations isn't a good idea; the security is only as good as the weakest link. DPAPI is slow to initialize due to the expensive key derivation algorithm, but once it's initialized the key gets stored in non-paged memory inside the protected Windows security subsystem; using the key is then fast (it requires a same-machine remote procedure call, and inter-process communication always has some perf cost, but the lrpc system on Windows is highly optimized and the data being passed is small). Additionally, the protections on the key are probably much better than Chrome will put on its "master" key.

I'm sure Google had their reasons, and they might even be good ones for at least part of their audience (maybe they had a problem with the way current-user keys work on domain-joined machines? maybe some people use different Windows accounts but share a Chrome profile somehow, and it needed the encrypted data to be shareable across the accounts for a setup like that?), but for the typical user this looks like a major step backwards for very little gain.


P2P botnets deal with firewalls the same way as all the other P2P applications (like Bittorrent, Skype and other VoIP, ...) do:

Simple NAT firewalls can be passed with UDP hole punching techniques
With more complex firewalls, like application layer gateways which only allow HTTP traffic, it either fails or it uses some outside server as a relay for communications.

Failing in case of more restrictive firewalls is actually not that much of a problem for P2P bots because most users are either not protected by any firewall at all or only by simple and easy to bypass packet filters.


Using jmp may not result in a ROP friendly return of control to your stack. You're better off finding alternate gadgets to achieve your goal.

Also for your proposed solution if your exploit is able to modify the opcodes at 0x8109b3f7 you already have code execution and no need for further ROP.


Linux uses TSC by default for its clock source due to its lower overhead, and only uses HPET as the fallback. The kernel gathers entropy from interrupt timing intervals, using the RDTSC instruction on x86 processors. Unless you do not have TSC support, then I do not believe disabling HPET will influence your entropy collection at all. Only on certain embedded processor architectures such as ARC will you have problems involving the lack of a high-resolution TSC instruction.


Is RSA-SHA1 secure enough for licensing?

SHA-1 is broken. When you use SHA-1 to verify the signature of your license files then an attacker can generate a license file which will pass your verification algorithm in reasonable time. Anything they need to do that (your verification algorithms and any shared secrets) must be a part of your program, otherwise it couldn't do offline verification.

But there are many other hash algorithms you can use as a simple drop-in replacement. When the hash algorithm has no considerable weakness and your license keys have enough entropy (long enough completely random and unique part) it doesn't even need to be a particularly slow algorithm, because brute-force attacks are unfeasible. You could, for example, use one of the algorithms from the SHA-2 or SHA-3 families. Despite the name they don't have much in common with SHA-1, so the vulnerability does not apply to them.

However, your client should rather be worried about a cracker releasing a patch to remove your license checking code from your programs binary altogether. In practice, copy protection is rarely effective against a determined attacker. When it runs completely on the users machine then it can't be 100% effective, because it runs under the users control. It mostly works by making piracy less convenient than buying, not by making it impossible.

Which brings me to another important consideration: The best copy protection is making the product easy to buy. The more hoops you have your user jump through to get and apply a proper license, the more likely that they will look for "alternative methods" to get it to run. The steps mentioned in the article linked in the question (user tells vendor device-id, vendor replies with license file...) sound far harder than googling "JMA's program crack download".


I am a little unclear on what you mean by what sort of xss attack can be done on clean urls so I'm going to go over both types of XSS for your situation.

It really depends on how that URL is being used to render the page.  First lets talk about two different types of XSS.

  Reflected XSS: Part of your URL is rendered on the page and the attack
  payload is part of your URL.  You need to trick users into clicking
  your link to execute the attack.

  Stored XSS: The XSS is stored on the server itself due to insecure
  programming.  Then when a user visits the page with the XSS payload,
  the attack is called up from the server.  The user just needs to visit
  the page, no link clicking required.

So lest look at your example URL:

//my url.net/project/public/#questions/question/edit/id/122/answer/1

When I first look at this I don't see anything that jumps out as being rendered to the page, but for arguments sake lets say you are rendering the last parameter (1).  If you change the URL to this:

//my url.net/project/public/#questions/question/edit/id/122/answer/1<script>alert('xss');</script>

and you tricked a user into clicking that link, it would display xss in an alert box on their page.  This is a reflected XSS attack.

A more likely scenario is that the last parameter (1) is used to pull some info from the database and render that on the page.  If you have not properly protected yourself against XSS it is possible that someone submitted an answer that contained javascript code.  Example:

My answer to question 1<script>alert('xss');</script>

Now anyone who views that answer will see an alert box that says xss.


I would start from the bottom and work my way up to the root.
Your leaf certificates will be valid for 2 months, that means your current intermediate must still be valid for at least 2 months when issuing a new certificate. In other words, you need a new intermediate in place and ready to use every 4 months (given that an intermediate is valid for 6 months).
You could fit 6 intermediates within the lifetime of one root (24/4 = 6). However, you cannot issue leaf certificates for the old root after its lifetime exceeded 22 months (because the leaf would then be valid longer than the root).
In your scenario, I would create a new root every year, distribute it immediately, and start using it after 4 months.
But why is the lifetime of your root certificates so short? The purpose of root certificates is to have a long certificate lifetime (10 to 20 years) and a root is typically kept offline with the private key stored securely in an HSM or a smart card and only brought online to sign a new intermediate or a CRL. There is no need to rotate a root certificate often.
You could then create relatively short lived intermediates and rotate them often if that is your requirement. It is easy to distribute intermediates (they get sent to the client along with the leaf certificate during a TLS hanshake), but burdensome to distribute and deploy a new root (because this has to happen out of band).


How does IIS persist identity credentials? Does it create any security issues?

It doesn't.  This is why the service accounts should only have the minimum level of permissions necessary.  If the application server is compromised, so are the service accounts that it has access to.  I'm pretty sure even an HSM couldn't help any since the system needs to be able to get the password out of whatever storage to submit to network resources.


Is a simple Whirlpool hash with random salt secure enough?

I'm not sure of the advantages of using one of these or why the current one is wrong. Does anybody mind explaining their reasoning?

Bcrypt CAN BE stronger than whirlpool, it depends on your strength setting. This is one of the most important advantages about bcrypt, that you can increase the strength as computers get more powerful, plus it's extremely difficult to crack using a GPU compared to simple SHA/Whirlpool hashes.

Since PHP 5.5, we've had bcrypt available as easy to use functions. To create a hash you would use password_hash($pass), you don't need to worry about salts because one is automatically generated and placed inside of the hash, because of this you need to use password_verify($pass, $hash) to check a hash, as generating a hash will use a different salt every time (and your strength settings could change).

There is almost no reason not to use this for a new application, as it's proven to be much much more secure than standard hashing algorithms. If you're on a version of PHP older than 5.5 there are a variety of libraries available to assist with this, most commonly ircmaxell's password_compat.


End-to-end encryption with a reverse proxy and an application server

What you want is "Upstream SSL".

This is when you re-encrypt the backend connection with Nginx. You don't need to buy another certificate. You can use self-signed certificates for the backend.

Discussed here: StackOverflow: Nginx load balance with upstream SSL
and here: ServerFault: Configure Nginx as reverse proxy with upstream SSL

Blog here: "SSL Offloading, Encryption and Certificates with NGINX (Archived here.)
They insist on calling this "End-to-End" encryption in their blog. (It maddens me that they do that. If you re-encrypt, then you're no longer end-to-end encrypting.)
(But Citrix is guilty of the same terminology sin with their "NetScaler" loadbalancer. (Archived here.))


Does using two layers of encryption reduce security (Veracrypt/Truecrypt)?

Say you memorize a random 16 character password. With 16 characters from a set of 95, there are a total of 9516 possible combinations. Using two layers of encryption each with an 8 character password, each of which has 958 combinations, the maximum number of guesses an attacker would need is not the expected 958 × 958 (9516) but 958 + 958 (959), which is much, much lower. Because of this, one long password would give you a security level of 9516, whereas two half-sized passwords would only give you a security level of 959. The attacker would only need to crack one container at a time.

The only time that using multiple layers would be useful is if you want to use different passwords in order to prevent compromise of the disk encryption password from implying compromise of the container. Because computers naturally need to keep the encryption key in memory, a cold boot attack or other physical attacks may be able to retrieve the key if the computer is powered on. By using a separate container that you close whenever you are not using it, you minimize the amount of time the container's password is present in memory without having to sacrifice full disk encryption.

So, what should you do? Use a single password created with the diceware technique. That involves using physical dice to pick out words from a 7776 (65, the number of possible combinations of five 6-sided dice throws) word dictionary and using the space-delimited words as your password. The amount of entropy present in a diceware password is log2(7776n), where n is the number of words. To have more than 100 bits of password entropy, which is often considered the minimum to be secure for the foreseeable future, you will need to have at least 8 random diceware words. Any less than 6 words and you start getting into dangerously weak territory where cracking becomes possible.


How can I find websites owned by a particular company?

I find BGP Toolkit from Hurricane Electrics Internet Services quite useful for providing insight into any CIDR range, registrants, Who-Is info, IP and DNS info, IRR, assigned IPv4 and IPv6 CIDR ranges for individual ASNs, you name it. All data presented is also nicely linked to each-other for our convenience.

For example, searching by term PayPal will result in this table:

AS17012            PayPal, Inc.
64.4.248.0/22      PayPal, Inc.
64.4.246.0/24      PayPal, Inc.
64.4.244.0/22      PayPal, Inc.
64.4.240.0/22      PayPal, Inc.
216.136.236.0/22   PayPal, Inc.
173.0.94.0/23      PayPal, Inc.
173.0.88.0/22      PayPal, Inc.
173.0.84.0/22      PayPal, Inc.
173.0.80.0/22      PayPal, Inc.
173.0.80.0/20      PayPal, Inc.

which gives you a single ASN and a few assigned CIDR ranges that are registered to PayPal, Inc. These items in the list link to their individual info pages. Following the AS17012, for example, displays all kinds of information pertaining to this ASN, among others the list of Prefixes (in our case IPv4 CIDR ranges).

What is HE?

HE is one of the largest Internet backbone providers and can thus collate loads of infrastructure related information like the ones mentioned. You can search their database by registrant names, CIDR ranges, ASNs, IP addresses, and so on, all through the same input box and it will display either a list of possible matches, ordered by relevance and network range, or display a single match details when only one record is found. They also include a lot of various network related reports and statistics.

This is from their About page:

  Hurricane Electric operates its own global IPv4 and IPv6 network and
  is considered the largest IPv6 backbone in the world as measured by
  number of networks connected... (and so on)

Also interesting (and relevant) to read is the page about their network. It gives a bit of insight into how they can collect all the data available through their search.

Of course, I'm not saying that HE is the only place to go. There are lots of other tools available, some paid and some more or less free to use and query. HE's one is however one I most frequently rely upon and I thought you might find it useful as well.

What do I use this information for:

I mostly use this information to compile blacklists and other network filters for my services. I find it especially useful to track down hosting companies and their CIDR ranges to include in content-theft, malware, spyware, and related policy blocks (in essence bad neighborhoods) when blocking by reverse DNS look-ups (and/or matching rDNS results with forward DNS look-up tables) wouldn't cut it.

Usage example:

To answer your example directly, collating information from HE gives us this list of A record domains operated by PayPal, Inc:

64.4.248.105    icppharm.com
173.0.84.191    paypal.fi, paypal.de, paypal.pt
173.0.88.180    paypal.mobi
173.0.89.113    www.paypal.de
173.0.89.161    www.paypal.com.pt
173.0.82.143    www.paypal-labs.com
173.0.82.144    www.paypallabs.com
173.0.82.145    www.thepaypalblog.com
173.0.82.156    paypal.me
173.0.82.157    paypal-portal.com

(limited to include only A records otherwise the list would stretch several pages long. This page alone, from one of several CIDR records, lists hundreds of domains.)

All relevant DNS records for our example can be found on pages 64.4.248.0/22, 173.0.94.0/23, 173.0.88.0/22, 173.0.84.0/22, 173.0.80.0/22, and 173.0.80.0/22

Some pages duplicate information from others as they're providing information on a sub-range of a larger range (smaller mask), like for example an IP range 173.0.80.0/22 would already be included in a 173.0.80.0/20 IP range.

What sites have 'paypal' in it's web address?

I'm going to make an attempt on answering this part of your question, however (as you probably can imagine) my answer can't be as straight-forward, because there isn't a single list of all registered domain names available to public, at least not that I'm aware of. Here's what I'd do:

The www.who.is website provides a bit difficult to navigate or search through domains index. Where do they collate all this information from is beyond my knowledge, I can only suspect they query individual registrars' databases on a regular basis.

Anyway, if you navigate their pages a bit you'll soon discover that the lists are organized in alphabetical order and then by page numbers (static URLs to individual pages). I guess you (or a CP savvy friend) could write a small utility crawler that would parse all this information into a single table and then do your search on it. If that's agreeable to the website operators and within their TOS isn't something I've researched. Honestly, probably not and your crawler could be banned sooner than it would be able to crawl all relevant pages. You would still end up having larger data set than any publicly available ones (that I know of) and that can be easily searched through by a common expression.

If you did this, you would soon discover tens of thousands (educated guess) of registered domain names that include 'paypal' keyword in it. Most, I gather, are actually parked domains, expired domains, and the most awful of the bunch - phishing locations trying to lure unsuspecting Internet users to their addresses by mimicking official PayPal domain names. For example, take a look at this page and search for 'paypal' in it. 1883 matches in a single page, and only God knows how many pages are actually relevant to our search without resorting to crawling and collating data of each individual index page. They can't possibly be all registered by PayPal, Inc.!

I hope that at least partially answers also your 'other' question.

Cheers!


Mac address spoofing in Kali resets back MAC addr. after connecting to WLAN

This is a known issue with Kali. Older versions from before the rolling releases don't seem to have this problem when running on real hardware (non-VM).


Which is more secure against packet injection?

In short, this looks like this:

WiFi without password is totally insecure. You can use VPN (not proxy) but then it's hard to use VPN on all devices.
WPA2-PSK (Personal) is OK except Evil Twin Attack as long as you have something like 14 character, random password with upper, lower-case characters and numbers. Some go with 12 character length if the password is truly random.
WPA2-EAP (Enterprise) if usually most secure and resilient to Evil Twin Attack. There's some security risk in EAP protocols and software stacks on your systems involved in it, however this is much harder to do and it can be patched once the flaw is found so it's not broken by design.
WPA2-PSK/Enterprise is not really something really common. It may be it's some sort of misinformation because this standard haven't been adopted.
Captive portals can be used with any of the above variants. It's more suitable for the Hotels for example

For the convenience, security and compability you could go with WPA2-EAP/PAP which is using login and password, so you can enter these on every device.
Captive portal is not also very secure because someone can do MITM on it even with fake SSL cert. It's good for customers who can logon with their Facebook account for example. With WPA2-EAP/PAP you'd get login and password so then you just enter it on Smartphone, Laptop etc.

You can use VPN on any kind of WiFi network. If you plan connecting multiple devices you could setup dedicated router which would handle the VPN for all devices but this would be quite complicated and hard to get it working in stable fashion on the start. I think if you can get WPA2-EAP or good PSK key then you'd be just fine without VPN, however if you do not trust your provider you can get one as well, starting from your laptop for example, using it on the mobiles is quite an over-kill.


This question leads me to believe that you're slightly confused about how data is stored on the drives itself, so I'll start by touching upon that first.

Filesystem type: ext3, NTFS etc. are nothing but types of file systems. The type of filesystem used (in most cases) has zero impact on your ability to securely wipe the drive since in any secure wipe, it'll be nuked.

As you probably know, just hitting the delete key doesn't really wipe the space on the disk clean. It simply marks the area of the disk as 'empty' and allows new data to be written to the area. Think of it as cubicles:

|  Joe  |  James  |       | Amy |

You can see the empty cubicle between James and Amy. That is untouched space. Now let's say that James is fired. So he clears out his cubicle and leaves - but the space he used is just empty - and not untouched. This is an important distinction:

|  Joe  |  *empty*  |       | Amy |

Why? That's because when a new employee joins (drawing parallels between new data being written to the disk here), the new employee can be given either a fresh cabin (to the left of Amy) or a used, but empty cabin (James' old room).

This leads to a important observation - although there's no one in James' old cubicle at the present, there's a chance that the new employee might find something that James' left behind - similar to what a data forensics program looks for.

Now we come to the next part of the question:

  How to securely erase/delete files or folders in different file systems (NTFS, ext3, ext4)?

Since we've figured out that the filesystem type is irrelevant, the only real consideration here is how. Data destruction programs that seek to wipe the entire hard drive work on the principle that - if all the hard drive space looks the same, it would be very, very hard to identify what was present on it earlier. Data on HDDs is stored as 1s and 0s. So some types of wiping programs, go over the entire disk with 0s, writing 0s to every sector. This is commonly called zero'ing out a drive. Here's how it might look before zero'ing:

|10101100|00110000|11001010|10101010|

And after:

|00000000|00000000|00000000|00000000|

At this stage, unless you've really got yourself into a real mess, most people might just give up. If you're being chased by a three-letter agency on the other hand might bring out their electron microscopes to figure out how the bits were aligned before you overwrote them with zeros.

So a new wiping methodology was introduced.

It involved zero;ing, writing random data and then zero'ing again, repeated several times. Each iteration was called a pass. There were several techniques that used different passes to render data unrecoverable, but I'd say that for any sort of sale to a citizen, more than 7 passes would be overkill (and probably would ruin the disk's life anyway)

As John says in his answer here:

  The only NIST approved method to securely erase a hard drive is by utilizing the secure erase internal command - documented at the Center for Magnetic Recording Research (CMRR) - and that is what everyone should be doing. It is an ATA command, and covers (S)ATA interfaces.

After that, you can optionally degauss the drive to erase the firmware itself.

SSDs:

SSD erasure is trickier because of how the data is stored on flash chips instead of magnetic disks. This answer answers the best ways to erase an SSD securely:

  ATA Security Erase

The only way to securely erase an SSD is to use the ATA Security Erase feature, present on all ATA6-compliant drives (i.e. virtually all modern ones). Attempting to overwrite data on an SSD will not actually remove everything due to overprovisioning space mentioned above. Unfortunately, because of this overprovisioning space, you cannot actually read everything which is present on the drive, as this space is always hidden, so you cannot verify if you have overwritten everything.

ATA Security Erase is designed to solve this problem by doing a low-level overwrite of every single sector. On some newer SSDs, an additional feature calld ATA Enhanced Security Erase can be used to destroy a master key which the drive uses to transparently encrypt and decrypt your data. Destroying the key is instantaneous, but renders all the encrypted content inaccessible.

And the commands on *nix:

# it must say "not locked", "not frozen", and "supported: enhanced erase"
hdparm -I /dev/sda | grep -A8 "^Security:"

# overwrite the drive with a repeating pattern to check for after
yes "You should not see me" > /dev/sda

# begin the erasure, without using a password
hdparm --security-set-pass NULL /dev/sda
hdparm --security-erase-enhanced NULL /dev/sda

# check if the repeating pattern is anywhere to be found
strings /dev/sda | grep "You should not see me"

I hope this helps!


KRACK is on the Network layer of the OSI model, while TLS is on the Session layer. So no, they do not influence each other, provided that the client can not be tricked into using a non-TLS connection (SSLstrip).

The basic threat from KRACK is that it allows an attacker to decrypt all packages on the network layer that the victim sends / receives. This includes all cleartext communication (e.g. that which many email programs still employ, local network device connections, etc.).

This means that if you display the network key and an attack is seeing all your traffic they can simply make a full connection to your network and wreak havoc on it any way they see fit.

If there are other vulnerabilities in the implementation (e.g., what happens in Android 6), then the attacker can even manipulate packages in transit to the victim. (both encrypted and cleartext can be manipulated). However the attacker can not read its contents if the packets themselves are encrypted by a session layer protocol (e.g. TLS). This opens up the possibility to change key values or redirect the victim to an attackers site for infection.

So while it is a serious breach and must be solved as soon as possible, it should not compromise properly secured traffic. So use a VPN, HSTS, HPKP and ssh, to protect yourself and/or your users.


Is it possible to detect if a trojan or program sends information by sniffing the network of a VM

Yes, traffic analysis is commonly used when evaluating programs, and their interaction with their environment.

There are a few caveats to consider

Encrypted traffic (TLS/SSL) - Unless you install a root certificate on the VM and actively perform a man in the middle attack to replace the certificate sent by the remote host, you won't be able to inspect encrypted traffic.  This may be detectable by the program if it's using certificate pinning, it may even prevent the program from running properly if pinning is strictly enforced.  If bidirectional certificates are used, then the server will also be aware of this.
Many programs and malware are able to detect that they are being run in a virtual environment due to the hardware emulation.  Things as simple as the MAC address being for a virtual vendor, or as complicated as specific quirks of the emulated hardware (CPU, memory, etc).  A program may alter it's behavior to not act maliciously in this scenario.  That can also be used to your advantage though, as some setups actively attempt to make their systems appear as a vitual machine in the hopes malware will not execute.


Realistically, how much added security does having a passphrase on a ssh key have?

For starters, yes, key bruteforce is unrealistic under normal circumstances. Any properly configured server will not allow you to make billions of guesses at the SSH key. If it does, there are some major problems with the security protocols of the server. All sorts of red lights should be going off from the logs of a production server if there are that many key failures against a single account.

http://blog.codinghorror.com/brute-force-key-attacks-are-for-dummies/
https://askubuntu.com/questions/2271/how-to-harden-an-ssh-server

For nearly all intents and purposes, it is in practice impossible.

Keep in mind that if someone has gained access to a client file system, you are already is very bad shape. However, that does not mean all further security should be abandoned.

For example, in the case of a remote exploit it is very common to gain shell access to a system without gaining full rights. For instance, a remote exploit of the Apache web server will land with a shell... as the server itself (whoami = apache), which isn't always as privileged as you might have hoped.

So in the case of a compromised client machine, you want to make sure that before compromise that machine has every sort of security protection it can to make post compromise life hellish.

There are many ways to compromise a client machine, so it isn't really possible for me to outline all the possible scenarios here but:

Make sure to do everything you can to lock down the machine from physical access. Good hardware management, full disk encryption, good passwords.
Ensure that once the attacker is on the machine the password to everything is neigh impossible to guess
Use a program to generate large, securely generated passwords. Store the passwords in a keystore that is locked when the user is away, and has a very large passphrase itself.
Enforce a policy that your users always full-disk-encrypt their laptops while on the move. This way a stolen laptop is useless to an attacker.
Use client side log auditing software (like ossec) to raise alarms when fishy activity happens on a client machine.
Configure a lockout on SSH key guesses. This will only slow an attacker down, but with a sufficiently good password it is almost a game over for the attack.


Can a website be used for targeted attacks?

Your misunderstanding is here:

  is it possible for the people running the website to hack into the
  computer of specific user secretly?

As a general rule of thumb, you can't just "hack" into a specific person's computer from a website.  In fact, browsers are typically one of the more difficult channels through which to attack a user's computer.  Doing so requires a zero-day vulnerability in the browser that the user is using.  Such vulnerabilities do exist but are rare and quickly patched.  Targeting someone in particular also means targeting their particular browser, and if they are using a browser without a known zero-day vulnerability then it is quite literally impossible.

This can be made slightly easier though if you find a zero-day in a common library or browser plugin.  This was a common way of attacking browsers back in the days when Adobe Flash was more common, but like browsers themselves, this is becoming harder to do - Flash in particular is on its way out due to its long history of security vulnerabilities.

If the US government wanted to hack a particular person they have much better and more direct ways to doing it rather than convincing a third party (e.g. Youtube, Twitter) to do it on the government's behalf.  Especially if the government wanted to keep it a secret.  The best way to keep something a secret is by involving as few people as possible, so getting a third-party to do the work for you is usually a bad idea anyway.  Finally though you have a coherent question at the end which is answerable:

  What precautions do they take?

If you are worried about someone trying to hack you through your browser then you should take the same precautions that everyone is told to take: use a modern browser and keep it up-to-date.  This simple protection will keep you safe against 99% of the threats out there, most likely including any government attempts to hack you through your browser.


I am assuming you are aware that this is text-book RSA and you are not planning on implementing this for security purposes. In case this is not clear, let me just remind you that you should not roll your own crypto for anything security related.

Now with that aside, I will try my best to answer your questions. Please excuse the use of images for formulas. Unfortunately, this website does not have LaTeX support.

  How do I chose the value of "e" after computing all GCD values?

I will rename your variables as follows: p = 61, q = 53, n = p * q = 3233, and phi(n) = (q - 1) * (p - 1) = 3120, where phi() is Euler's totient function, denoted as φ(n) in my LaTeX snippets. With these variables you can pick a value for e as follows:

That being said, as @Sjoerd pointed out, the values 3 and 65537 are commonly used for e. [1]

  How do I calculate the private key knowing the value of N and "e"?

To compute the private key d, use the following congruence equation and solve for d:

To make things easier, you should use the modular multiplicative inverse of e.


It's not very common, but I've seen this occur before.

From a theoretical networking viewpoint, you can think of these addresses just as any other IP address range. So, if I were attempting to hunt down the source of this traffic, I'd start by asking "how did this traffic get to my router?".

One suggestion: look for an ARP table within the router. For example, in JunOS you would use:

show arp no-resolve

This could provide you with the MAC address for the device. From the MAC address, you can lookup the device manufacturer, which can provide more insight into which device has the IP address. Either way, note the MAC address.

Some key questions:

Is there another router connected to the physical interface of your router?
If yes, does that router have any interface addresses within the 169.254.0.0/16 subnet (unlikely, and this would be strange)? If so, repeat the previous step for this router.
If no, then it's a matter of hunting the device from that physical interface.

Some hints to hunt down the device connected to the physical interface:

If it's a direct physical connection to that router then the hunt is over!
Are there any switches connected to that physical interface? If so, look up the MAC address table in the switch and try and find the corresponding interface that matches the MAC you found in the previous step.

There's no silver bullet for tracking down the device, but repeating the steps above should help. I'd bet it's a random Windows device connected to a switch somewhere.


Applying a transform on passwords before hashing them makes no direct harm to security as long as it is injective: two distinct passwords before apply the transform shall still be distinct once both are transformed. Your "character shifting" is fine for that if you do it properly (i.e. beware of transforming a byte of value 255 into a byte of value 0 which will "truncate" the password).

Indirectly, there is a bit of harm in that your extra transform is extra code, thus extra complexity, and complexity is always bad for security. Moreover, if the transform is computationally expensive, then it comes at odds with the iteration count used in PBKDF2/bcrypt (i.e. you have less CPU available, so you must use a lower iteration count).

A transform like the one you envision makes any good to the security only insofar as the attacker is not aware of it, i.e. the attacker did not do his homework. Basic, low-power attackers who just got lucky with a SQL injection attack may indeed lack the knowledge, but these attackers are not the scary ones. Your extra transform will not deter strong attackers, and that's strong attackers you should worry about.

Transforms applied after hashing have no influence whatsoever on security, except if you are using something like extra hashing, in which case you are just trying to build a custom hash function, which, as usual, is a bad idea. So don't do it. The proper way to use your CPU is not to waste it on voodoo character shifts and other rituals; instead, use your CPU to have a bcrypt/PBKDF2 iteration count as high as is tolerable for your overall application performance.


IPS fail close vs IPS fail open, what are the risks and benefits?

The way to look at which is better for you is to work out what your risk appetite is.

If you must have service at all costs then you don't want to fail closed, as any problem with that IPS will cause a Denial of Service. That is a very rare scenario though - the majority of implementations are configured to protect the server and the data on it.

This is where defence in depth comes into its own. You filter some traffic (eg everything but ports 80/443) using a hardware device - this gives you speed and the ability to remove the vast majority of the traffic that may impact you.

Then use a firewall to limit connections to only those you need. If it can do stateful inspection, this can be used to limit the types traffic.

Then you harden your web server, and locate it in a DMZ which is segregated from your internal network and databases by further firewalls or access controls on routers.

etc etc etc

Layering gives you the ability to cope with the failure of one component, so in your case, if your IPS fails you can make a call based on how secure your other layers are as to whether you fail open and cope with a reduced level of protection until fix, or fail closed and suffer an outage.


My WP site just got hacked for the third time even after following WP hardening guidelines

(Emphasis added).

I would suggest that you Nuke It From Orbit.

This would entail completely wiping the infected systems and reinstalling everything from scratch.

As the quote goes: "...It's the only way to be sure."


By definition, that is a NIDS. That may or may not be enough for your project.

What is possibly more important for a real world NIDS is how it is updated, how is is tuned, how it is managed, how it reports on exceptions or alerts etc. Any of the following would be useful in a NIDS.

Updates - using Snort signatures is useful. Is there any heuristic/learning capability
Tuning - how do you train the system, and keep it updated when network topography or usage changes?
Management - is this standalone or part of an array?
Reporting - do you alert on thresholds, likelihoods, or just on a signature match
Logging - what do you log, and where? Syslog server functionality?


what role do hashes play in encrypted containers?

The hash is a part of a container with encrypted data because of the two main purposes:

integrity check - rather hashing the encryption key then encrypted container is hashed to receive a digest. Then other side of a communication channel would hash received encrypted data and verify whether hashes match. If they do match - data is untampered during the transmission and decryption process starts.
authentity check - what if the container was intercepted during the transmission and both encrypted data and hash was substituted? To make sure this never happens some kind of key-derived hashing like hmac is used. Then without knowing the key attacker has no way to tamper data so the other party would not detect it. The hmac key is obviously should be shared between parties separately prior the actual transmission of an encrypted data.

As of the encryption key - in AES scenario the key should be already known to both parties prior the transmission of an encrypted data. Usually it's shared using some assymetric cryptography like RSA.

Google SSL or TLS to read more about how both symmetric and assymetric crypto play their role in such a way of communication.


Attaching the same file to two separate email, does it compromise security of the "message"

Update: I retract that. PGP uses symmetric encryption for the payload. So the real reason that both messages are different, is that each e-mail is encrypted using a different symmetric key (session key), which is in turn asymmetrically encrypted.

Without having checked that, I think it is safe to assume that GnuPG uses padding with RSA (OAEP probably). This padding will make sure that the two identical files are not encrypted identical in both messages. You should see that when comparing the ciphertexts.

Also see this particular question on OAEP and RSA for more clarification.


Storing OAuth and other authentication tokens

If at all possible, don't store OAuth tokens! Storing OAuth tokens makes your users susceptible to an attack vector they aren't aware of.

If you must store OAuth tokens then AES encrypt them with the best key you can use for this purpose. If users use a password to enter your site then generate an AES key based on the clear text password of each user (e.g. using PBKDF2) and encrypt the OAuth token of each user with their AES key.

Use a site key only as the last resort if no other options exist and do your best to secure the site key as per @tylerl's answer to Where to store a key for encryption?. But as @tylerl wrote, "there isn't a good answer".

So, again, if at all possible, don't store OAuth tokens!


mifare desfire ev1 security with wiegand and rs485

Normally you use key diversification. That means you start with a masterkey M and then you have some key derivation function KDF which maps the masterkey and the card id ID to a card specific key C(ID) for each card.

C(ID) = KDF(M, ID)

This process is used when creating the keys on the cards and in the reader every time a card is trying to authenticate.


It the absence of Signalling firewall(SS7,Diameter and GTP) in the receiving network, if an attacker uses a software that has the capability to send SS7 Map messages. The attacker can send Map messages that are expected from SMSC of external network towards the receiving network.
The attackers can send MAP messages with spoof CgPA such as ATI to get the subscribers locations, since there is not firewall, the Core CS network is not smart enought to detects these attrocities, unless you have a very smart telecom engineers that is monitoring the traffic 24/7 and are actively blocking traffic from operators that does not have certain traffic aggrement with them.


Why must all classes' data members be set to private?

Actually putting a class member on public or private has nothing to do with security. This answer on stackoverflow covers it quite well:

What are public, private and protected in object oriented programming?

Also note that there are languages like Python where there is just a convention to start private methods with an underscore. However every programmer can still access this method from another class. This Stackoverflow question covers this pretty well: Why are Python's 'private' methods not actually private?


Using Gmail in China triggered lots of Two Factor SMS

It is very likely that the SMS alerts were simply caused by heuristic algorithms on Google's end detecting a login attempt from a new location where past failed login attempts have occurred on a frequent basis. Why was 14 text messages sent? I don't know. Probably a bug on Google's end.

I wouldn't worry but contact Google if you want to clarify the situation.


How to verify new accounts against a known persons database?

This is what I'm hearing you say: You have a medical facility with computerized records for the full set of patients.  You want to allow web users to try and set up accounts with a one-to-one mapping between actual patient and their own records.  Your goal is to allow this to be done online without resorting to out-of-band methods such as snail mailing account information or requiring an office visit.

There's two questions here:

Can you one-to-one match a user against their patient record based on what they know?
Can you trust verification based purely on what they know?

The answer to both tends to be "not really."  Because patients may use different names or variations (I've got paper trails as both 'Greg' and 'Gregory'), there may be name mismatches.  Adding in things like birthdate helps, but is still not collision-proof.  And you probably have multiple patients with the same name - I've worked with so many Jennifer Chens over the years it isn't funny.

...which is why your set of patient records all have some form of unique patient ID, hopefully unique to your facility or umbrella medical group.  If the user knows that, they can just type that in.  But in many cases they won't know it or have it handy.  At best, it may show up on paperwork they receive in the mail... but that goes back to what you wanted to avoid.

Finally, nothing a user knows can be trusted to be private.  I'm not legally allowed access to my wife's medical data, but I know everything you could possibly ask to identify her.  And in this day and age it isn't impossible to find out that level of detail about strangers.

I think you'll find that the standard in this area is to send snail mail out with an initial password.  I've signed up for some medical (insurance) related sites where that was how it worked.  The snail mail to the address of record is treated as a trusted second form of authentication, although of course, it isn't really.  As you pointed out, it's easy enough for a family member or even stranger to intercept that mail.

Given that you're talking about medical records, you need to be careful to avoid the more culpable forms of improper access ("I know John's birthday, so I can get into his medical records").  That may mean resorting to snail mail, which reduces culpability if not exposure.


Why are scripts injected through innerHTML not executed whilst onerror and other on attributes on elements are? - Google XSS Challenge 2

The answer to that depends on the way the browser executes scripts present in different places within a page. For example:

JavaScript within the inline script tags is processed synchronously with the other markups in the webpage. These script tags might slow down the processing of a web page.
Script tags which are assigned to the elements after the DOM loads (as in the case of challenge 2) are actually never executed in most cases (see Exception at the end of the answer)!
JavaScript inside an event handler as an attribute is executed as soon as a particular event occurs (reason why inputs like <img src="/" onerror = "alert(1);" and  will work in this case).

EXCEPTION:

Script tags with a defer attribute will not be executed (on some browsers) until the DOM has been fully rendered. For instance, I tried the same challenge on IE and I was able to alert a popup using the following user input:


How does an ISP combat Bandwidth Exhaustion / Volume DDoS?

The answer to your question varies wildly based on ISP. Some ISPs are very capable of handling DDoS attacks upstream, while others do absolutely nothing to stop them. Basically, there are three different ways that an ISP can handle them:

Buy extra bandwidth and let any attacks through. The simplest and
worst solution.
Have simple monitoring systems to detect attacks, and blackhole any
traffic headed to the destination IP. This protects the network as a
whole but still causes the customer to suffer a DoS.
Some form of "scrubbing". This is a process, usually third
party, of detecting attacks and beginning packet inspection to try
and filter out illegitimate traffic. A vast variety of methods are
used, from filtering out traffic from foreign countries to detecting
amplification attacks (such as DNS Amplification, as described
within this US-CERT article). This is the preferred method that most
large providers are switching to, since it allows the customer to
stay online.

Of course, no matter what the ISP does they can still only filter traffic on their own network boundary. As is the case in the largest DDoS attacks, the bandwidth going to the ISP itself can be overwhelmed. There is little anyone can do in this situation.

Unfortunately, there is not much that the database users can do on their end. As you say, in a bandwidth exhaustion attack it doesn't matter if the database owner can filter traffic if they can't receive any traffic at all.

As much as we would like for ISPs to cooperate to stop these attacks, many come from foreign countries and from so called "bulletproof hosting" providers that ignore any complaints of misuse.

Legal action can almost never be pursued. Attackers are very good at hiding themselves behind botnets, and it can be very difficult to find even if someone bothers investigating. If they are found, they are often in foreign countries that do not have laws governing these attacks. The ones in more modern countries hide in legally gray areas, by doing things like offering "stresser" services to "test" your website against attacks without bothering to check if you really own the website.

Fiber optic connections do not decrease the attack in any significant way in the same way they do not decrease legitimate traffic.


Alternative to anti-CSRF tokens for AJAX request (Same Origin Policy)

Yes, you can use a custom header such as X-Requested-With to protect AJAX requests from CSRF.

A customer header is not allowed cross-domain without CORS being enabled on your server. The Origin header could also be used, however the logic for this is not straightforward.

If you wanted to add extra security to the custom header in the spirit of defence in depth, you could add a token to the header. However, as you are saying this is the tedium you want to avoid, checking a custom header would be enough bar any future vulnerabilities in browser plugins like Flash or Silverlight that enable this header to be set.