What happens if a page with an invalid SSL cert responds with a 302 redirect to a page with a valid cert? Do you still get the warning?

Alice will see a warning. This is because the certificate is checked at the point where the SSL negotiation happens, which is before you get the contents of the page - whether those contents are an HTML page or a status code with a redirect.

For an example of why this is important, imagine this scenario:

Evul manages (e.g. by DNS cache poisoning or some other technique) to get you to go to his server instead of the real https://example.com. Evul does not have a correct cert for https://example.com, but he wants to redirect you to a page for which he does have a valid certificate, for instance his very own site https://www.evulkrakker.com, knowing that once you're redirected there you'll see that it has a valid certificate.

If there were no warning at the first site, you'd never know that you were redirected to his evil site.


Do I need to expire a session cookie when sessions are handled server-side?

Telling the browser to expire the cookie is just a form convenience, because the user is always able to override that. After all, the cookie is really on his browser, so you'll always check the expiry of the session on the server side.

That said, I'd still recommend setting an expiry date on cookies. It's a piece of information there in the user's browser, and when it's not needed anymore it's not a bad idea to tell the browser to get rid of it.


How does XAdES-X-L compare to RFC4998 Evidence Record Syntax

The difference between Evidence Records and XAdES signatures is that, well, the first consist in evidence records (ensures data integrity) and the second in signatures (ensures data integrity AND authenticity).

The various XAdES formats enable persons and legal entities to sign data. In an increasing number of countries, this has the same legal value as signing a paper document, however with stronger security (forging a digital signature is theoretically impossible if you use proven, secure digest and encryption algorithms).

There are however some issues that can arise with such signatures: algorithms become weaker and revocation information for signing certificates may become unavailable (once a certificate has expired, the CA is not required to keep its related revocation information). As a result, archiving digital signatures for long periods may become impractical... unless you keep, along with the signature, all its related revocation information while also ensuring that it cannot be forged should the algorithms (that were used at its creation time) become weaker/broken.

And that's exactly what the XAdES archive/long-term formats bring: they add revocation information to the signature and then issue a new timestamp (with a stronger algorithm this time) over this updated signature. This new timestamp hence covers the original signature value, along with the added revocation information.
By issuing such archive timestamps each time an algorithm becomes weaker and/or when a signing certificate expires, you can virtually archive the original signature forever.

Evidence Records, on the other hand, are "just" evidences to which a timestamp (cfr. RFC3161) has been applied. This can be used to prove that some piece of data actually existed at a given point in time, but it misses the legal purpose of a signature (i.e. someone marked his/her agreement to something specified in a given document).

So, to sum it up: XAdES-A must be used when you need to store the archiving stuff within the signature. Otherwise, ERs can do the same job...


Encryption - how to secure files - decrypting exposes them on SSD

There are several strategies:

You can set up a ramfs/ramdisk for temporary area to decrypt your data. When using this strategy, you'll need to research carefully that any programs you use to decrypt/encrypt and edit your files don't make any temporary files outside of your ramdisk area.
You can set up a full system encryption. With this scenario, any persistent storage attached to this machine are encrypted, so you'll never leave any trace of unencrypted data. This is a lot easier to manage than ramfs/ramdisk, but requires significant initial setup.
Use a Live CD. Most LiveCD set up are configured so any writes you do to the files are done on an overlay ram-based filesystem. When using this strategy, take some extra precautions and mount all other persistent storages as read only.


How will Apple and Google provide 5-minute data on Covid exposures using 10-minute interval numbers in the hash?

While the actual SDK code is not available, we can make an educated guess that the ENIntervalNumber is NOT used to calculate the duration of contact.
Let's step back a minute from the crypto to describe what's actually happening on a person's phone. This is documented here, but to give a quick summary:

Alice who has enabled the app is scanning for bluetooth broadcasts sampling every 5 mins.

The scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 minutes.

Bob who has also enabled the app is broadcasting over bluetooth with data containing their Rolling Proximity Identifier (RPI).

Alice's phone detects Bob's broadcast and saves the RPI and metadata. This data is timestamped.

Scan results shall be timestamped and RSSI-captured per broadcast.

Later when Bob is diagnosed a set of his Temporary Key and ENInterval numbers are send to the diagnosis server that pushes this information to all clients.

Alice's phone receives this information and calculates the RPIs and matches against those stored on her phone. Locally the distance and duration of contact are calculated.

Given that we've got the timestamp and the RPI from step3 it's likely that the calculation of duration is done by simply comparing the timestamps. This will also ensure that the distance and duration data is not revealed to the server or other clients.


How to disclose a security vulnerability in an ethical fashion?

You should let the developer(s) know privately so that they have a chance to fix it. After that, if and when you go public with the vulnerability, you should allow the developer enough time to fix the problem and whoever is exposed to it enough time to upgrade their systems. Personally, I would allow the developer to make the announcement in a security bulletin in most cases rather than announcing it myself. At the very least, I would wait for confirmation that the vulnerability has been fixed. If you have time and have access to the source code, you could also provide a patch.


Javascript http to https redirect - how vulnerable/how secure?

Doing this in the browser with JavaScript is insecure and inefficient.

As you have already mentioned, if the User Agent doesn't execute JavaScript then the user is just going to be sat on your 403 Forbidden page. If you're going to return a 403 response to a user, why not just return a 301 and make some use of the response? This is a bad user experience at best and will result in people continually hitting your http URL to be redirected instead of the https one.

From a security standpoint you're opening the user up to attacks from a MiTM. If the user types in site.com without specifying a protocol, the browser will default to HTTP and make a request to http://site.com for them. If the redirect is done in JavaScript the browser will not remember. If the server responds with a 301 permanent redirect to https://site.com then the browser will cache this response. The next time the user types in site.com the browser will visit https://site.com instead of http://site.com as before. This helps mitigate various forms of SSL stripping attacks but isn't a perfect solution. Still though, it is slightly more secure.

What you could also do is issue a HSTS policy for your domain. I've gone in to some detail on what HSTS is on my blog titled "HSTS - The Missing Link In Transport Layer Security". Simply put, HSTS allows you to tell a browser to always use https with no requirement for a redirect. You still need to keep the redirects for non-compliant user agents but it's another step in the right direction.


No, there is no central authority that certifies such things.  But if you're curious you can examine all of the Internet traffic and see if any goes someplace you don't expect.

By the way, even with open source it isn't as easy as just reviewing the source code.  You have to build the operating system yourself, somehow verify the toolchain used to build the operating system hasn't been compromised in order to insert privacy bypasses (no easy feat) and even then there could be subtle things included in the source code in order to defeat source code analysis that could route traffic in non-obvious ways.


How does this site decrypt SHA256 hashes?

You are correct, the hash functions SHA256, SHA384 and SHA512 are (currently) unbroken, so it is not possible to easily reverse them. MD5 and SHA1 are considered broken because researchers have found pairs of strings that produce the same hash value, but even these require weeks or months of computation.

(note: I don't like that the site uses "decrypt" because that's a word you use for encryption; you can't "decrypt" a hash)

What they are probably doing is a dictionary attack in which they have pre-computed the hashes for all common dictionary words. This would give them a lookup table which would take in a hash and return the word that produces it.

Just to give an idea of scale, there are 171,476 English words and a SHA256 hash takes 32 bytes, so storing the SHA256 hashes of all English words would only take about 5 mb.


Secure individual passwords in password manager with U2F?

U2F can't be used to encrypt anything.
U2F devices can be asked only two things :

Enroll a new identity (Create a new key pair)
Authenticate using an existing Identity. (Sign the hashed server challenge with few other info)

So I don't think your question makes sens, but perhaps you can give more details.


Outlook service is storing decrypted password in server memory – how insecure is it?

I believe it is fairly standard to keep secrets in memory. Why it is generally better not to store passwords themselves, but rather use tokens/keys, it is not too bad IMO. The app has to store some kind of authentication token/key anyway, so by not using password, the only gain would be that an attacker capable of obtaining said key/token would loose access after the key/token were changed (you logged out). Because they would still be able to access your current and old mail at least until you logged out/had to type password again, this would be of little comfort.


How to interpret the scrypt vs bcrypt vs pbkdf2 comparison table?

To understand the table it is worthwhile to read the article. The table is only an illustration and estimation for memory hard function. Furthermore, the article states:

We caution again that these values are very approximate and reflect only the
cost of the cryptographic circuitry with circa 2002 technology: It is quite possible
that the costs of other hardware (control circuitry, boards, power supplies) and
operating costs (power, cooling) would increase the costs by a factor of 10 above
these; and it is equally possible that improvements in semiconductor technology
and improved cryptographic circuit designs could each reduce the costs by a factor
of 10.

The price of computing power has dropped quite a bit; in 2003, the KAYSO cost $82 per gigaflops, in 2017, an AMD RX Vega 64 cost $0.03 per gigaflops (so a factor 2733). Granted that FLOPS is not a real measure for dealing with brute-force cryptography, but you should, for the costs take a factor 2500 into account.
Bitcoin miners could probably, with quite a lot of effort, be used to crack AES256 hashes, which are not in the table. But for the rest they're quite useless. You might, if you are determined, create your own ASIC for this. That may be quite costly to develop, but afterwards easier to distribute.
That also brings us to your probability calculation. They are a very gross simplification. Real values depend on the scalability of the algorithm (might not be linear) and a lot of other factors.
Look also at the development of new algorithms. For example: Andrey Bogdanov e.a. presented in 2011 a paper how to significantly reduce the cracking time of AES 128, 192 and 256 bit keys (Biclique Cryptanalysis of the Full AES).
From al that to the question if a password is safe is really a step too far. For passwords, there are a lot of other issues. Most passwords are cracked because they are relatively easy to guess (qwerty123) and/or are in dictionary files. On the other hand, if a cracking device does not have the encrypted password, it will be difficult to decrypt, so access to your (even encrypted) passwords must also be controlled.


How are 2 Open IDs linked on StackExchange?

Stackoverflow likely uses an internal id after you log into the site.  Then (after logging in) you can merge the other IDs.

If you sign in using the alternate ID and never merged them then they appear as separate accounts, even if the user is actually the same human.

Here is SO's source code for OpenID.  Let me know if you dig up something interesting, the folks at StackExchange write great code you can learn from


Are Playstation 4 communications really harder to monitor?

Many of the news were just sensational news, not actual. There have been reports surfacing after this that security agencies monitor xbox and playstation communications. It came up as a playstation was found in one of the Paris attackers flats. It was baseless and been debunked quickly (https://motherboard.vice.com/read/how-the-baseless-terrorists-communicating-over-playstation-4-rumor-got-started) however that didn't stop the hoax.

The communications also don't use crypto as opposed to many better communication techniques for secret communications.

So the answer is, its quite easy to intercept and Sony probably helps law-enforcement do it already. Some reports even say they are also using algorithms to search for suspicious activity themselves.


Is ntpd running purely as a client vulnerable to the recent ntp vulnerabilities?

"Multiple buffer overflow flaws were discovered in ntpd's crypto_recv(), ctl_putdata(), and configure() functions. A remote attacker could use either of these flaws to send a specially crafted request packet that could crash ntpd or, potentially, execute arbitrary code with the privileges of the ntp user. Note: the crypto_recv() flaw requires non default configurations to be active, while the ctl_putdata() flaw, by default, can only be exploited via local attackers, and the configure() flaw requires additional authentication to exploit." Source

If you're just doing  server ntp.org in your ntp.conf, then no, you are not vulnerable.

As long as you have the default configuration and don't accept authenticated commands (sounds like you don't), then no.
And if your ntp.conf file has no lines active starting with "crypto".  (you said you didn't), then no.


Benefit of Parameter Map size validation in web application controller

This is answered by @kingthorin in StackOverflow
https://stackoverflow.com/questions/52092548/what-is-the-benefit-of-parameter-map-size-validation-in-web-application-controll

There are a few benefits to using a size map. Such as prevention of HPP attacks, etc. You've got to weigh the maintenance headache vs. the risk of such attacks with regard to your app. ZAP adds the query param on URLs with no params in order to test a few things like DOM XSS etc which might be missed or overlooked otherwise.


They matter. Not updating libraries and dependencies will leave your software vulnerable. Each one of the libraries is part of the attack surface.

Unless an update breaks your code, update as soon as the update is available. If the update breaks your code, patch the code and update. But never leave any outdated library with security bugs in your projects. Even if used only for development. If one day you forget to disable them, you are in danger.


How to disable weak cipher suits in java application server for ssl

JAVA allows cipher suites to be removed/excluded from use in the security policy file called java.security that’s located in your JRE: $PATH/[JRE]/lib/security  The jdk.tls.disabledAlgorithms property in the policy file controls TLS cipher selection. The jdk.certpath.disabledAlgorithms controls the algorithms you will come across in SSL certificates. Oracle has more information about this here.

In the security policy file, if you entered the following: jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 4096 It would make it, so that MD5, SHA1, DSA are never allowed, and RSA is allowed only if the key is at least 4096 bits. As for forcing TLS versions, this depends on your operating system (Linux, Solaris, Windows, BSD, etc), server (Apache, IIS, other)


Is it possible to locate Tor/proxy users? Spam is getting on my nerves

Your forum accepts posts from anybody. That is your core problem. Connecting to your site from various IP throughout the world is trivial, if only by using Tor. Tor provides "high anonymity" in that not only the user's identity is hidden, but each request is anonymous -- you cannot, from the outside, make sure whether two distinct requests are from the same human user or not.

This can be fixed at two levels:

Restricted anonymity: enforce user registration and authentication. Users may use a pseudonym, and need not provide an email address or any other identification, but your forum will insist on a login process before posting. That way, you can know whether two comments come from the same person. Note that this does not totally solve the issue; instead, that moves it to the registration process. The poor sob who has nothing better to do with his time than defacing your forum will adapt and engage into mass registration of phony accounts.
No anonymity (with regards to you): user registration, this time with an email address, which is verified during registration (you make sure that the registrant can read an email sent at the address he provided). The possibility to be identified, if only by law enforcement agencies, could be a powerful deterrent for wannabe spammers (even if the said spam is not necessarily punished by Law: to my constant dismay, there is no law against writing "LOLOLOLOL").

If you choose to retain anonymous posting, then, well, welcome to the wonderful world of Mankind. While most humans are civilized, honest and polite, there is always one user who thinks exposing his lack of education is a smart thing to do. The best you could do, then, is to patiently clean up (possibly proactively, by enforcing pre-publication control of all posts by trusted moderators) until the perpetrator loses interest or reaches the age of 14, whichever comes first. This may take a few weeks or months.

Historically, most societies have dealt with troublemakers by a mixture of ostracism and actual penalties (up to and including death). The apparent anonymity of Internet prevents efficient penalties (with a lot of resources, this anonymity can usually be unraveled, but police forces will not do that until an actual crime is committed). Ostracism is social pressure, so it does not work on people who do not feel the target forum as being a "society" they are part of.


Has my browser been hacked, there was a tab I didn’t open editing my LinkedIn profile

Hacking/obtaining access to WiFi is not enough to get into your computer/browser. It is likely your computer have been taken over using something like RDP or TeamViewer. I recommend disabling RDP and uninstalling TeamViewer. If you need the functionality, you should check more secure alternatives.

Another possibility is, that you have some sort of malware in your PC. You can not go wrong by using few tools to scan your PC. I recommend Malware-bytes at the very least.


Now that it is 2015, what SSL/TLS cipher suites should be used in a high security HTTPS environment?

Would an 'ideal' HTTPS service only enable TLS 1.0, 1.1 and 1.2 with key-size variants following ciphers?

No, an 'ideal' HTTPS service would enable only TLS 1.2 and enable only AEAD (Authenticated Encryption with Associated Data) based cipher suites with SHA-2, 4096 bit DH parameters and 521 bit EC curves of a type that matches your requirements (government approved or not government generated).

Said service would also be unable to connect be used by a wide variety of older clients, including Android 4.3 and earlier, IE 10 and earlier, Java 7 (at least u25) and earlier), OpenSSL 0.9.8y and earlier (OpenSSL 1.0.0 is simply not listed on my source), and so on.  It would, however, be immune to any attack that works only on TLS 1.1 and below, any attack relying on SHA-1, and any attack relying on CBC mode or outdated ciphers like RC4.

Client cipher suite limitations per https://www.ssllabs.com.

  What should be the most preferred cipher suite?

It depends!

I assume Foward Secrecy is a requirement.

I assume "believed to be reasonably secure at this time" is a requirement.

I assume "actually implemented by at least one major actor" is a requirement.

All requirements regarding must have/cannot use some or another subset of ciphers (must use X, can't use Y, etc.).

Thus, I would propose the following lists as a reasonable start.  Begin with the top category (TLS 1.2 AEAD), then keep going down the list and adding categories until you reach a level that works with your userbase or you've reached the end of your comfort zone, whichever comes first.

Include as many cipher suites of each category as you can, so that when the next attack rolls around, you'll be able to remove the affected cipher suites and continue with the remainder.

Keep an eye on the threat environment so you can continue removing cipher suites that demonstrate vulnerabilities.

Within each major category, please order or cull the cipher suites according to your taste: DHE is of course slower than ECDHE, but takes elliptic curve provenance out entirely, and so on.  At this time, it appears that ordering is a tradeoff, but if you want speed, prefer or even require TLS_ECDHE_*.  If you don't trust the currently commonly implemented elliptic curves, or are concerned about elliptic curves due to the NSA Suite B guidance from Aug 2015 indicating a move away from prior Suite B elliptic curves is coming in the near future, and are willing to burn CPU, prefer or even require TLS_DHE_* suites.

Bear in mind that "normal" certificates are RSA certificates, which work with both TLS_ECDHE_RSA_* and TLS_DHE_RSA_* cipher suites.  DSA certificates which work with TLS_ECDHE_ECDSA_* cipher suites are very rare so far, and many CA's don't offer them.

TLS 1.2 AEAD only (all are SHA-2 as well)

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xcca9, Pre-RFC7905 0xcc14)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xcca8, Pre-RFC7905 0xcc13)
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (new 0xccaa, Pre-RFC7905 0xcc15)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-3

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

These are the highest level of security I'm currently aware of in common TLS implementations.
As of Jan 2017, major modern browsers DO handle this level, including but not limited to Android with 6.0 supporting AES-GCM and - alone of the main ones - old valued CHACHA20-POLY1305 and 7.0 supporting new CHACHA20-POLY1305, Chrome with both AES-GCM and CHACHA20-POLY1305, Firefox with both AES-GCM and CHACHA20-POLY1305, IE and Edge with only AES-GCM, Java with only AES-GCM, OpenSSL 1.1.0 with both AES-GCM and CHACHA20-POLY1305, Safari with only AES-GCM).
Many major browsers cannot handle this, even 2015 vintage ones (Safari 7 on OSX 10.9, Android 4.3 and earlier, IE 10 on Win7 (IE 11 even on Win7 will support 0x9f and 0x9e if Windows has been patched)

TLS 1.2 SHA2 family (non-AEAD)

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-3

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 may category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)

For U.S. folks who are interested in NIST compliance, this is a TLS 1.2 should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-5

TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0xc4)
Note that you've lost AEAD mode and are using the much older CBC mode; this is less than ideal.  CBC mode has been a contributing factor for several attacks in the past, including Lucky Thirteen and BEAST, and it's not unreasonable to believe that CBC mode may be related to future vulnerabilities also.
Some modern browsers that don't have any AEAD cipher suites do have one more more suited in this category, for instance, IE 11 on Win7 can use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and Safari 6 and 7 can use a few of these

again, this is if you don't have ECDHE_ECDSA GCM suites working)

TLS 1.0 and 1.1 with modern ciphers (and outdated hashes, since that's all that's available)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

For U.S. folks who are interested in NIST compliance, this is a may category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2

TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Once you're including cipher suites from this level, you're likely to find something that works with almost all modern implementations.
At this level, you're not only using CBC mode, you're also using SHA-1. NIST SP800-131A recommended that SHA-1 be disallowed for digital signature generation after Dec 31, 2013 (a year ago today, actually).

TLS 1.0 and 1.1 with older but still reasonable ciphers and outdated hashes

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)

For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using RSA private keys and RSA certificates per NIST SP800-52 revision 1 table 3-2

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)

For U.S. folks who are interested in NIST compliance, this is a should category cipher suite for servers using elliptic curve private keys and ECDSA certificates per NIST SP800-52 revision 1 table 3-4

IE 8 on Windows XP is still out of luck, as is Java 6u45 due to DH parameter maximums.
This is absolutely the minimum level I'd recommend going to.

Note that for servers using RSA private keys and RSA certificates who need NIST SP800-52 revision 1 compliance, you SHALL, should, and may implement specific other TLS_RSA_* cipher suites which DO NOT PROVIDE forward secrecy, and thus I would not recommend unless this compliance is required.

Note also that paragraph 3.3.1 of that document states specific "The server shall be configured to only use cipher suites that are composed entirely of Approved algorithms.  A complete list of acceptable cipher suites for general use is provided in this section..."

Other national and industry requirements will vary, of course.

and may conflict with each other; read all of those that apply to you carefully.

I'll put in the usual plug here - try out your cipher list with your own tools (openssl ciphers -v '...' for openssl based systems), go to https://www.ssllabs.com/index.html first to check on cipher suites supported by various clients, then set up your site, and then go back to www.ssllabs.com and run their server test.

Note that _ECDSA_ cipher suites require ECDSA certificates, of course, and those are still very hard to find.

ETA: NSA Suite B EC advice, and IE 11/Win7 now supports 0x9f and 0x9e.

ETA: As of Jan 2016, NIST SP800-52r1 is unchanged, and one new cipher suite (0xc00a) has been added to the list.

ETA: As of Jan 2017, RFC7905 has change the three TLS 1.2 AEAD CHACHA20-POLY1305 ciphers, and "modern" browsers have drastically improved AEAD support as noted in new bullet.  See https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4   for up to date IANA cipher suites.


Adequate prevention of distributed brute force attacks?

Bit late here but there are a bunch of suggestions here: https://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure

A problem with "it would take approximately 14 hours to try a password on 50k accounts" is what if your legitimate user tries to log in after a bot net has put in 50k requests and has to wait the 14 hours? Not happy presumably.


Is the overwrite of a Javascript prototype method a XSS attack?

You don't seem to be specifying the vector by which the untrusted code is run.  This seems to be a good example of an attack that leverages how hard it is to sandbox / prevent vulnerabilities when loading and executing untrusted code.  While XSS is the most common vector for getting untrusted code to run in javascript, this does not seem to be an XSS.

This is similar to a CERT java issue:
https://www.securecoding.cert.org/confluence/display/java/OBJ57-J.+Do+not+rely+on+methods+that+can+be+overridden+by+untrusted+code


I discovered a Client Side Template Injection (CSTI), and after?

Try to get account takover or user data manipulation. This will be a very dangerous subject.
Good form rules tell us not to be destructive. Just describe vulnerability to security team and list potential harm moments.


There are a number of things that could cause your account to be hijacked.
Generally speaking an insecure password is not high on the list unless its been taken from a site that was recently hacked. To prevent against this, make sure you do NOT reuse passwords on different sites.

What's more likely is that your computer has some kind of malware installed on it and is key-logging your passwords whenever you change them.
In the case of spammers it's rare for them to manually target your account specifically (by say trying to reset your password using recovery questions etc).

I'd suggest using two factor authentication to sign into you email if you use a service like gmail that supports it.

I'd also suggest you check your computer for viruses/malware and ensure that any other devices you regularly log into (home/work/school etc PC's) are scanned as well.

Finally, its possible that someone might be intercepting un-encrypted login traffic if you are signing into something like hotmail where SSL isn't enabled by default. It's worth ensuring that your wifi traffic is encrypted and that users on any wired connection are trustworthy.

With any luck, one of the above recommendations will solve your problems.
Good luck!

Edit: As rory has suggested, your account may be spoofed and not actually compromised. Check your outbox/sent items to see if the email has indeed come from you. It might also be worth while checking the mail headers to see if it comes from your network or from somewhere else.


Approximately how much entropy/security is lost by typing passphrase words using a number pad?

tl/dr: This method hurts your password strength quite a lot due to the loss of characters (mainly since 0 and 1 are often left out when
entering letters through a numeric pinpad).  However, trying to brute
force a password here is slow, so with a long enough password you'll
be fine anyway.

Analysis
You already seem to know the answer, but I'll spell it out with a bit more detail in hopes that this is helpful.
Unfortunately, your selected method of password generation will, quite possibly, generate the lowest possible amount of entropy. Obviously you would get less entropy by picking a clearly bad password, but this method still gives pretty poor results.
The best way to see this is by comparing against it's entropy ceiling - a pure digit password. That's a simple one. If all you have is numbers then you have 10^n possibile passwords, where n is the number of digits in your password. A 4 digit password has 10,000 possible combinations, etc...
In your case though your numbers are determined by conversion from letters. As you know, the English language doesn't use letters evenly, resulting in a loss of entropy. It would be difficult to determine exactly how much entropy is lost, so a good paper would be required. I don't have one of those though, but I can still guestimate!

You lose at least 1 number because in most letter mapping systems the 0 is unused
Many telephone keypads leave the 1 unused as well
And of course the variation in frequency hurts. Harder to estimate so I'll just knock off another digit and call it a day

You'll effectively lose 2-3 possible characters out of the 10 you have.  This actually takes a big hit out of your entropy, because the number of possible passwords is determined by [Number of characters]^[Password Length].  The presence of that exponent makes this very non-linear, as we'll see below.
Brute-forcing
Is this a deal breaker though? That depends!
Deciding how difficult a password is to crack depends on two things: the number of possible passwords, and the rate at which an attacker can guess passwords.  Both can be determined accurately enough in this case.  First, how many possible passwords are there?  Let's assume you end up with a 12 character password, and let's compare against three passwords: randomly chosen numbers and characters, randomly chosen numbers, and random numbers without 0 and 1.
We also need to know how fast an attacker can run through passwords.  Just for kicks, I'm going to compare two speeds: the rate at which a high-end GPU hashing rig can crack MD5 hashes (200GH/s), and the rate at which a very experienced person can enter numbers into a pinpad.  Obviously the former (the MD5 hashing rig) is not in the least bit applicable here, but I want to include it because I think it will give a helpful reference.  For pinpad entry, it's hard to guess exactly how fast an attacker can enter passwords, but we'll be generous and give them 10 guesses per second.  Here are our numbers:

12 character alpha numeric password.  Number of possible passwords: 62^12 = 3e21 (entropy = log2(3e21) = 71 bits of entropy)
12 character numeric password.  Number of possible passwords: 10^12 = 1e12 (entropy = log2(1e12) = 39 bits of entropy
12 character numeric password (but without 1 and 0). Number of possible passwords: 8^12 = 6.9e10 (entropy = log2(6.9e10) = 36 bits of entropy.

Against a cracking rig
Our cracking rig can check 200,000,000,000 (aka 2e11) passwords per second.  Simply divide the number of passwords by the hashing rate to get how long it will take to crack it:

Alpha numeric: 3e21/2e11 = 1e10 seconds = 511 years
All numbers: 1e12/2e11 = 5 seconds
Numbers without 1 & 0: 6.9e10/2e11 = 0.3 seconds

As you can see, there is a huge difference in their cracking times.  For reference, some websites still use plain MD5 for storing passwords, so the above math is why using a long, random password is required.  Of course an attacker can't just hook your wallet up to a GPU cracking rig and run through guesses that quickly.
Hand entry
Instead the passwords have to be entered by hand, so we'll try again with our 10 passwords per second rate (which is probably very generous):

Alpha-numeric: 3e21/10 = 3e20 seconds = ~700 times the age of the universe
All digits: 1e12/10 = 1e11 seconds = ~30 centuries
Numbers without 1 & 0: 6.9e10/10 = 6.9e9 seconds = 2 centuries

Your password is still quite uncrackable under these circumstances, but it is worth noting that losing just 2 out of 10 possible characters reduced the cracking time by a factor of 15!
The above analysis assumes a full brute-force search of the entire password space.  For a long diceware-style password that is actually quite unrealistic, and an attacker would be better off working off of the actual word list.  In that case, a more detailed analysis from the OP shows that the loss of entropy is much smaller.  Either way though the overall summary remains the same:
Summary
So your chosen method definitely weakens the password.  However, given that these passwords have to be manually entered (and therefore password cracking is quite slow), you can still get sufficiently secure passwords even with this method, as long as it is long enough.
Personally though, since we're talking about a potentially high-value target that someone has to physically steal, I'd be more worried about rubber-hose cryptanalysis.


How to identify and analyze malware that checks for security tools before running?

Malware was detecting the presence of Rootkit Revealer, so they changed the way that program ran.  It now is started by a windows service with a randomized executable name.

Similarly, you could use a supervisor process to launch procmon and any other detected executables under "assumed" names.


It does get traced back to your IP. However, this isn't really practically avoidable.

What you can technically do is a "idle scan" with nmap. I won't go into the technical stuff too much, but it's based off the side channel of IP ID being incremented. However, I've never heard of hackers actually using this method.
https://nmap.org/book/idlescan.html

However, the internet is getting scanned so much, that there is no way for the admin to investigate every port scan.

On a local network, you'd want to slow it down a lot so it doesn't get detected as a port scan. That's what phineas phisher did when he hacked the hackteam. Even on the local network, there are many false positives when it comes to detecting port scans.

It's also possible to use IP spoofing or proxies to mask your IP address by hiding it among many other IP addresses. Furthermore, a proxy or VPN may be used for port scanning. This will completely hide your IP address from the target. You can also combine the two methods.


What you have proposed is analogous to texting a password (but with TLS). As long as the doc is a separate channel from the account in question, and there is nothing relating the password string to its account, then you have a similar threat model.
The doc can be downloaded, saved, undeleted. A compromised Google account exposes the password strings. But all that is similar to a texted password.
So, it would seem that the approach improves on email and text by ensuring deletion of the central doc, ensured TLS, and access logging. It does not appear that the process introduces any more threats than email or text.


How safe is RSA generated public-private key pair?

They can, but bruteforceing these keys takes too much time to actually be a plausible attack. This depends on things like key length, but in general we are talking about on the order of thousands of years (or more!) to bruteforce. And as far as I know, RSA keys aren't subject to key wear, so using a public-private key for a while won't help attackers discover the private key.


Difference between Symmetric and Asymmetric encryption

The underlying protocols used for HTTPS are SSL3, TLS1.0, TLS1.1, TLS1.2, etc.  Each of these have a different way of exchanging keys, so there is not a one-size fits all answer to this question.
However, in symmetric encryption, the message is encrypted and decrypted using the same key.  In asymmetric encryption, the message is encrypted using the public key, and the private key is used to decrypt the message.
But, in practice, a sender typically does not use the recipient's public key to encrypt a message (using asymmetric encryption) directly, because this takes a lot of computational resources.  Instead, the sender generates a symmetric key on the fly, then this symmetric key is used to encrypt the message (using symmetric encryption).  Then, the symmetric key is encrypted using the recipient's public key (using asymmetric encryption) and this encrypted symmetric key is sent to the recipient along with the encrypted message.  On the receiving end, the recipient decrypts the encrypted key using his private key, then uses this key to decrypt the message.
See http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html for an excellent walkthrough of how all of this works in TLS1.0.  Even though this was written in 2009 and TLS1.0 has long been outdated at this point, you'll probably find this blog post to be very instructive if you're trying to get your head around these concepts for the first time.  Once you're comfortable with this, have a look at https://tlseminar.github.io/first-few-milliseconds/, which is based on TLS1.2 (which uses a whole different method of key exchange, based on elliptical curves).


Metasploit MacOS victim - tools to enable remote desktop / GUI view of the victim

Q1: Is there a similar one-command to setup tool for MacOS victims? .. or maybe some metasploit / evilosx modules to set up a VNC connection?

You can try to use vnc_login auxiliary scanner to identify if there's available VNC in target and attempt to login with a password or a wordlist:

msf > use auxiliary/scanner/vnc/vnc_login

And/or ard_root_pw to remotely exploit CVE-2017-13872 over 5900 port - if requirements are met:

msf > use auxiliary/scanner/vnc/ard_root_pw

  Some notes by ard_root_pw's author (jgor):

    This extends Rex::Proto::RFB to support usernames, implements authentication security type 30 ("Apple Remote Desktop" / ARD used by macOS), and uses that to add a module to remotely exploit CVE-2017-13872 over 5900/tcp on vulnerable macOS High Sierra hosts that have either Screen Sharing or Remote Management enabled.

  (source)

  Q2: Or I must do it manually without easy to use scripts?

If you already have access (w/ shell or meterpreter) in target, you should consider that Apple includes a VNC Client by default, you can use it with a simple bash script:

echo '#!/usr/bin/env bash' >> /usr/local/bin/vncviewer
echo open vnc://\$1 >> /usr/local/bin/vncviewer
chmod +x /usr/local/bin/vncviewer

After that, simply use: vncviewer [IP]:5901

(source)


From the linked article:

  BioStar 2 is a web-based biometric security smart lock platform. A centralized application, it allows admins to control access to secure areas of facilities, manage user permissions, integrate with 3rd party security apps, and record activity logs.

It seems that unless you have access to somewhere that uses biometrics for that (and they used this software), you won't be affected.


Is forcing users to change passwords useful?

As you note, when you force users to do something, they do not like it, because it makes things more difficult for them. Users rarely focus on security; it is not their job, and, instead, their job implies going through the hoops that the security department comes up with. So they react logically, by taking measures which make their life easier.

Classical countermeasures employed by users include:

simple derivation of the new password from the previous one (but there are password management interfaces which try to prevent that: "the new password is too similar to the old password");
cycling through a list of passwords, usually reduced to two passwords; the user just swaps his "normal" and "alternate" passwords whenever a password change is requested (to prevent that, the password management system must remember previous passwords, which can itself be a security hazard);
the all-time favorite of writing the passwords down on a sticky note (cunningly hidden under the keyboard);
getting passwords from a "natural list", e.g. current players in a soccer team (it is not easy to make an automated test which will detect that, but a human attacker with half a neuron will handle that easily).

So the increase of security through regular password change will be, at best, dubious. Its main virtue is to avoid the establishment of a local "traditional password" which employees communicate to each other for years, and previous employees keep on remembering.

Theoretically, regular password change might give users a sense of "something worth protecting is going on" and prompt them into being more cautious with their passwords; in practice, I have never witnessed that.


If you're not running an opcode cache then you're DOSsing yourself already, particularly if you're running Drupal! It makes for a nice business model if your renting out server hardware!

There are some edge cases where running suPHP makes sense from a security point of view (but the number of these is massively reduced by php-fpm's support of pools per user) - but this is not one of them. (if you were using php-fpm, then it might be worth considering having a dedicated user for handling the file upload path).

The best protection against a DOS attack is having the capacity to deal with it. The second best option is being able to profile the attack and easily inject specific handling / blocking.

  and removed write privileges for any directory/file except where image uploads, etc may occur.

This is not enough on it's own - you also need to disable PHP parsing (and, preferably any direct webserver access) to the uploads dir.

Controlling your server via WHM is not a good idea if you're concerned about security.

Regarding the previous attack...this is a seperate question, and there's not nearly enough information to hazard a guess - even if that information were available, it's probably beyond the scope of an answer here. It's rather unlikely that the PHP config would cause the symtpoms you describe ('I remember a non admin seeing admin privilege protected pages') - it's more likely to be a code defect  / issue elsewhere in the stack.


What happens when I send a git request to a Malicious Site?

The worst that can happen, is that you may have a security bug you don't know about in your git client, and the remote you accidentally connected to may host a specially crafted repository to take advantage of it, and you will be pwned.

Unlikely? Yes. But there has been at least one git vulnerability allowing remote code execution during a clone in the past. And git, like any network-enabled software of sufficient complexity, has had its share of security vulnerabilities.

If you're running with sudo, obviously remote code execution could be far worse than normal. So maybe avoid doing that in the future if you can.


What tools to use when researching possibly illegal topics?

Tor browser is designed exactly for this purpose.

Unlike a VPN, which alone is really only useful for providing confidentiality and integrity between you and your ISP (e.g. when using hotel WiFi), Tor is designed explicitly with anonymity in mind. It is easy to use and free, and provides an extremely good level of anonymity, which is perfect for research of illegal or questionable material. Using it is most certainly not overkill. It is a good idea.

VPNs have a nasty history of recording browsing history even when they say they don't, and revealing the logs to law enforcement when they request it. Tor, which connects to a website over three random relays, is designed such that no individual relay is able to simultaneously know both who you are and what website you are visiting. This is what provides such a good level of anonymity.


Security benefits of hosting your CMS on localhost

If your CMS is listening to 127.0.0.1 ("localhost") and not to any other IP addresses on your system, then yes, no one online will be able to access it.  You will be the only one able to access it, while logged into the computer it's running on.

It is unusual that this would be what you want, but hey, maybe you just want to use your CMS as a personal library.  If that's the case, have fun.

If your goal is to secure your CMS but still allow other people to access it, this is not an appropriate step.  If that's the case, I'd start by Googling "how to secure XXXX" where XXXX is the name of your CMS (wordpress, drupal, what-have-you).  Any major CMS will have guides describing standard security steps.


Size of a secure random number taking into account quantum computing and size of universe

Quantum computers are not magic. They can only accelerate a very specific class of problems in the so-called BQP complexity class. This includes integer factorization, which is why a cryptanalytic quantum computer is said to be capable of completely breaking RSA keys in polynomial time by utilizing the quantum Shor's algorithm. However, their ability to brute force through a keyspace is much more limited. The most efficient quantum algorithm for searching a keyspace is Grover's algorithm, which provides only a quadratic speedup over classical algorithms. This means that a quantum computer can brute force a 256-bit key in only 2128 operations instead of 2256 as with a classical computer. Luckily, this means all we need to do to resist quantum computers when choosing key size is choose a 256-bit key or larger. You only need to double the key bits to retain the equivalent classical security against quantum computers. If we consider 128-bit keys to be the minimum, then double them to 256 bits.


Is overlayroot a significantly more secure way to use the Internet?

Running a system from RAM only like you propose makes it harder to permanently infect the user account the browser is running on because user only infections will be removed on the next restart.

But, you propose overlayfs which means that most of the data are still stored on some permanent storage and only few data like browser history or cookies are stored in RAM and thus reset on next start. This means that if an attacker finds both a browser exploit to get user access and then a privilege escalation to get system access then the attacker could still write directly to the disk installed in the system (bypassing overlayfs) and thus make the infection permanent.

Insofar your approach is more secure than the normal setup but it still has its problems. Using a physically read-only media like a DVD as the base file system like many live distributions do would be more secure but would still make it possible to make permanent changes to BIOS/UEFI and other permanent and read-write storage on the system.

But of course none of these approaches help against session hijacking or identity theft or similar attacks possible due to bugs in the web applications used. And they also protect you against CSRF or other web based attacks which infect the local router in the network since no local permanent storage is needed for these attacks.


I've already answered this question a few times here. Have a look at this answer in particular:
Virus scanner on server
And in particular this part:

The concept of a virus implies a user at an interactive session. Someone opening email in Outlook or documents in Word, or running programs they received in an email. A virus implies a human element. Servers don't (or shouldn't) allow reading emails and browsing websites. Instead, attacks against servers are fully automated; no human required. They call that a "worm" rather than a "virus".
Worms are a concern on Linux. But protecting your server from that type of threat works differently. Protecting users from viruses requires something stopping users from doing things they shouldn't. Hence the "anti-virus". But protecting servers from worms and similar exploits involves fixing vulnerable software. If something is exploitable on your server, then the thing needs to be fixed.

A virus scanner watches files to see if they will hurt you if you run them. That's not a concern on servers because the only programs you're ever going to run are already there. As a rule, you're not downloading and running new programs on servers the way you do on desktops.
Assuming Linux is running as a server, (which RHEL pretty much always is) Running an anti-virus is the wrong kind of protection. It protects you against threats that can't hurt you, while ignoring the threats that can. This is why RHEL doesn't offer antivirus integration. Because Redhat understands server security.
This has nothing to do with how popular Linux is or whether virus writers will target it, as commonly argued. This has to do with how the server is used. There is no user browsing email in Outlook, or download flash movies and running them. So preventing dangerous user activity is not a valuable solution.
If your QSA is demanding you run an anti-virus on your Linux server, then you need a different QSA. This one hasn't a clue.


Here's the PDF of the standard

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf

That shows (page 4 & 5) that RIM set nbiterations as 1.

Here's a more general overview for people wanting a bit of easy to read background:
(It's a blog post of a company selling products which they mention on that page, with a single text link.)

http://blog.crackpassword.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/


Best practice to verify data against a CA

Let's say that I have signed my public key with a trusted CA and the
  CA provided my with a signed certificate, and I want any client
  applications to verify against this certificate. The general process
  is that the client verifies against the CA's public key, and not my
  own, so I do not even need to transmit the public key, but what is the
  best practice to implement this in a C# client application?

You DO need your public key (contained in the certificate) on clients to validate the signature you have done with your private key. You use the CA certificate to validate your certificate signature (a certificate is a public key + some info about the owner (subject) of the certificate).

You may send your certificate on every request or have it cached on the client, that is language independendt.

  My current chosen approach is that on the server application, I am
  storing the certificate (which contains my private key) in my local
  store, which I use to sign data. Then, on the client application, I am
  loading the Root store of the Current User and I pass the certificate
  name of the CA which signed my certificate, and if this CA is found in
  the store, I retrieve its public key and I verify against that. If my
  public key has been signed by the CA, then verification should
  succeed, otherwise it will fail. Is this the correct way of
  implementing it? If not, please provide better solutions.

It is not the correct way. You should have your certificate on the client. Verify the certificate using the CAs certificate and then use your certificate (that contains a public key) to verify the signature.

  The following are my questions regarding my chosen approach:

All of those wont happen if you correctly validate your certificate against the CA certificate. I would recommend not to reinvent the wheel here, and use some standard Certification Path from a good library, since it is complex to get it all right. I´l explain above how each thing is solved in a Certificate Path validation:

  Can the Certificate Name of the CA change? If so, I would have to
  change it in code. If this can change, what else should I use to
  search for the certificate? Maybe the SerialNumber?.

Your certificate has fields that identify correctly and exactly the issuer of it, using many fileds from the certificate that should not colide. If they colide, still, the signature of your certificate needs to match.

  Can someone create the same Certificate Name. I am assuming that you
  can. For instance, a hacker might create a certificate name which is
  the same as an established CA, but it is obviously up the user to add
  it to the trusted store on his machine. If he does not, then the
  hacker does not have any power whatsoever. Also, I do not think that
  two certificates can have the same Serial Number.

That will be soved by the signature of the CA on your certificate, that you will verify before using it.

  If my private key is hijacked and I revoke the certificate,
  verification should start failing on the client's applications. It
  will start verifying successfully once I start signing the messages
  with the newly issued certificate by the CA. Is this correct?

That will be solved by revocation checking, that you should enable on the certification path verification. When theprivate key is hijacked, you need to ask the CA to revoke it, and it will be added on a CRL (certificate revocation list) that is checked on the the certification path verification.

  Finally, I do not currently possess a signed certificate so I cannot
  test this out. That is why I am asking these questions, so that if
  this approach is correct, I can proceed to buy a certificate since I
  know the way forward. Also, hopefully, this question might help other
  people with the same problem.

You might create your own CA and do tests, using Microsofts CA, openssl or other tools. There are a lot of tutrials on that availble.


Is secure web-app off-line auth possible?

I'll answer your "2" questions below:

As for the salt: a salt is supposed to be public. Sometimes an extra secret value is used (e.g. by pre-pending to the password). This is often referred to as "pepper".
Try TLS with client authentication. Use the credentials within the client certificate (after successful authentication & session establishment) to provide access control.
Yes, it is possible to derive a DES key "in a good way"; use PBKDF2 with a high iteration count and large random salt. The DES key is however not secure anymore once it is used for encryption because of brute force attacks.


Should I worry if I have tried to ssh into a 'fake' dyndns.org site? (with ssh keys)

Change your password.

Anytime you enter a password into an unknown server, change it immediately.

I don't believe your keys would be at risk, as the private key itself is never transmitted, only used to sign a piece of data to verify that you do in fact have it.


Why doesn't Google uninstall or report, installed pirated apps?

Android is an open source system. Its the users choice what to do. If he wants to install pirated apps google will not stop him. If google would, the users would disable google play and youre still not blocking pirated apps.


What Steps Does An Anonymous Artist Need To Take to Retain Anonymity?

If hacking google to gather your phone details is considered a threat to your anonymity then surely the ISP logs must be also - they can relate you to your address much more so than most these other things, in which case a private VPN or TOR must be used. To be honest I would recommend TOR (browser/bundle) anyway, as it enforces the forgetful browser in case you dont remember to..
Other things to look for are GPS/camera tag information if you upload photographs - its appalling the number of site/users that don't remove this information (potentially down to GPS coordinates and time).
A virtual machine with one of the anonymity operating systems (tails or whatnot) would probably be good enough for your purposes though without being too "over the top": Tails - I know you aren't keen on the idea, but it is well suited for anonymity and will work out to be EASIER than manually ensuring these things are in place before using your identity online.
Incidentally, getting those IP logs would take a huge (bribe or) lack of security on the ISP's part or a warrant (It's a non issue with TOR though).
Registering websites and domains are more complicated, unless you can find one that accepts bitcoin payments and dont mind the hassle of that. Prepaid cards might suffice with privately registered domains. But really only you can determine the lengths you are willing to go through.


Is sending only password (not username) by sms secure?

Really your question needs a lot more context to answer fully.

The likelihood is that your answer will be: 'No, its not inherently terrible to send a user a password via SMS if done with careful consideration.'

SIM spoofing/cloning risks are not really worth considering for the majority of applications, although yeah... if you are designing a system which launches nuclear missiles, SMS would not be adequate.

The biggest realistic technical risk to using a phone number as a point of contact to deliver a password is that phone numbers get recycled. While email services typically haven't let you re-use a dead account since the early 90's, many phone operators still recycle numbers quite quickly and autonomously - with there not being much you can do about it.

Secondarily, you are obviously going to have to involve a third-party's infrastructure to physically deliver the SMSs for you, which adds and expands to the attack surface of your application.

There are some quirks you get via SMS also, such as how the message can spread to multiple devices (like from an iPhone to a Mac) and that technically increases the exposure/footprint of the password, although the same is true of email these days; with users have several devices all signed into the same email.

You could argue that more people have insecure phones than email inboxes. But its a bit of a thin argument as if you have the phone of a victim that has no password protection, that phone is probably authenticated to their email already anyway.

The fact that you are going down a road much less travelled with this design leads me to also speculate that you might be doing odd/bad things elsewhere in the application. While its not related to your question, you might want to consider (if you have not already):

After you send the password, are you storing it encrypted?
How are you generating it?
Does the user have to change it on first logon?


I have forwarded port 80 to WAMPServer and 25565 to the MineCraft-server running Bukkit. (http://www.bukkit.org/)

I assume that you're talking about forwarding those ports from a router / firewall / NAT box to your own machine rather than forwarding them to some off-site instance. Usually we call this "opening" a port.

  Am I vulnerable to attacks. Can hackers attack me if WAMP-server is running or if it is not running, or will it be easier to hack me than if I hadn't opened the port at all?

Yes, you are more vulnerable by running a service than by not running a service. Adding more services increases attack surface. That doesn't mean by that you're vulnerable by definition, but an increased attack surface increases is one of the factors that increases your risk.

  I have tried to learn about how people hack and how to protect myself from it. Do you know where I can read about it?

The more time I spend here, the greater resource I find this site to be. I've never found a really good comprehensive guide to how to be secure. There are books like the Hacking Exposed series that talk about a lot of technical aspects to security and some of the mindset. As much as the CISSP might be railed upon, trying to study up for that exposes one to most of the different knowledge domains that a professional should be aware of. I think that reading questions on this site is a great way to learn.

The challenge is that security is a mindset. The technology and even some of the fundamentals of it are an evolving realm. You learn by exposing yourself through trial and error. It is helpful to make as much of that exposure as possible vicarious -- learn from others' mistakes.

Security as an equation works like this:

Decide what you need to offer -- you have a need to provide something with a WAMP server and Minecraft game server.
Limit everything you don't need to offer and do it in depth.

When I say in depth, I mean that only offering those services is a start. Try to make sure that the programming code on your website is written securely. Then, pretend it has been compromised and consider what can happen from there. Is the Apache process prevented by the operating system controls from writing files anywhere? Do you have a method to detect compromise? Keep asking those questions and finding layers of answers so that if you are hacked, you mitigate your risk.


Execute a remote PHP shell which is inside a file I dont have permission to access

It really depends on the upload function and how it is designed. Have you tried looking at the request? Sometimes applications include a 'directory' variable, or even parse one sometimes when it's not there. Is it a custom application or one that you can download trial for?

Also, does the application support other types of server side code?

Here is a video on "Java code smuggling" also known as GIFAR (GIF + JAR): https://www.youtube.com/watch?v=5TgfKKX7uSQ

Finally, if the site supports .htaccess files you may be able to upload a backdoor that way:
https://github.com/wireghoul/htshells


Yeah, I can say that the problems you are experiencing are problems of the driver because they are printing a very different output on iwconfig commands than the rest of the drivers for the rest of the cards.

So, all the Realtek chipsets RTL88xx like yours (RTL8812AU) are having problems using airgeddon due this different output. Anyway, there are some workarounds:

Since the airgeddon v10.0 was released, there is a new awesome feature, a plugins system. Now users can develop their own custom stuff. More info here: airgeddon Plugins System. What is this useful for these kind of cards? because there is a plugin to handle that awful different behavior. You can find it here

So with the plugin, you can use safely that cards with airgeddon.

Anyway, check the list of the recommended and whitelisted cards: airgeddon Compatible Cards

For the next v10.01 airgeddon will have removed use of ifconfig and iwconfig commands (they are deprecated). Instead, ip and iw commands are used... so for v10.01 the plugin will be no needed.


Okta backend verification of Access Token generated in PKCE flow

Okta and the client app are using RSA as the underlying verification mechanism.  Okta signs its JWTs using the private half of an RSA keypair and publishes the public half of the keypair at that /keys endpoint.  The JWT contains the ID of the key that was used to sign it, so the client app can then retrieve the public key and use it to verify that the JWT was signed using the corresponding private key.  If the signature verification succeeds then the client can infer that Okta issued the token and that its payload hasn't been altered, since Okta is the only party who has access to the private key.


packets characteristics (src,dst ports) of a DDos amplification attacks

For an up to date list of protocols used for DDos applification attacks, see UDP-Based Amplification Attacks

Currently the list is

+------------------------+--------------------------------+------------------------------+
|        Protocol        | Bandwidth Amplification Factor |      Vulnerable Command      |
+------------------------+--------------------------------+------------------------------+
| DNS                    | 28 to 54                       | see: TA13-088A               |
| NTP                    | 556.9                          | see: TA14-013A               |
| SNMPv2                 | 6.3                            | GetBulk request              |
| NetBIOS                | 3.8                            | Name resolution              |
| SSDP                   | 30.8                           | SEARCH request               |
| CharGEN                | 358.8                          | Character generation request |
| QOTD                   | 140.3                          | Quote request                |
| BitTorrent             | 3.8                            | File search                  |
| Kad                    | 16.3                           | Peer list exchange           |
| Quake Network Protocol | 63.9                           | Server info exchange         |
| Steam Protocol         | 5.5                            | Server info exchange         |
| Multicast DNS (mDNS)   | 2 to 10                        | Unicast query                |
| RIPv1                  | 131.24                         | Malformed request            |
| Portmap (RPCbind)      | 7 to 28                        | Malformed request            |
| LDAP                   | 46 to 55                       | Malformed request            |
| CLDAP                  | 56 to 70                       | —                            |
| TFTP                   | 60                             | —                            |
| Memcached              | 10,000 to 51,000               | —                            |
+------------------------+--------------------------------+------------------------------+


How to allow users to connect from multiple devices with refresh tokens?

In my opinion the question you're asking now is not really regarding security anymore, instead it's more focused on the implementation of a concept. You have already established that refresh tokens makes it harder for attackers and it appears like you have a working implementation. From what you are describing, you are making use of a custom solution and not something like an OAuth2 library implementation that will provide this functionality to you.

What you now need to decide is if you want multiple device authentication from the same user account. If you do not want users to sign in from multiple devices on one account, congratulations, your solution is already working. They will be logged out from the old device soon since it will not contain the correct refresh token after a timeout.

If you do want to provide users the ability to sign in from more than one device on the same account, you unfortunately require a few changes. A possible solution is to add a device identification field in your database and issue a refresh token per device.


What are the most common username-based password patterns?

Username + Current Year

Username + Digit (any of 0-9)

Username + 123

Those are my top 3 determined from a 4000 stations login surveys in a large company.


Bcc list of an exchange server email accessed by someone who was forwarded the email

The whole idea of BCC is to not disclose any BCC recipients to each other. An email program whose sent mails allow the recovery of BCC recipients is terribly broken.

The Exchange Online docs also confirm that they don't intend to forward addresses in BCC:

  Bcc recipients are stored in the message in the sender’s mailbox, but not included in headers of the message delivered to recipients.

Ideas about what could have happened:

Did you use BCC correctly? It only hides the list of BCC recipients. Any addresses in the TO and CC fields will be disclosed to everyone who received the mail, regardless which field they're in themselves. (That is, a BCC recipient will know who was in CC.)
Did you use any email encryption system? There is some research, for example in this Stanford paper, on how numerous encryption systems completely expose BCC recipients due to their encryption mechanisms.
Does the person who accessed the recipients have access to the mail server or its traffic? The messages to BCC recipients are visible in the traffic and server logs just like any other emails.

To investigate the problem further, you could send a test mail with you and someone else on BCC, and inspect the raw email data to see if there are any hidden headers indicating the BCC recipients.

If you only have a small number of BCC recipients you might prefer to first send the message to all disclosed recipients and afterwards forward it to everyone else individually.


How can I crawl the internet for malware?

Try starting with public spam email messages.

For example, some accounts on mailinator.com receive a lot of spam. There is also a lot of public spam available on untroubled.org.


Will it matter if I give to someone the IMEI or Serial number of my device?

Knowing the serial number of a pacemaker won't allow you to magically stop it.

Now, the IMEI is sometimes used for things it shouldn't really be used like authenticating you on WhatsApp (a weakness of the app). Thus, it's not recommended to go around publishing it (OTOH for instance the manufacturer will require you to provide it before giving support…).


How is a password kept secure before hashing?

I think the short answer is that TLS provides encryption in transit over the internet, but the password needs to exist in plaintext on both the browser and the server, and usually little is done to protect or obfuscate it there.

Your browser will establish an encrypted TLS session with the server; which means the wifi access point, your home router, routers on the internet, etc will see the password go by encrypted.
The TLS session will be decrypted at the server and it will have the plaintext password in memory. Since it needs the plaintext to do the hashing, this cannot be avoided. Best practice is to have the password in memory for as little time as possible; ie hash it, check it, and then free that memory (zeroing it out first if you're in a programming language that lets you do that); basically don't keep the password around in server memory longer than you need to.


Dealing with SSL Certificates on Products

We are installing the same self-signed certificate into every development and prototype unit.

Installing the same certificate into every unit is about the worst security practice one could imagine when dealing with certificates. We now know not to release products with the default hard coded administrative credentials. We avoid default credentials because such credentials could be extracted once and used to compromise all devices that implement them. This is a very similar situation – the default certificate means the private key could be extracted once and used to compromise all devices that rely on this certificate.

Cryptographically, both self-signed and trusted third party certificates operate the same way. Each certificate is associated with a key pair consisting of a secret private key and a non-secret public key. If you know the private key, then you can perform every action associated with the public key and certificate.

The compromise of the default certificates has further implications than just compromising authentication. For TLS, depending on the cipher used, the certificate could end up being used to establish a shared secret. In such cases, a passive eavesdropper would be able to decrypt TLS traffic after seeing the initial handshake.

Sure, competent administrators will fix this issue by uploading their own unique certificates, but how many would actually stop at 'just make it work' stage by trusting the default certificate?
What you should do instead is generate a new key pair on initial boot or factory reset. This is how secure network devices operate. When generating new certificate, you also have to make sure that you have sufficient entropy available in the system and do not end up generating factorable keys.


The simplest way to defeat this type of attack is to use a notification email instead of an error message. When someone tries to create an account using an email address respond with "Thank you for registering, an email has been sent to this account for confirmation". From then there's 2 cases:

The email is not registered: the email would notify the account holder that a registration attempt has been made using that email address and have links to either confirm the registration, or do nothing and the registration attempt will fail
The email is already registered: the email would notify the user that an attempt has been made to register using the email address, and that an account already exists. Give them options to recover their account if it is a legitimate attempt to access. Tell them to do nothing if it is not legitimate

The benefits to this system is that an attacker won't know whether the email has been used in the account or not, the users are notified if someone is attempting to create an account in their name, and you will be notified if someone is trying to discover account information.


Is my current method of handling session cookies insecure?

You asked: Am I exposing potential vulnerabilities by exposing the same session cookie to all my  users' subdomains?

Answer: It depends, but generally speaking, yes, you could be exposing yourself to some attacks.  It depends upon what kind of content you allow on the subdomains (e.g., elmer.acme.com).  There are two cases:

If you allow Elmer to put arbitrary HTML on the website hosted at his subdomain elmer.acme.com, then you have a problem.  Using the same session cookie on all subdomains is a security hole in this case.
The attack: A malicious Elmer could set up his site elmer.acme.com with some Javascript that reads the session cookie of anyone who visits his site and steals it.  Then, if poor Bugs Bunny visits http://elmer.acme.com/ (Elmer's site), Elmer learns Bugs Bunny's session cookie.  Now Elmer can pretend to be Bugs Bunny when visiting other subdomains (including Bugs' own site).  That's no good.

If you somehow prevent Elmer from writing arbitrary HTML, Javascript, etc., to the website on his subdomain, then you might be OK.  However, be warned this may be tricky to do securely, if you allow the users a lot of control over the content on their subdomain.  You'll have to block a lot of stuff (including Javascript, Flash, Java, META tags, and maybe more).

Generally speaking, the reason to use multiple subdomains is to isolate multiple users from each other, so that one malicious user cannot harm other users, and so that a security failure by one user does not harm other users.  If that's the reason you are using multiple subdomains, then your practice of using a single session cookie on all domains is insecure and should not be used.
In other words, most folks who are using multiple subdomains are probably in the first case, and thus I would expect that in many cases where multiple subdomains are used, it is not a good idea to expose the session identifier to all subdomains.

A better approach, that doesn't have these problems: Add a login page on acme.com.  When users log in on acme.com, give them a session cookie that is scoped to acme.com only (no subdomains).  This will be the secure session cookie.
When users visit a subdomain, you can do some tricks to authenticate them using their acme.com-session cookie and then give them a new cookie that is specific to the subdomain, without requiring them to log in again.  The backend webserver can remember the association between the subdomain-specific cookie and the secure session cookie, so the webserver will be able to manage authentication in a way that the user doesn't notice.
This way, because you are separating your cookies by domain, you get better security.  If one subdomain hosts malicious content, it learns only the session identifier for that subdomain, but it doesn't learn the session cookie for acme.com or for any other subdomains.
For instance, the secure session identifier for acme.com might be 7a3f...90 (cookie: SESSIONID=7a3f...90, scoped to acme.com).  The session identifier for elmer.acme.com might be 09ac...b3 (cookie: SUBDOMAIN_SESSIONID=09ac...b3, scoped to elmer.acme.com), generated as SHA1(7a3f...9 || elmer.acme.com) = 09ac...b3.  The session identifier for fudd.acme.com might be f067...85 (cookie: SUBDOMAIN_SESSIONID=f067...85, scoped to fudd.acme.com), generated as SHA1(7a3f...9 || elmer.acme.com) = f067...85.  If elmer.acme.com is malicious, it cannot learn the secure session identifier or the session identifier for any other subdomain; it can learn the session identifier for its own subdomain, but that doesn't give Elmer any additional powers he didn't already have.
The only tricky bit is how to install these cookies onto the user's computer.  I don't think it is a good user experience to ask/expect users to log in again for each subdomain they visit.  Therefore, we should look for a technological solution that lets us transfer the session cookies across domains securely, without requiring the user to log in multiple times.
There are ways to achieve this, using iframes, postMessage, and/or redirection between domains.   For instance, here is one approach.  elmer.acme.com can have an invisible iframe that loads acme.com/authenticationhelper.  The latter can use the secure acme.com-session cookie to authenticate the user.  Meanwhile, the elmer.acme.com page can use postMessage to communicate to that iframe and ask it for a new session identifier that's good only for elmer.acme.com.  Once elmer.acme.com receives this new session identifier, it can automatically set a session ID cookie that's scoped to elmer.acme.com, and now you're good.  Here a key fact about postMessage is that the recipient of such a message can verify the domain that sent the message, which prevents spoofing and malicious attacks (acme.com can verify that it is elmer.acme.com who is requesting a subdomain-specific session identifier and respond with the appropriate session identifier for elmer.acme.com).
See the steps that Livejournal takes to protect its cookies, for an example of this sort of approach deployed in practice.  You can also read about the attack that prompted them to implement this defense, to learn about the risks of doing nothing to defend against these threats.


Is it possible to renew a certificate to allow end users to continue using the existing one, rather than having them implement the new one?

The expiration of a certificate is included in the certificate itself and not external to the certificate. Changing the expiration thus would require changes to the certificate itself. But a certificate cannot be changed since this would invalidate the signature on the certificate. Because of this there is no way to extend the validity time without creating a new certificate.

  ... service to our clients is uninterrupted and doesn't require any action on their part

With a typical PKI based validation of certificates no changes or action in the clients are needed to handle the new certificates. Even if clients use pinning this is not a problem as long as the client pins to the public key and not the certificate itself and the new certificate uses the same key as the old one.


How to share an emergency list with non-technical users so they can only open it in emergencies?

Search around for a digital dead man switch. You can build one yourself, and keep checking out on it every day or week to keep it from triggering.
With a cheap VPS (you can buy one for a dollar or less per month), you can have a simple service running that you write the rules, and what should be sent by email and to who.
So if 2 weeks passes without you checking in, login for the payment is sent. After a month, people are informed. And after an year, the request for deleting your data is sent.
You only have to be sure to not let the switch trigger before it was intended, and keep enough credits on the VPS account to outlive you at least one year. Renewing it for 2 years, and refunding it halfway would be enough.


I'm not sure how your keyboard hooking code works in the background, but first up, Mr Chen blogged about the problem of using PostMessage for this type of thing. As he says, if you want to send input that gets stuck into the keyboard queue, use SendInput.
For example, one way to capture keypresses is to use SetWindowsHookEx and write an event handler as part of a DLL loaded in via LoadLibrary. This will then receive all the keyboard input you feed the system, and is one way for example to implement global hotkeys (as in, for the whole system).
The problem with this mechanism is that if the hook takes too long to process that input, Windows boots it out and never passes any more messages to it. Charming. It turns out there's actually a Windows 7 bug where the OS chucks hooks out for no good reason, too.
Anyway, OK, back on to task. It is possible, as one explanation, that your keylogger isn't showing any measurable performance difference because it's not actually installed. This is worth verifying.
Secondly, however you hook, you're going to incur a performance penalty, whatever the marketing speak says. There's extra instructions being executed whichever way you cut it, since if you're using a driver, Windows is clattering through an extra device in the driver stack and if you're using SetWindowsHook, Windows is enumerating and calling an extra hook.
What might be going wrong is the measurement process. This is pretty hard to do, especially when you account for confounding factors like context switches, IO delay etc. Depending on how you attempt to measure input time, you might just be missing the difference.
It gets more technical than that too - for example, rtdsc doesn't work all that well with multi-core systems these days, so if you're using that, it might not work. You need the appropriate API function to get a decent resolution timer.
Another point to note is the presence of a debugger. If you've ever debugged an application under say Visual Studio, you'll be well aware as DLLs load, debugging symbols get loaded too, introducing massive delays. I'm sure you've realised this, but worth repeating.
Here's how I'd approach this:

Write a Windows application. Log WM_KEYPRESS messages - time and keypress.
Have a thread.
Have a button that triggers the thread to begin sending SendInput messages.
Run this process for a while - you need to get enough data to negate any confounding factors.
Stop.
Repeat with keylogger loaded in.

Needless to say, I'd load this on a physical, not virtual machine, with as little running as possible.
Will you see anything? Honestly, I don't know. It looks like some have tried using this and other metrics, but I'm not sufficiently privileged to be allowed to read papers that are the advancement of human knowledge and that my taxes might have contributed to. If you can, do let me know if it's any good!
Added detail a context switch may occur whenever you make an API call, but does not necessarily occur. For example, if you call an IO-related function and the API must block, your process will then be suspended and the scheduling algorithm run to determine if any waiting processes are either starved of time, or have IO messages they need to handle. Depending on this, you, or another process, might well be woken up and run. The process then repeats.
If a switch between processes is merited, this is comparatively expensive (on the minute scale that we'd be measuring here) then the current register state is saved, your process is mapped out and another is mapped in. This is clearly more expensive than jumping back to user land.
Another potential gotcha are interrupts. On Linux (not sure about Windows), interrupts preempt everything when allowed to run, so a call may take more time simply because during that time, the kernel handled more interrupts than the previous time.
Interrupts don't always (in fact, probably shouldn't need) to switch process context, but there may be more or less of them at any given point, depending on what the hardware is doing. More of them means more CPU cycles between call and completion of that call.


What vulnerabilities does a malware exploit?

There are two sort of malware analysis dynamic and static each has its own pros and cons. As you are trying to reverse engineer the malicious code you may require adequate machine language knowledge to analyze the code and identifying different routines. The second way is go with dynamic analysis by executing the code in the sandbox environment. There are few open source automated malware analysis tools like cukoo that can identify the threat data the malware is trying to exploit


how to configure edit-restricted mediawiki

Sorry for being the downer, some of MediaWiki's security pages are rife with warnings

"MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.
To help authors of security extensions, this list of the security flaws found in the field is being maintained, so that they can test their extension against each. There are several extensions that claim to give selective read/write access to pages in Category:Page specific user rights extensions, and currently most of these do exhibit several of the listed flaws."

I don't know if that affects your actions, but I remember seeing all sorts of warning when locking down my internal mediawiki.


From your description the problem doesn't sound like malicious activity, but rather the common issue of wireless interference that occurs when there are too many wireless networks in a given location. When the channel you are using is "busy," meaning another access point or client is transmitting, you must wait until the channel is clear again before you can transmit. This results in high and very variable ping times.

There are two potential solutions to this. The first is to check if you are using the 5Ghz band, assuming both your access point and your WiFi adapter support it. The 5Ghz band is generally less congested than the 2.4Ghz band and supports faster speeds, with the tradeoff being worse signal penetration through walls. You can use WiFi Analyzer tools on your phone or computer to check which band you are using.

The second solution is to switch to a wired connection, but you seem to have already ruled out that possibility. Wired connections will virtually always be faster and more reliable than wireless ones.


Company computer use from home - how much can they see on the desktop?

The tools are out there for a company to collect a great deal of information about how you use your work-supplied computer. There is software available that can record every keystroke, complete browsing history, even periodically take pictures with the webcam or sound from the microphone. Your company may not have this sort of thing installed, but it is good advice to assume that anything you do on that computer, or even within sight or hearing distance of that computer may be recorded.

In many cases the law isn't particularly clear about what information companies can use, historically companies own and have the rights to anything you do on their equipment, even if you weren't clocked in. People have been fired from their jobs and students have been expelled because of information on systems when they weren't at work or school.

In other words don't use your work PC for anything that you wouldn't want your employer to see or hear.


What is the purpose/role of the "alias" attribute in Java keystore files?

ALIAS

To answer your immediate question, the alias field should be a unique string to identify the key entry. This applies to all types such a trusted and intermediate.

Documentation

Keytool

  KeyStore Aliases

  All keystore entries (key and trusted certificate
  entries) are accessed via unique aliases.

  An alias is specified when you add an entity to the keystore using the
  -genseckey command to generate a secret key, -genkeypair command to generate a key pair (public and private key) or the -importcert
  command to add a certificate or certificate chain to the list of
  trusted certificates. Subsequent keytool commands must use this same
  alias to refer to the entity.

  For example, suppose you use the alias duke to generate a new
  public/private key pair and wrap the public key into a self-signed
  certificate (see Certificate Chains) via the following command:

  keytool -genkeypair -alias duke -keypass dukekeypasswd

  This specifies an initial password of "dukekeypasswd" required by subsequent
  commands to access the private key assocated with the alias duke. If
  you later want to change duke's private key password, you use a
  command like the following:

`keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass`

  This changes the password from "dukekeypasswd" to "newpass".

  Please note: A password should not actually be specified on a command line or
  in a script unless it is for testing purposes, or you are on a secure
  system. If you don't specify a required password option on a command
  line, you will be prompted for it

Standards and Practices

I don't think there is any set naming standard and I'm sure you can talk to 10 different people and get 10 different answers. You just want it unique and logical.

The API and Oracle's Keytool don't do a great job of checking for duplicates which is a particular oversight in my opinion considering it's used to identify each entry in a key store.

The best way to resolve duplicates is to generate a new keystore, and add each entry from the old keystore to the new one with unique alias'. You can iterate over the keystore and use its timestamp to identify different certs in a store.


Stealing SSL Session Id can cause any harm?

This is not risky.

The session is in ServerHello references a previously established TLS session which can be chosen to resume by the client.

This makes it possible to leave out otherwise repeated handshakes, but with just the session id, an attacker cannot do much.

Even if the attacker previously witnessed the handshake that is now skipped, they would know the configuration parameters (as they are the same) of the session - but not the ephemeral keys that got exchanged during the last handshake, as their transmission was secure in the first place (assuming that TLS was used in the right version and with the right configuration).

The misunderstanding might come from the multiple use of „session“: in TLS, there are sessions - and in HTTP(S), there are sessions as well, sometimes. The session id in the ServerHello is not an HTTP(S) session cookie, though. They are different things altogether.

A TLS session has nothing to do with the session you may know from “http session hijacking”.


airodump-ng station not associated with bssid

The second part of the listing is listing stations, a.k.a clients - computers and mobile phones that your chip captured either communicating with access points, or sending discovery beacons.

Your screenshot lists 4 clients, 4 of which are associated with ("connected to") XX:AC:D2:41:22:AC, which is the single access point you've been able to discover, while the last client (10:08:C1:2B:7E:XX) is not connected to anything at the moment - it either doesn't know the password for the access point, doesn't have enough signal to be able to connect to it or didn't connect to it for any other reason.

The last column, "probe", provides a hint as to why you were able to detect this station - while it isn't actively communicating with any AP, it was sending discovery beacons for a network called hXXXX, and your chip was able to capture that beacon.


You have essentially two issues in your process: providing the update and having it installed.

Server Auth

Firstly, yes you need to authenticate the server. This means that communication to the server must be done on a secure encrypted channel. Make sure to take the time to understand attacks on SSL so you don't use something that's expired. Ship the certificate with your app, and encrypt all the exchanges. Ship an extra public key for verifying signatures, different from the one used to secure the channel.

Update distribution architecture

Secondly, you must ensure that clients can trust what is being served to them. Assuming the worst, your server could indeed be compromised. You can take two steps to mitigate this. Firstly, ensure that the server used for updates is dedicated. Don't go running that API of yours on a Web server that hosts your personal blog. Run only the update API and think carefully about how you maintain this server and connect to it. Keep it updated. Have a penetration tester break it for you.

Secondly, (thanks @Steffen-Ullrich for reminding me of this) ensure that the server only distributes content that you have validated. When you publish a software release, you should sign your release tarball / binary with a private key (the one for which you shipped the public key) and release the signature along with the tarball. So your process involves uploading signature and binary to the update server and then clients retrieving it from the server. If your server is compromised, clients will no longer receive updates but at least they will not receive bogus / malicious executables.

Replacing the binary on the OS

Surprise surprise. This is 2016, you don't just replace executables system-wide on an OS without permission from the user. You'll have to drive your users through a UAC permission dialog every time you want to change the binary. This is of course going to be annoying for them.

If you expect your clients to absolutely need the latest update every time it's released (and assuming you can't get your app to install with a Integrity Level like browser vendors do), it might be more transparent and pleasant for your users to update your app via Microsoft's app store (saying 'might' as I've never shipped an app there and am unsure about that point).


Is XSS prevention only on the frontend enough for JSON services?

Yes, there's a possible attack: You someday change the frontend, and stop using JSON and start using something else. The XSS stored on the database kicks in and your users are attacked.

It is a very good practice to sanitize the user input as soon as possible. I always sanitize them as soon as it reaches my code.