How can I make sure password hashing is secure on computers while not being prohibitively slow on mobile devices?

jBcrypt is a Java implementation. Android apps are written in almost-Java, for an almost-Java virtual machine called Dalvik.

For computing-intensive tasks, especially cryptographic algorithms, Java incurs a typical 3x slowdown compared to equivalent optimized C code: a good Java virtual machine runs a JIT compiler, and the performance of the code will be limited by the constraints which a JVM must operate in (translation from bytecode to native code must be fast and incremental, methods being translated on a per-call basis; and the result must still be appropriate for the garbage collector). Further slowdown can be observed in some specific cases where native code can benefit from extra opcodes provided by the CPU, the typical case being computations on big integers (say, for RSA), because the CPU may offer an "extended" multiplication (64x64->128) that Java code cannot use, due to the lack of a 128-bit integer type in Java.

For a rather thorough experiment in the context of hash functions (not "password hashing", just "hashing"), see sphlib: a library implementing a lot of hash functions, in C and in Java, with "similar efforts at optimizations" (same developer for the whole lot), and including measures on a variety of platform types.

Now, there can be additional slowdowns for Android apps:

The CPU of a smartphone is not as fast as that of a PC. Smartphone CPU can go to the gigahertz range, but still do less work per cycle than x86 CPU -- because one of the prime objectives of a smartphone CPU is to save battery. A smartphone must be alive for a full day, while engaging in radio activity, whereas a laptop can have a bulkier battery and only needs to be up for a few hours. Modern smartphones are efficient, but there still is a gap when compared to desktop PC. Let's say an additional 3x factor.
Dalvik is not necessarily the best JIT compiler around. The relative lack of raw muscle means that the JIT cannot apply the most complex optimization strategies, because it would make JIT translation of a method too expensive.
Up to Android 2.1 (included), Dalvik has no JIT. This is the worst slowdown, that other answers allude to. In Android 2.1 (and before), Java bytecode is interpreted, not translated to native code, and this incurs a heavy extra cost (say 10 to 20 times slower than JIT code). Android 2.2 onwards has JIT.

Switching to PBKDF2 won't change the picture much. If you use PBKDF2, be sure to use SHA-256 (or SHA-1), not SHA-512, because the smartphone CPU is ARM-based and will be quite uncomfortable with 64-bit arithmetic operations that SHA-512 heavily relies upon, thus slowing down your code -- whereas the attacker has a PC, which eats 64-bit operations for breakfast, and will not incur the same slowdown.

Summary: bcrypt will be very slow on Android 2.1 (and previous versions). It will be somewhat fast on Android 2.2, albeit not as fast as a PC (say, between 5 and 10 times slower). PBKDF2, scrypt... do not change this picture in a significant way.

All of this is said about the performance of bcrypt. I did not comment in any way on the proper use of bcrypt-derived secrets for both encryption and password verification. Indeed, when you store "something" to validate a password, you don't what that "something" to be too close to the password-derived key you use for encryption.

One "cryptographically reasonable method" is to compute the password hash with bcrypt or PBKDF2 (with salts and iterations and everything), and then take the output and expand it with a Key Derivation Function into enough key material for your needs. In your context, take the bcrypt output, then hash it with SHA-256. This yields 256 bits. Store the first 128 bits in your database as "password verification token". Use the other half as encryption key.

PBKDF2 makes this process slightly simpler since it is a KDF, so you can ask for 256 bits of password-derived output right away, not needing an additional hashing; whereas bcrypt's output size is fixed to 192 bits, which may not be sufficient for your needs.


Is a SSL Certificate for a static IP Address a good idea

Main problem with a certificate for a static IP address is that it may very well not work at all. Relevant standards (RFC 2818, RFC 6125) only talk about DNS names, not IP addresses.

There are mostly two ways in which an IP address could be stored in a certificate's Subject Alt Name extension: either directly under its normal ASN.1 type (iPAddress, an OCTET STRING of length 4 or 16, depending on whether you are talking about IPv4 or IPv6), or as a dNSName by converting the address to its decimal-dotted representation (as in "1.2.3.4", a sequence of seven characters to encode a 4-byte IP address). I heard, but not verified myself, that some versions Internet Explorer would accept to match the second kind of representation as if it was a name, but not all browsers would do that. The iPAddress format is likely to be completely ignored by clients.

Usual commercial CA won't accept to encode IP addresses in certificates, in particular because they cannot guarantee that the IP address is yours and will remain yours, regardless of how strongly you believe it.


Strange escape codes in a GET request - is this a known attack?

The url encodes a Windows Codepage 1251 encoded string, containing (harmless) russian error messages. The transcoded url is:

/767/browser-wars-side-show-how-natty-handles-the-load/+++++++++[+Активация+]+Result: использован никнейм "azazalolxd"; вошли; не нашлось формы для отправки;

Google translator gives:

[ activation ] Result: used the nickname "azazalolxd"; included; can not find the form to send;

Its consistent with the usage of the russian Yandex browser that has this useragent.
Also see this question.


Bitmessage is a decentralized, encrypted, peer-to-peer, trustless communications protocol that can be used by one person to send encrypted messages to another person, or to multiple subscribers.

so using this you can use bitmessage email service anonymously

and here is the guide to use it
guide to setup bitmessage


Security requirements of storing ID numbers in database EU/USA?

Above all: every use of individual related data has to be reported if there isn't an explicit exception! So if the excel sheet contains names, addresses, telephone numbers etc. I would definitely talk to a legal expert. If there is no individual related data to be transferred, no additional rules apply.

If you are looking for laws regarding encryption (key length, algorithms,...)- i don't think the EU has clear regulations for the protection of data, other than the data has to be adequately protected. There is a FAQ to get an overview to the topic of data transfer.

If your customer has it's legal headquarters within the EU there are three different "data export categories" applying to him:

If he wants to transfer data within the EU or "EEA" no additional rules apply
If countries outside of that "community" are considered to adequately protect data, transfer should be no problem: list of countries
If the country to which the data should be exported doesn't fit one
of the above criterias, the company who is receiving the data has to assure an adequate level of protection. There are standard contractual clauses to make the report of the data transfer more easy: standard contractual clauses


Educational institutions are often required to obtain and maintain compliance and certification in numerous cybersecurity standards.  Maintaining a weak cipher suite or broken encryption may put them out of compliance, which could be uncovered on their next audit.

When I see "NT password" I get very worried-- Windows passwords can be cracked in about 13.6 seconds.  A sambaNTPassword is just an MD4 hash, which is a hashing algorithm that is horribly broken and has been for well over a decade.

That being said, these systems should be under occasional audit and will eventually get caught and addressed if possible (or a waiver and other mitigations will need to be put in place, e.g. a second factor of authentication that protects administrator accounts). So if you choose not to do anything, it doesn't mean they won't fix it...eventually.

If they are purposefully concealing this vulnerability during compliance audits,  this is not technically illegal, but they can lose their various certifications if they get caught, and open themselves up for civil liability if they get hacked.

As for this comment

  and our students are not so smart to understand that they can obtain and decrypt them

^ Is a ridiculous statement from someone who is forgetting that the younger generation bypasses their elders by several orders of magnitude when it comes to things like this.  This guy found vulnerabilities in the XBox at age five!!!!  (He now works for Microsoft security)

  however, please, keep this secret.

I would not agree to that, but be polite about it.  You should be clear that you are not willing to lie to cover someone else's mistakes.

  What would you do next?

Personally, I would treat this as a "teachable moment" (remember that you are still a student) and express that you would like to learn more.  See if you can arrange a meeting with one of the university's cybersecurity compliance officers-- these are the folks that sign the forms that swear and affirm that they are maintaining compliance, and who regularly work with auditors.  Once you bring it to his or her attention, you can safely say you did everything you could do, and it will be their job to take it from there.


This is typical of a handshake that supports a minimum version that is lower than its preferred/maximum version.

In this case, the client is using a TLS v1.0 ClientHello Record, indicating minimum support for TLS v1.0, but inside the record is indicating support and preference for TLS v1.2

Using that technique, clients and servers can negotiate the best possible version that both share.


Fail to understand how hash length extension might work in real application

A length extension attack can be performed on the Merkle–Damgård construction (MD) based hash functions (MD5,SHA1,SHA2,...). The trimmed versions of SHA2 series like SHA512-256 or HAIFA ( extension to MD) based hash functions like Blake(2(b)), or the SHA3 are immune to length extension attack.
To be useful the attack needs the data (known_data). The first real attack was on the Flicker API over MD5 on Sep. 28, 2009. Actually, It is more than that, it is signature forge.
Given a hash value h with the secret_key the signature is calculated as;
   `h = MD5(IV,secret_key ∥ known_data ∥ pad1)`

one can form a new message without knowing the secret_key. If there is no secret_key, then there is no problem, just compute the hash of any data you want and the server will accept.
Now, the attacker takes the message and the signature to forge this
h' = MD5(IV,secret_key ∥ known_data ∥ pad1 ∥ appended_data ∥ pad2)
here the new message is m' = known_data ∥ pad1 ∥ appended_data
The pad1 and pad2 are the MD5 function padding.
They can execute the extension as;
MD5(h,appended_data∥pad2)
In other words, one just needs the change the initial values of the MD5 with the h. Now, one can send this to the server with the message by the server's protocol, and the server will accept it. As shown, the attacker doesn't need the secret_key at all to execute this attack.
The attack worked since the secret_key is in the beginning. Today we have better constructions like HMAC which is immune to the length extension attacks. HMAC is expensive since two calls of the hash function. With SHA3 we have a new one KMAC that has a more simple design and easier proof of security.
update per comment:

I don't get how applications validate hash signature, as hash are only one way and can't be decoded

To validate the signature it will use the canonical verification, the application, take the received new message m  and hash it with the secret_key and check the equality with the received h. They are fooled since they considered that the secret_key is enough for this signature scheme.


php crypt - trailing dollar sign - extract only the salt part from hash - padding the salt

The 22 characters it requires are actually encoded binary data that is used for the salt. Bcrypt/Blowfish/$2y$ only uses the first 128 bits of your 132 bits, so the last four bits are totally ignored and should not be a dollar sign because that is not a valid character for the modified base64 encoding that is used for the salt. What has happened is you specified too short a salt, so it was padded with $ so the system knows the salt has ended. The reason it ends up being a . is because since only the first four bits are used, the last four are padded with zeroes before the beginning of the encoded hash. A . is all zeroes in this base64 type encoding and because there's no previous value to affect the first four bits of the 22nd character, you end up with just the .. As an aside it does make me wonder why they chose to use dollars instead of . to represent the missing salt - perhaps just to differentiate between actually asking for zeros in the salt and the automatic decision to pad with them.

$pass = 'secret';
echo crypt($pass, '$2y$07$notlongenough'), "\n";
echo crypt($pass, '$2y$07$longenoughsortof......');

> $2y$07$notlongenough$$$$$$$$.uYiNG9WczQSWgnuPdcNj0jugGbSnaAC
> $2y$07$longenoughsortof......9dPQFbAgDCQ4RWEcZ4/ficmGapMNSpC

It only makes sense to provide one of: ., O, e, or u for the last character of the salt because these are the only characters in the encoding set that actually affect the first four bits. FYI the full range is [./A-Za-z0-9] in that order, so if you number them 0-63 and look at the binary expression of those numbers you'll see where those four characters come from.

The examples seems to erroneously use trailing dollars. They are not needed and indeed shouldn't really be present. All you need to do is provide enough bits for the salt depending on the algorithm you're using. Every character should be as random as possible up until enough bits have been provided (i.e. a minimum of 22 characters for Blowfish/$2y$).

The output is then a concatenation of: algo-description, salt used and hashed result/password. The algorithm knows the binary boundaries of where the salt ends and the hashed string begins. There should not be any dollar signs with $2y$ because you should have provided a long enough salt string which will not consist of any dollar signs (again, because that is not in the valid character range for the utilised modified base64 encoding).

This should be enough information for you to extract the salt if you so desire. But PHP actually recommends the use of password_hash, as do I if you have v >=5.5.0 http://in1.php.net/manual/en/function.password-hash.php.

This will automatically generate a secure random salt for you using either /dev/urandom or  CryptGenRandom() on Windows - both well vetted to be sufficient for this purpose. If you've already started using crypt, password_hash is compatible so fear not about upgrading to use it.


How danger to install APk from outside google play?

When installing apps from the Google Play Store, you're fairly safe since apps are verified by Google before being made available. Google also has a feature called Google Play Protect, which scans your device for malicious apps, including third party apps, and malicious activity.

Of course, there are a few exceptions to this rule, like the recent indicident where hundreds of malicious apps infected the Google Play Store.

When installing an app directly from the APK, there is a higher risk of the APK containing malware since you give Android permission to install any third party application. Some things to consider to make sure the APK is safe:

VirusTotal

Upload the APK to VirusTotal and scan it for issues including malware.

NViso ApkScan

Scan the APK with NViso ApkScan and get a detailed report of the file.

Decompile Java

Decompile the Java source code and examine exactly what it's doing. There's a guide on how you can do this here.

Permissions

Look at the permissions the app is asking for and determine whether they look suspicious. Here are some permissions which may raise suspicions (taken from here):

READ_CALENDAR
WRITE_CALENDAR
CAMERA
READ_CONTACTS
WRITE_CONTACTS
GET_ACCOUNTS
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
RECORD_AUDIO
READ_PHONE_STATE
CALL_PHONE
READ_CALL_LOG
WRITE_CALL_LOG
ADD_VOICEMAIL
USE_SIP
PROCESS_OUTGOING_CALLS
BODY_SENSORS
SEND_SMS
RECEIVE_SMS
READ_SMS
RECEIVE_WAP_PUSH
RECEIVE_MMS
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE

See more on permissions here.

App Signature

Make sure the app signature is valid. There's already an answer on Stack Exchange which explains how to make sure the signature is valid.

Avoid Third Parties

Don't install apps from third parties at all. It's much safer to get apps from genuine sources like Google Play Store where the apps are already scanned.

Available Updates

If there is a version of the app on the Play Store, after installing the APK you can check the app on the Play Store and if there is an option to update the app due to the APK being old, this would suggest that the APK is genuine.


Folded TLS as a protection from root cert issuer vulnerability

... if the traffic is double-encrypted: with two certs from two independent issuers (or more).

The traffic is not encrypted with the certificates. The certificates are mainly used for authentication, i.e. to verify that the client is talking to the correct server. The key pair of the leaf certificates is also used inside the RSA key exchange but not with DHE or ECDHE key exchange.

While double TLS like you proposed would be a way to not rely too much on a single CA it would need to be supported by all clients. But, since the encryption itself is not the problem but authentication is it would be much better and less overhead to make the authentication part only less dependent on a single CA. And this is the direction  where improvements are done in browsers today. While it is not possible to directly sign the same certificate by multiple CA one can use certificate transparency or projects like Convergence for an extended validation of the certificate. There are also standards like DANE as replacement of the current PKI or for additional validation and certificate pinning also helps in this regard.


Deep packet inspection (DPI) can recognize SSH handshakes and block them, but that doesn't gain you anything. A competent attacker would just use TLS instead, for example via reverse tunneling through openssl client or the more advanced flavors of netcat. It's not possible for even DPI to tell the difference between one of those (if configured to act exactly like a browser, in terms of cipher suites and so on) and an actual browser making an HTTPS connection; the TLS handshake looks exactly the same. An attacker could also run a TLS-based VPN such as OpenVPN and then tunnel anything at all through that.
Also, a fully reverse tunneled shell isn't actually needed. An attacker can remote control a shell script via curl or similar, or even receive commands and exfiltrate data through DNS requests or similar (which you have to allow out; even if your workstations can't make them to the outside directly, it can make them to your gateway which will relay the request and the response).
Blocking SSH is also awkward for a number of other things. Git can use HTTPS, but then you need to do password auth and it gets messy with MFA; SSH with public key auth is more secure but then you might have to allow SSH connections to GitHub or similar. SSH is the standard way to administer remote Linux servers in the cloud, and is becoming increasingly common for Windows servers too. SSH is also used "under the covers" for some other software and protocols.
At the end of the day, blocking SSH is a speed bump to a competent attacker, who - having already dropped and executed some payload on a host inside your network - does not actually need another way to gain code execution on internal hosts. Nor does it prevent exfiltration at all.


Does setting a WiFi AP to channel 14 avoid the most common detection methods used in Europe or the Americas?

Usually within the U.S., special-ordered equipment is required to scan channels not permitted for operation by the FCC.  This could be WiFi devices imported from overseas, or specially-licensed equipment manufactured specifically for spectrum analysis.

Since consumer electronic devices (including Wi-Fi) sold within the U.S. must conform to FCC Part 15 regulations, which do not permit operation in certain channels, I'm fairly confident hardware manufacturers have taken every measure to ensure that their devices are literally incapable of operating (transmitting or receiving) on those frequencies.  At the very least, I expect specialized firmware hacks would be required to work around those measures.  On the higher end, it's entirely conceivable that the device has been physically engineered so that it cannot work on those frequencies regardless of what it's told to do.

It should be noted however that:

As already stated, unlicensed operation in channels 12-14 on the 2.4 GHz band (as well as a number of channels in 5 GHz) is illegal in the U.S..  One may be subject to fine by the FCC if caught in violation.
Operating in such frequencies where not allowed by law is not a real security measure.  It is simply another form of "security by obscurity".  If an attacker has knowledge that a network is using illegal frequencies, or has equipment that can detect and connect to networks operating in those frequencies, that network is as vulnerable to the attacker as any network that is operating legally.


Is ssh tunneling to remote server Php admin secure?

Would this be sufficent in terms of being able to securly access
  PHPMYAdmin and upload files or should I be using SSL aswell?

I am guessing you are talking about Secure socket tunneling to run the localhost on the remote server as given here.

The secure socket tunneling protocol already does SSL/TLS provides transport-level security with key negotiation, encryption and traffic integrity checking.wiki
That should be sufficient.


Scapy: Sending forged Probe Requests and capturing them in a different device

It appears the code you are using doesn't check or set the wireless channel for either transmitter or receiver. If they are not on the same channel, they cannot communicate.

Since you have success some of the time, there could be other daemons that are hopping channels (e.g. scanning for available networks). For your code to work, you will need to kill other daemons that are using your wireless card, and force the channel with:

iw dev <interface_name> set channel <channel>

The airmon-ng utility can print out processes that may be using your wireless card.


Getting a suspicious error in apache error.log (DJANGO)

Assuming that your site is not kyortisdzheykob.ru then somebody is sending a HTTP request to your site where the Host header does not match your site, i.e. trying if your site will answer to a request for http://kyortisdzheykob.ru/ even if your site is actually http://example.com.

A web site should only accept requests for the actually intended domains and should reject any other requests. Failing to do this means that it is vulnerable for attacks like DNS rebinding and depending on the configuration of the site maybe even for more attacks like being used as a proxy to access internal resources.

It looks like that your web server is configured to accept such request which is bad. Fortunately your Django application behind the web server has an additional protection against this misconfiguration in the form of the ALLOWED_HOSTS option and fortunately this options seems to have been set to sane values instead of allowing everything. This means that you don't have to worry for now about the log entry you see: it is only showing that Django successfully blocked a request which was wrong.

But you should better also fix the problem at your web server. How this is exactly done depends on your specific server. But it usually can be done by having virtual hosts for the specific domains the server should be for and then have a default configuration for everything else which simply rejects the request.


Why is OAuth2/OpenID Connect considered less secure than SAML/WS-*?

tl;dr

Most security issues are with implementation and not protocol, the
simpler the better.
SAML/WS-Federation and OpenID Connect all use
cryptographically signed tokens that support optional encryption
SAML/WS-Fed is XML based  and takes on the XML threat model while
OpenID Connect is JSON based {} and takes on the OAuth2 threat model
OpenID Connect provides the authentication layer for OAuth2 and
addresses some of the most important security gaps with OAuth2
OpenID Connect when properly implemented and used can be just as secure and
SAML/WS-Fed OpenID Connect is a "modern" protocol and well suited for
newer use case such as devices and native mobile apps.

SAML is a protocol for flows like Web SSO as well as a format for an XML based token (assertion) that is protected via a XML Digital Signature (XML DSIG) and optionally XML encryption (XML ENC).  The protocol supports several bindings including SOAP and HTTP (redirect/post)

WS-Federation is a lot more complex in that its actually based on a large set of WS-* standards such as WS-Trust & WS-security that are SOAP based.  WS-Federation is agnostic to the token format as it was designed to be a protocol to negotiate tokens (aka Security Token Service).  It's common to use SAML format tokens with WS-Federation, but you could technically also use something like a custom token or even a JWT!  There is also a "passive" flow for browser based scenarios that is very similar to HTTP redirect binding for the SAML Authentication Request Protocol

OAuth2 is NOT and authentication protocol but rather an authorization delegation protocol.  It defines a set of flows (grant types) to obtain tokens but doesn't define the format of a token.  Different flows are specified to accommodate the needs of different applications (clients in OAuth) such as a browser, a background server daemon application, or a native mobile app.

OpenID Connect is built on-top of OAuth2 and provides the authentication layer.  It adds a new token to OAuth (id_token) that is JWT based and set of mandatory params and claims for the protocol and token (assertion).  OpenID Connect was designed to be the "modern authentication" answer to most of the SAML/WS-Fed use cases without the XML & SOAP based overhead for modern apps such as native mobile apps and devices.

When comparing SAML/WS-Fed to OpenID Connect (remember vanilla OAuth2 is NOT an authentication protocol), we need to consider the security of the protocol and security of the token (assertion) but also the software "implementation" of both.  More complexity to specifications often leads to more developer bugs!

SAML has common XML threats (www.owasp.org/index.php/SAML_Security_Cheat_Sheet) and puts a lot of complexity on both the IdP and SP to get right from as security perspective.  SAML for Web SSO with HTTP binding (most common) depends on TLS for transport security to ensure the token is not intercepted.  SAML Assertions are commonly issued as a "Bearer Token" which means that there is not way to bind the issued token to the client that presents the token.  If you have the assertion that you are presumed to be the subject of the token. The Identity Provider (IdP) acts as the Authentication Service and issues a SAML assertions (token) that is returned to the pre-configured destination known as the service provider (SP).

The request/response messages can use HTTP redirects or Form POST depending on IdP/SP configuration. A successful response form the IdP contains a protocol envelope message with metadata and an assertion (token).  The response and/or the assertion needs to digitally signed with XML DSIG by the IdP using it's private key and optionally encrypted with the SP's public key.

The request/response protocol is very minimal but its important to note that the actual user authentication happens over the browser typically with HTML/JS and is not defined the protocol (yes there is a binding that can use HTTP Basic Auth but its not really used in most deployments).  The requesting application is typically not authenticated so the most significant threat from a protocol perspective is to ensure that the IdP only delivers the response to the configured SP and not an attacker.  SAML Assertions are commonly issued as a "Bearer Token" which means that there is not way to bind the issued token to the client that presents the token.  If you have the assertion that you are presumed to be the subject of the token.  The location where the assertion is delivered via redirect or POST URL is typically whitelisted in the IdP to ensure that it can only be delivered to "trusted locations" (assuming you trust DNS, TLS, CA's, and your browser!).

WS-Federation as mentioned before is a lot more complex.  The active RPC-like SOAP protocol can optionally use any number of features from the wS-* stack such as message or transport security and bearer or proof-of-possession tokens (where the party presenting the token must cryptographically prove they are the subject of the token).  The passive flow is similar to SAML from a security perspective.

Most security issues with SAML/WS-Federation have to deal with the dependency on XML and XML Security (signature & encryption).  These are very complicated technologies to get right and most developers only test happy path scenarios.  There are so many ways one can implement  parsing and  data validation that leaves room for an attacker to exploit.  A common attack is XML signature wrapping (www.ws-attacks.org/XML_Signature_Wrapping).

OpenID Connect (OIDC) is based on OAuth2 and takes on most of the well documented OAuth 2.0 Threat Model and Security Considerations (rfc6819).  There has also been a recent Comprehensive Formal Security Analysis of OAuth 2.0 (https://arxiv.org/abs/1601.01229).  OIDC adds an additional security layer to OAuth2 by returning a signed JWT token to the requesting application called the id token (https://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/).  Just like SAML with HTTP binding it also relies on TLS for transport security and takes on the typical DNS, TLS, CA's threat model. JWTs can be signed with shared secret or public/private key HMAC and optionally encrypted.  The JSON Web Signature (rfc7515) and Encryption (rfc7516) are a lot more simple than their XML DSIG/ENC counterparts which hopefully means more secure implementations but there have been known issues with common libraries (www.chosenplaintext.ca/2015/03/31/jwt-algorithm-confusion.html).    OAuth2 requires on client registration which provides identity for the requesting application which  can be public or confidential and require client authentication.  User authentication is performed over the browser just like SAML.

There is a lot more inputs to validate with OAuth2 than there is with SAML!  Most common issues deal with input validation and binding request/response params to the client.   There has  been a lot of recent work in the  OAuth working group to define best practices for native apps (draft-ietf-oauth-native-apps-06).  There is a recent draft in OAuth2 working group to identify additional open security topics (draft-lodderstedt-oauth-security-topics-00).


Since some years, all of the Skype communication happens through their servers and not directly.

There is no IP to hide (encrypt) because your Skype client doesn't know the IP of your pals.


Why is the 2nd step in two-step authentication not a single click?

If two or more people try accessing the same account at the same time, and only one of those users is legitimate, it wouldn't be possible for the app to know which sign in attempt it should verify, without the user identifying their particular attempt in some way.

As such it makes sense for the user to apply a code directly to their session. Also notable is that the codes are generated offline, based on a secret and device time. Using an "It's me" button would require an intermediary server through which the web app and the mobile app confirm the authentication request. This adds expense to the app, and introduces dependencies, a point of failure and potential point of vulnerability.

  @Scott if someone is able to fake a "it's me" notification, that means he have stolen the original secret. He might as well still the your MFA code

Imagine you are signing into your Google account, and a hacker is also attempting to sign in to your Google account. Both of you are at the MFA stage. Only you have the MFA device.

You press your "It's me" button to authenticate ... Which of the 2 pending sessions does that authenticate? The "It's me" idea then only works if you select the correct session. In which case a code is simpler and safer.

  In any case, the "that's me" notification can be a response to a challenge sent by the authentication server on your session. In which case you will be notified if an attacker attempted to log in. Any idea why that wouldn't work?

I can see what you are getting at with the device being notified of the attempt, and then you just confirm it with the app. It's not an unfeasible design. I guess ultimately it comes down to pros and cons:

Your suggested method:

Intermediate server(s) required. To send notifications, to authenticate devices and session
Servers require maintenance, cost money to run, can themselves be hacked, can fail / or be unreachable.
The web app requires to talk to the MFA verification server.
Only works online.
Potentially more security holes and complexity.

The current code method:

Free
Works offline
No servers required
Open standard


I don't think you're going to come up with a numeric probability value, here. But there are in fact several places where passwords get cached temporarily when they're used. The chances are higher if you use the same password in multiple places, and many tools for this purpose also scan the drive for anywhere you might have a copy fo the password stored somewhere -- such as saved credentials, Word documents, email conversations, etc. All of this automated, of course. If you have the person's computer in your posession, your chances of retrieving their password is significantly higher than if you don't.


Can a custom return path make SPF redundant

When we're talking about "From" in regards to email, it can refer to two things:

The "From: " header
The "Envelope From" that is exchanged between email servers directly when establishing a connection.
They don't have to be the same.

When your client connects to the server to send email, here's a simplified exchange between them:

client: HELO client.example.com
server: Hello, client.example.com, nice to meet you
client: MAIL FROM: <bjones@example.com>
server: Okay
client: RCPT TO: <csmith@example.com>
server: Okay, go ahead with the message, terminate with a single '.'
client:
From: Junie B. Jones <bjones@example.com>
Subject: Important discussion

Hello, Claire...
...blah...
...blah...
.
server: Okay, accepted for delivery

You'll see above that the "From" showed up twice: first time as part of MAIL FROM, and the second time as From: in the body of the message. Only the first one (called "Envelope From" or "Return Path") is important as far as mail servers are concerned -- the second one is mostly for looks. In fact, it can be missing entirely.

What Intercom is saying is that when they send a message, they will send it like this:

client: HELO foo.intercom.com
server: Hello, foo.intercom.com, nice to meet you
client: MAIL FROM: <someaddr@intercom.com> # <-- envelope-from
server: OK
client: RCPT TO: <somedestination@example.com>
server: OK, proceed, terminate with a single "."
client:
From: Junie B. Jones <bjones@example.com> # <-- cosmetic "From:"
Subject: Mailing from intercom

...blah...
...blah...
.
server: OK, accepted for delivery

Many mail clients will show this as "Junie B. Jones <bjones@example.com> via foo.intercom.com" when displaying the email, to indicate the discrepancy between the Envelope-From and the cosmetic From, but it's considered a kosher practice when it comes to email.

SPF specifically only deals with Envelope-From, and ignores the cosmetic "From:" field:

http://www.openspf.org/FAQ/Envelope_from_scope


This depends how you do the integration with the payment processor. Let's pretend for a minute you are a merchant - then the correct SAQs would most probably be SAQ A or SAQ A-EP depending on the integration / re-direct / IFRAME / JScript.

As a service provider you can't complete A or A-EP but you must complete D or undertake a full Report on Compliance. What you need to do is follow the guidance contained in these FAQs about basing an full PCI DSS assessment on a reduced set of requirements contained in one of the other SAQs.

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-a-partial-PCI-DSS-assessment-be-documented-in-a-Report-on-Compliance-ROC

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-SAQ-eligibility-criteria-be-used-for-determining-applicability-of-PCI-DSS-requirements-for-onsite-assessments

I know you asked about SAQ D and not an onsite assessment but the principles outlined in these FAQs are the same for a Service Provider SAQ D.

To answer the question about what the CDE is for SAQ A and SAQ A-EP there's another FAQ you might find helpful.

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-PCI-DSS-Requirements-2-and-8-apply-to-SAQ-A-merchants

It's basically anything that can directly affect the integrity of the redirection.


Firewall with packet capture and inspection?

You probably won't find it for desktop firewalls. That feature requires a much higher level of network knowledge than most users have/are willing to study.

Therefore, firewall companies won't put much effort developing something like this.

On the other hand, professional network appliances tend to be more inclined in that direction. I know that the Palo Alto Firewalls have some tools for capturing and analyzing traffic "wireshark style".


Why does IP address need to be listed as a DNS name in SAN/UCC certs?

Why do CSR utilities give you the option to list an IP as an IP if this does not work?

I don't know which CSR utilities you refer too, but some of them target people who know what they do. Certificates are not restricted to browsers and the rules how they get used differ in other contexts. Especially the often used openssl is a tool which is able to create CSRs which are valid, but maybe not valid in the context of browsers. Thus it is definitely a tool for professionals who know the relevant standards and not for newbies.


Veracrypt - Encrypted USB Partition - Does it Pass the Key Over USB?

I'm not quite sure what you mean with "does the key it get passed over USB". I'm assuming that you're asking whether the volume encryption key gets passed from your external USB storage device to your CPU, or vice versa.

The answer to that question is yes.

The reason for this is that your passphrase which you use to unlock the volume is not actually the encryption key for the data. The encryption key is stored on the volume, but it is encrypted with your passphrase (after it undergoes key stretching etc).

This is why you can change your passphrase without re-encrypting the whole volume - you basically just re-encrypt the encryption key with your new passphrase.

So, if you think about it, since the actual encryption key is stored in the VeraCrypt volume header, and the volume header is sitting on the USB storage device, obviously there must be a moment when the encryption key - in encrypted form - is moved from the USB storage device to the CPU.

I don't see a security problem with this, though.

OTOH, if you were asking whether your passphrase to unlock the volume gets passed to the USB storage device, then I'd agree with Thomas that no, it isn't passed.


How does Zeus (and other malware) inject code into other processes

I don't know about Zeus in particular, but generally speaking, it's easy to do this using debug APIs like VirtualProtectEx and WriteProcessMemory. Open a HANDLE to the target process, add some executable memory (with VirtualAllocEx), put some malicious code in there, re-map the virtual address of the executable code of the library that holds your target API as RWX, overwrite the first few bytes of the function you want to hook with a jump instruction that goes to your injected malicious code, and you control everything that function does.

There are plenty of other ways to achieve similar results; the use of the debug APIs and overwriting the entry points of real functions is just one example I've seen in the real world. The malicious program can do this each time the debuggee (victim) loads a new library, including all the ones loaded at process initialization, before the victim's main() even executes.

DLL injection (which can do the hooking from within the process, no need to do anything inter-process at all) and compatibility shims (like are used for running programs in "compatibility mode" for older OS versions, and replace system APIs with different code) are two other handy options.


IPhone iOS 8.3 encryption security against physical access

The purpose of Effaceable Storage is really to be able to quickly erase everything on the device, not to provide any confidentiality for your data. It works like this: Effaceable Storage stores a key (which is itself is encrypted with device-specific key) that is used to encrypt device's filesystem. When device needs to wipe itself (e.g. due to remote wipe command) it simply erases that key from Effaceable Storage. Data on the filesystem remains untouched, but because it's encrypted using the key that was stored in Effaceable Storage (but not anymore), that filesystem data effectively became cryptographically inaccessible.

  Does this mean that the system encryption is useless against
  forensics? Or is it only vulnerable when it's locked and not turned
  off?

Yes and no. Yes in the sense that protection provided by Effaceable Storage is useless against forensics (unless we're considering the possibility that remote wipe command can reach device while it's already in custody). No in the sense that there are additional layers of protection/encryption above that filesystem encryption, and those can be (and are) a considerable obstacle for forensics.

  SO, can someone confirm that a locked Iphone 4s iOS 8.3 cannot be
  cracked in the case of no access to lockdown certificate?

If that iPhone 4s is not jailbroken then there is no public tools that can get into it. Nobody can confirm that device cannot be "cracked" because, if nothing else, Apple can create a signed ramdisk that will obtain at least some of the data (that isn't protected by layers of encryption above Effaceable Storage, so to speak).

MDM scenario is only relevant if that device is enrolled with some MDM. Basically, in this case MDM has a "lockdown certificate" that can be used to access and decrypt data on the device, change passcode, etc.

Hope this helps.

UPDATE:

Powered down device is at least as secure as a powered up one. What really matters for iOS devices though is if the passcode has been entered at least once since device boot.

If it has been then number of encryption keys will remain in device memory but without a pairing record (aka 'lockdown certificate') or a jailbreak there's no way to exploit this AFAIK.

As for sources, this slides and this project are an excellent source of information on the subject.


Drive-by downlad VS buffer and stack overflow attacks

"Drive-by-download" refers to the behaviour of the malware: it will (attempt to) infect the user during normal interaction with a web page.

Buffer and stack overflow, on the other hand, are two technics used to attack a vulnerable application. They are not limited to the web in any way. (any software that takes some form of input - i.e. all software - is potentially vulnerable).

So a malware might spread through drive-by-download by leveraging a stack overflow in a vulnerable component.


How does a root kit work inside a virtual machine?

As stated above, root kits work similar on a virtual host as they do on a normal host EXCEPT that many malware/virus/rootkit authors have developed mechanisms to detect whether or not they are in a virtual machine, so they can be scripted/programmed to behave differently than they would on a normal machine.

This is highly evident when reverse engineering malware, where malware will behave different if it detects it is virtualized. Some of the behavior may be to stop from doing its normal routines/functions, try to delete itself. This is similar to malware checking to see if a host is running reverse engineering tools, e.g., IDA Pro, OllyDBG, Immunity Debugger, Redline, etc.

VMWare has an "antirootkit" approach to certain things since the vmware agent will monitor things like changes to the SSDT and IDT (system service descriptor table, and interrupt descriptor tables). At the end of the day though, the behavior is MOSTLY the same.


Why don't browsers check CAA records to help ensure a certificate is valid?

I just found the answer in RFC 6844, DNS Certification Authority Authorization (CAA) Resource Record:

  A set of CAA records describes only current grants of authority to
     issue certificates for the corresponding DNS domain.  Since a
     certificate is typically valid for at least a year, it is possible
     that a certificate that is not conformant with the CAA records
     currently published was conformant with the CAA records published at
     the time that the certificate was issued.  Relying Applications MUST
     NOT use CAA records as part of certificate validation. [emphasis mine]

Basically, it is not the purpose of CAA to describe which certificates are currently valid for a domain. If a certificate is issued when the CA is on the record, and the record is later removed, then the certificate should remain valid until it expires (or is revoked).

Validation of certificates in the browser (or Relying Application) through DNS appears to be the purpose of DANE, or DNS-Based Authentication of Named Entities, specified in RFC 6698. Unfortunately, DANE is not widely implemented.


Is using HMAC to transmit a password OK?

Besides being a self-invented scheme, I see at least the following problems with your proposal:

There is no binding with the actual data. When you authenticate a user, you do not want to really authenticate "the user" only; you want to authenticate a session, i.e. make sure that what will follow on the link will be guaranteed to be from that user, and what you will send on the link will be seen only by the intended user. An active attacker can hijack the connection, and even a passive eavesdropper can spy on whatever you will send afterwards.
The scheme is vulnerable to offline dictionary attacks. Passwords are weak because they fit in human brains, and human brains are not overly good at remembering long passwords (and human users lack patience to type long passwords). It is a losing battle: computers regularly gain more power, but not humans. Trying out potential passwords tends to be a successful attack, and observing your scheme yields enough information to try passwords (the attacker just has to compute a single HMAC per guessed password, and see if it matches what was observed). Such attacks can be mitigated to a great extent by employing a slow derivation process (e.g. bcrypt) but a single HMAC will just not be enough. It is still a bad idea to even allow for an offline dictionary attack.
The server will have to store some information which is enough for a user to authenticate. This means that an attacker gaining temporary read access to the server's storage (e.g. a database dump through some SQL injection) may obtain passwords (or password-equivalent data) allowing him to impersonate users at very little cost. Better password schemes store on the server enough data to verify a password, but no more.

Making a proper, secure, authenticated medium for data transfer is not an easy task. If you really need to reimplement something yourself instead of using some SSL/TLS library, then do yourself a favor and implement a standard protocol for that, e.g. SSL/TLS. If you have qualms about certificate, consider TLS with SRP (no certificate at all, mutual client-server password-based authentication, not vulnerable to offline dictionary attacks).

Edit: about your clarification in your own edit: using the secret data (the password) as the key in HMAC, and the publicly known data (the challenge) as the data in HMAC, is theoretically much better than the reverse (HMAC was designed for the key to be secret); in practice, given the structure of HMAC, it would probably not much change security. Yet my points exposed above still apply.


Simplest way of hashing a password with multiple different hash algorithms

On most UNIXoid operating systems, the openssl command line program should be available. It implements most of the hashes you mention. To use it just for hashing, pipe the output of echo -n to openssl dgst -[ALGORITHM]. To calculate the SHA1 hashsum of "Hello World", for example, use this:

 echo -n "Hello World" | openssl dgst -sha1

openssl dgst supports the following algorithms: md5, md4, md2, sha1, sha, mdc2, ripemd160 .


PCI Compliance - If am eligible to self certify - do I need to use a QSA company in this context?

No, the point of the self-questionairre is that you don't need a QSA.
On the other hand, you might want some assistance or guidance, to verify that you complete it correctly - you still may be subject to an audit, and you'd be worse off after filling it out incorrectly.

Also, you'll still need an ASV (authorized scanning vendor) to run your quarterly scans.


Using LetsEncrypt certificates for WiFi network authentication

Is it even possible to "recycle" my valid personal certificate to be used in the RADIUS server?

A certificate is valid only for the domains listed in the certificate. Since your private domain is likely not the domain of the radius server you cannot reuse your certificate there. Apart from that it is a bad idea to give your secret key to the school, since this is what you would need to do in order to use your existing certificate on their radius server. But see  Use Let’s Encrypt Certificates with FreeRADIUS how you could proceed.


How can waiting 24 hours to change the password again be secure?

By itself, the rule of only allowing one password change per day adds no security. But it often comes in addition to another rule that says that the new password must be different from the n (generally 2 or 3) previous ones.

The one change per day rule is an attempt to avoid this trivial perversion:

a user has to change his password because it has reached its time limit
he changes it to a new password
he repeats the change immediately the number of saved passwords minus one
he changes it immediately back to the original one => hurrah, still same password which is clearly what the first rule was trying to prevent...

Ok, the rule could be the changing the password many times in one single day does not roll  the last passwords list. But unfortunately the former is builtin in many systems while the latter is not...

Said differently, it is just one attempt to force non cooperative users to change their password on a timely manner.

Just a trivial probabilistic analysis after comments saying that allowing users to never change their password is not a security problem. Say you have a rather serious user and that the risk for his password to be compromised in one day is 1%. Assuming about 20 work days a month, the risk of being compromised in a quarter is of about 50% (1-(1- 1/100)^60)). And after one year (200 work days) we reach 87%! Ok, 1% may be high, and just start at 0.1% per day, only one on 1000, pretty negligible isn't it? But after 1 year (200 work days) the risk of begin compromised is almost 20% (18% to be honest). If it is the password for holidays photos I would not care, but for something more important it does matter.

It means that what is essential is to educate users and have them accept the rules because we all know that rules can easily be by-passed, and that if a user does not agree with them it will not be cooperative. But asking users to regularly change their password is a basic security rule, because passwords can be compromised without the user noticing that, and the only mitigation way is to change the (likely compromised) password.


Pseudo Random Generator is not initialized from the (entropy pool)?

/dev/urandom will always try and return the most random value it can.  In the worst case,  it will use cryptography to "stretch" the last bits of entropy in the pool to fill your request.  By contrast /dev/random will block until the entropy pool is full enough to fill the requested bytes,  so /dev/random will guarantee a more random value.  However /dev/random will block until the entropy store is large enough to fill the requested bytes,  which is unacceptable in almost all uses.  If the entropy pool is full,  then /dev/urandom and /dev/random are identical.

When rc.sysinit shuts down  it copies 512 bytes from /dev/urandom.   At this point its likely that the machine has been on for a while so the entropy pool has had a chance to fill.  There for this file is most likely a pure chunk of the entropy pool.   However if the entropy pool is not full,  its better to having something than nothing at all (Or even worse,  block until the entropy pool is full enough before shutting down).

On a Linux system it is very important that the entropy pool is populated during boot. To fill this need the shutdown action is to save the entropy pool to disk,  and the start-up is to re-load this entropy pool very early in the boot process. On a Linux system the ASLR'ed memory locations and TCP sequence values  are calculated with this entropy pool.   If the pool was flushed, then on each boot the memory space layout of daemon processes would not be very random and there for a process like your SMTP daemon could be exploited via a buffer overflow more easily.   This also affects your susceptibility to MITM attacks.  This is because it would be easier for an attacker to predict your TCP sequence values needed to complete the TCP 3-way handshake.

If you ever see a Linux distribution that doesn't restore isn't entropy pool at boot,  then its a vulnerability that need to be reported.

If you would like more information,  try reading the code comments in random.c


Implementing an invitation process for user setup

It is up to the user to keep their email account secure. If it is compromised, it is their problem. There's no way to really solve the problem, other than ensuring that your site's authentication is good (see here for a guide) and that you have appropriate monitoring and moderation controls in place to deal with unscrupulous users.


I've been hoping someone would ask about this topic, i've been doing a lot of research in the area.

You are correct that most of the points in javascript-cryptography-considered-harmful are outmoded by newer browsers. Aside from the obvious issue of someone compromising the server, which is a separate issue and presents a problem to TLS as well, the main points are now "fixed":

window.crypto.getRandomValues() uses a real CSPRNG
HTTPS is common and much cheaper now than in 2011
CSP's integrity and nonce <script> attributes can secure script delivery to make sure what's running is expected
SJCL is years more mature than in 2011, and no major issues are outstanding
malleable runtimes don't matter if you don't have XSS, which CSPs are now good at stopping

Furthermore, we now know that HTTPS is not an absolute guarantee of privacy (snowden/heartbleed/crime/breach/etc), but proper end-to-end encryption is. We can also now implement fairly robust, battle-tested, and secure libraries, backed by a more secure JS runtime than what was offered in 2011; "use strict" widely supported, a CSPRNG, binary structures, web workers with sealed runtime environments etc.

Those are updates to the main points, but if you have concerns about other aspects of client-cryptography, i'll be happy to address them.

Of course, nothing is perfect:

really old browsers still have issues or can't run new code securely
user-added extensions can run whatever code they want
malware can replace the whole browser with something sinister, or steal data pre-encryption
phishing can trick the user into using something besides your safe site.

In short, i think post-snowden, we should try to keep plain private data off servers wherever we can help it, and solid end-to-end encryption, done right, greatly enhances the privacy of your users and the security of their content.


Why require root to be the first entry in /etc/passwd?

It has to do with the potential for early entires masking later ones:

  Note that earlier entries in /etc/passwd take precedence over, or mask, later entries with the same user name or same user ID. Therefore, please note the order of the entries in the example for the daemon and sync user names (which have the same user ID). Make sure you do not alter this order in your own file.

http://uw714doc.sco.com/en/NET_nis/nisC.passwd.html

Therefore, if you can inject a user named "root" at the beginning of the /etc/passwd file, it could cause some havoc.


Firefox trying to connect to other computers on the LAN

There are several possibilities here:

A tab in Firefox has a website that keeps connecting and refreshing an internal IP address. That might be a home NAS appliance that by coincidence has the same IP with your computer
A Javascript script from a legitimate website attempts to scan the internal network using Cross Origin Requests or WebSockets. This website can do that. Note that the latest WebRTC feature can get the local IP address of a computer even it is non routable and behind a NAT.
Maybe a special or malicious extension or plugin is doing the traffic. Start Firefox in safe mode and see if the behaviour is the same.
There could be malware or an attacker on that computer that injected itself in the Firefox process to escape firewall egress restrictions (like the Windows firewall). Similarly, that instance of Firefox could have been the victim of an exploit that remained in the Firefox process.

You can open Firefox's network monitor and see which website is making HTTP requests to internal IPs.

You can also use Process Explorer to look at the Firefox process and look for strange things, like strange loaded DLLs and TCP/IP connections.


What impact does an installed extension have on the browser fingerprint (uniqueness)?

There are no explicit APIs to enumerate the browser extensions. But this does not mean they are not detectable or that they cannot be included in the fingerprint even if the specific extension is not detected.
Browser extensions usually serve a purpose and this purpose can cause side effects, like manipulating the DOM (remove ads, change visual representation, enrich content with more additional information ...) or change the timing of operations. These side effects can be measured and can be included in the browser fingerprint. This can be done even if the specific extension is not known, i.e even the effect of private extensions can be included in the fingerprint.
Apart from that it might be possible to detect the existence of specific extension by probing their internal resources, see How to Detect Browser Extensions for details.


What's the security issue with base64 encoding/decoding?

why would simply executing it be a security vulnerability?

It's not.

base64_decode does exactly what you would expect: It decodes a string.

There are also no know vulnerabilities in it, nor have there been in the past (there was an integer overflow issue in base64_encode -  CVE-2003-0861 - but PHP does not consider it a security issue).

I would assume that http://phptester.net/ bans it because it can be used to obfuscate data. They may have some filters in place to prevent execution of dangerous code and may worry that base64_decode could be used to bypassed these filters. I don't think that this is necessary or useful, but that might be their train of thought.


Can I detect web app attacks by viewing my Apache log file?

Yes you can, apache log gives you information about people who visited your website including bots and spiders.
patterns you can check:

someone made multiple requests in less than second or accepted time frame.
accessed secure or login page multiple times in a one minute window.
accessed non existent pages using different query parameters or path.

apache scalp http://code.google.com/p/apache-scalp/ is very good at doing all the above things


Is localStorage a security liability for JWTs?

localStorage should never be used for storing any sensitive data; if you absolutely must use something other than cookies, use at least only sessionStorage instead, which is only available to that window/tab until the window is closed.

You cannot control the expiration time like you can do with cookies.
A single XSS vulnerability can be used to steal all the information from data inside localStorage, also it persists when you close the tab.
localStorage doesn't have any options to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies.
Cookies are ideal because you have much more control over them: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
You can specify a number of attributes/flags, like: Secure, HttpOnly, SameSite, HostOnly.
It wasn't designed as a secure storage mechanism, and it's implementation can vary from browser to browser.
There is no way to restrict script-access to information stored in localStorage, which is possible with the HttpOnly attribute for cookies.
Cookies are stored encrypted on the client computer, unlike data in local storage.

OWASP strongly advises to never use local storage for storing any sensitive information:

  Any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

JWTs are highly sensitive data. Not only because they act as tokens for authentication, but they also very often contain sensitive data like email/username, roles, etc. only base64-encoded (although best practice is to avoid that). So they are often still to be considered sensitive data even when they are not valid anymore.

I recommend to read the corresponding section in OWASP's HTML5 Security Cheat Sheet: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md

An interesting read about the topic can be found at: https://dev.to/rdegges/please-stop-using-local-storage-1i04


This can be easy as changing your IP address to one of the other subnets. Since you mentioned that this isn't port-based, then if there is no anti-spoofing rules on that switch you can do vlan hopping just like that. Try various gateways too, e.g. IP address from one LAN, and gateway from another. Sometimes works - on default setup with no filtering or routing policy this is the case on most switches.

You can see one vendor's implementation of subnet-based VLans and how they interact with the switch here starting on page 12: http://www.alliedtelesis.com/media/fount/how_to_note_alliedware_plus/overview_vlans.pdf


I would recommend having a look at cloud based vulnerability scanners. You can also find a number of web based nmap scanners that will scan your public facing IPs for some common ports. (usually for free)

If you are UK based (and since you are going for cyber essentials I assume you are) I would also recommend joining the NCSC Cyber Security Information Sharing Partnership (CiSP). One of the services they offer is “access to free network monitoring reports tailored to your organisations”. Basically these are reports that will highlight any services on you pubic addresses that look risky.  This is a free service offered to all member organisations.

This will likely allow you pass this section of the Cyber Essential + audit.


Is encrypting SALT with given user's password more secure?

generate salt encrypt it with AES using user's password as key save
the encrypted salt and hash

You could do this and it would be an effective salt, however it wouldn't actually be any more secure than just using a regular salt.
Let's consider two attack vectors:
Password collisions
Obviously we don't want two users with the same password to have the same hashed password. To prevent this we use a random salt and assume that the probability of two users with the same password and the same randomly generated salt is effectively 0.
However, if two users happen to have the same password and coincidentally the same salt then they will have the same hash regardless of whether the salt is encrypted with their password or not encrypted at all. Therefore, by encrypting the salt you're not making it any less likely that a collision will occur in the salt. The only factors which do make it less likely is the quality of the random values used for the salt and the number of bits.
Brute force attacks
If an attacker is trying a brute force attack and you've encrypted the salt the only extra step they have to do is decrypt the stored salt each iteration and use that to produce the hash they then compared to the hashed password to see if they have a match.
This does require marginally more effort for an attacker, but when it comes to cryptography making something take only two or three times longer isn't significant. If brute forcing a password now takes 3 days instead of 2 you haven't really made it materially more secure. If you're trying to make something secure you want it to take 5000 years instead of 2 days.
If you want to slow down brute force attacks you'd be better off iterating your hashing process tens of thousands of times or using a hash function which is specifically designed to be computationally slow.


How to get admin cookie with Persistent XSS?

To get another user's cookie via javascript, you seem to need the following conditions to hold true:

the cookie is not set with HttpOnly (otherwise the browser will deny JS access to the cookie) or you are able to get a JS based keylogger into the login page and MFA is not used.
you are able to get the XSS to run somewhere an admin user will be
and either:

you have a resolveable host that the cookie can be sent to - if this is a public internet application and you're not on the same network, you could use a personal machine exposed via something like ngrok or some other host that is publicly addressable like an exposed AWS/GCP/Azure server

and CORS is enabled so the browser doesn't block a x-domain request/you use a way of bypassing SOP like via the img tag in your example.
or

can devise some means of exfiltrating the cookie via the server that hosts the site. This might be achieved by causing the admin user to post their cookie back to the site somewhere you can find it/extract it from server rendered HTML (like a hidden field in a forum post or something).


nmap no ping returns host is active and all ports are filtered

Here is the relevant line from the command line help output ofnmap.

-Pn: Treat all hosts as online -- skip host discovery

The -Pn flag allows nmap to assume that the host is online because you told nmap that the host is online.


No, that's not possible. It would require code on the SD card that ran when inserted into a PC and could identify the PC, and the SD card standard doesn't provide for that.


What attack vectors does AWS SSE-S3 help mitigate?

A number of regulated industries require Encryption at Rest to be compliant with relevant standards (PCI-DSS, HIPPA, etc), so this is providing this tick box.

The attack vectors that this is preventing is anyone with either physical access to the hard-drive, or (if designed correctly) root access to the machine storing the S3 data, from being able to read the data.

As for mandatory by default, AWS does not know the sensitivity of what you are storing. It could be national secrets, or it could be a public readable copy of the compleat works of william shakespeare (out of copyright material). Why should they pay the CPU cost of encrypting/decrypting Romeo and Juliet when it is a public bucket?


Considering openssl processes a majority of the HTTPS traffic on the internet, I simply don't understand your question. Of course openssl is used in production. A lot. By everyone. All the time.
The API is not nice, the certificate processing code is not nice, the CLI is not nice, the documentation is often wildly outdated. It is not easy to use, and it is hard to use correctly. It will not hold your hand. It will not steer you away from danger. By all means, if you can, use Google Tink or libsodium.
There are two forks that tried to clean up the code by breaking compatibility - Google's BoringSSL and OpenBSD's LibreSSL. They are not very popular outside their organizations, exactly because they break compatibility.
The openssl code base has improved a lot since Heartbleed, it's not as bad as it used to be.
gpg is considered to be a dumpster fire comparable to Heartbleed-era openssl, so no, it's not better (look at the work of isis agora lovecruft).
EDIT:
If your question is about encrypting backup files for storage (or encrypting files to send to people over insecure channels), then gpg command line tool is better than the openssl tool.
The openssl CLI enc command should not be used, IMO, because its man page says:

For bulk encryption of data, whether using authenticated encryption
modes or other modes, cms(1) is recommended, as it provides a standard
data format and performs the needed key/iv/nonce management.

The openssl cli cms command is not the part of the openssl code that people use and trust, and I would not use it. Also, I would not use anything that tries to do openpgp or s/mime. So, if not openssl cli or gpg then what?
If you can use openssl's libcrypto API (for example with pyca/cryptography), I would prefer that over gpg. But if you're writing code instead of using a command line tool, I would use libsodium over libcrypto, to reduce chance of error.
But actually, the correct answer finally is to use age, because my own code was not reviewed by knowledgeable people and we finally have a good tool written and reviewed by people who know what they are doing.


Is using OAuth2 services like Google or Facebook Single Sign-On a privacy concern?

OAuth2 is not intrinscally a security risk for an end-user, i.e. the person authenticating on a third-party service using their Google or Facebook account (for example).

OAuth2 works in scopes, which define the nature and amount of data the third-party service will end up having access to.

You will probably be familiar with this kind of screen (source):

A well-designed OAuth2 implementation will clearly express the various bits of information that will be disclosed to the third-party service.

However, this really depends on the OAuth2 provider's apt definition of scopes. There are no standard scopes, so they vary from provider to provider, as shown in this scopes-by-provider list.

Therefore the "outside risk" lies in your choice of OAuth2 provider. It is possible to implement OAuth2 in a totally insecure way, and still "adhere" to the OAuth2 specification. What if I ran a service with a single scope for all your information? What if my description of such scope in the consent page was misleading?

More generally, it is often a criticism of the OAuth2 specification that it leaves critical elements out for the implementers to make up by themselves, leading to all sorts of problems. The wikipedia page briefly brushes on them (please feel free to go down the rabbit hole and read up on it).

But this does not make OAuth2 itself intrinsically insecure.

Addressing the current Cambridge Analytica scandal: Facebook, for all that could be held against them, run a reputable OAuth2 implementation and have been providing this service for years before this event. People who surrendered their information in the Cambridge Analytica debacle must have initially clicked through the consent screen, which must have displayed an item about disclosing their friends circle, when using the psychological profiling app that ended up fishing (not phishing) for all this information. It seems however, that Facebook has at least been "negligent" in enforcing its data usage policy (make up your own mind).

Edit: @Ian commented that the Cambridge Analytica’s app users may not have given explicit consent for their friends data to be pulled. I suppose it means Facebook may not have been straightforward in the description of their scope.

As for your last question, an OAuth2 provider is not able to tell any more than when and how often the third-party service accesses the scoped information. It cannot know what you are doing with the third-party service, or for that matter, what the service is doing with your information. It's (rightly) out of their hands.

More background on OAuth2: https://oauth.net/2/


I recently added dnssec to a few domains, and here are a few random notes and tips from that experience:

First of all, make sure your domain registrar support DNSSEC. Some do, others (e.g. namecheap) don't. If your registrar don't support dnssec (i.e. don't have a method for adding DS records for your domain at the parent level) you need to switch registrar first.

Depending on which dns server you use, signing the domain can be an almost automated trivial task, or a fairly complex manual thing. My primary dns is Windows DNS, where you can just right-click on a zone, select DNSSEC/sign..., and a wizard takes you through the process.

Set up a test domain and go through the entire process on that one before doing on a real prod domain. If something goes wrong, you can bring your domain offline for users that use DNSSEC validating resolvers (e.g. Google DNS), so testing on an unused domain first is a very good idea.

GetDS is a neat tool on linux that can help you along the way to troubleshoot and validate your setup.

Another useful tool that will help with validating your config is this site: http://dnscheck.iis.se/


Why does Windows consider a certificate valid even after its expiration time?

It's OK if the certificate has expired - as long as the timestamped signature on the file that you downloaded was made while the certificate still was valid.

See https://comodosslstore.com/resources/how-to-avoid-code-signing-certificate-expired-issues/ for more info.


There are many facets to your answer. Botnets do resort to innumerable possibilities for evading detection, and even secure communication with the C2.

Can the malware update itself periodically?

DEFINITELY. I have seen malware in the wild which contacts the C2 and downloads updates even every hour. But a daily update is pretty common. In essence, the already installed binary will download the new malware (exe) and replace itself with the new version, essentially changing the behavior overall.

Can the malware update just the Bitcoin ransom amount?

Yes. Now the nuisance could be dependent upon the kind of botnet. Perhaps the malware is trained to visit a rogue account on twitter at particular time of the day, and pickup the seed number from the tweet, which will ultimately define the ransom amount? Oh yeah, I would say someone is already doing that somewhere.

Note that I do not have specific experience with Cryptolocker but I would suggest not marrying yourself to one particular behavior.


Security Architect as a career path. How do i do it?

This is my experience working with security architects, so YMMV, and the role is evolving... maybe it's different for new architects.  "Security Architects" have lots of outdated detailed knowledge and lots of up-to-date high level knowledge.  Most seem to be promoted into the role and survive through sheer arrogance.

Pricing, scaling, project management and risk assessment can't be understated for their roles.  They can't be experts in everything though, so that detailed knowledge they might have had earlier in their career becomes less and less important.  An architect should not be getting their hands dirty outside of the lab.  The reason being separation of duties and the risk of taking on too much of the workload.

Management needs to have somebody they can talk to.  Security architects understand the policies, the risks, the business decisions, budget and costs and direct the practitioners' leadership to implement solutions or changes on time and on budget.

Eventually their in-depth knowledge fades into obsolescence.  Some can't seem to cope with this.

The ones I worked with had CISSPs with some business training, ITIL, project management experience and a lot of technical certs collected from previous roles.  They also sit in on all the free training and certs provided by vendors who are trying to sell them solutions.

But don't forget the arrogance.  It's important.  The job is really impossible.  You're asked to provide perfection, but you're given a limited budget and a creeping scope. You're only right 90% of the time, but you'll waste all your time worrying about the 10% and burn out if you're not arrogant.  Overspec and fight for budget improvements or get risk signoff, but do not admit you're uncertain.  You are the expert.  Nobody knows more than you do.

(don't mark this answer correct... let's see if the Security architects chime in)


If you are reading academic papers, then it is likely you are going to be reading about esoteric features, distributed problems, and otherwise interesting OPEN issues in the ongoing battle of IDS.

If you are looking for (a) specific paper(s), then I would suggest looking for a SURVEY of existing systems.  Surveys usually give some historical review with emphasis on the current state of the art.  They are generally easy to read and light on hard-core analysis.  I googled for "survey of intrusion detection systems" and got so many viable hits I won't even bother linking to any of them.  You can try to focus purely on academia by hitting the major academic CS research websites such as CiteSeerX.

Since this is a term project, the nature of the system needs to be scalable.  Don't try to go all out -- maybe try creating a host-based IDS instead of trying to tackle otherwise more difficult issues.  You may also want to focus on something easy like a signature-based approach rather than a heuristic-based approach.  Remember: the core problem you are trying to solve is that of Intrusion Detection, rather than, say, distributed systems.

Of course if you find yourself with more time on your hands at the end, then augment.  Software development is an evolutionary process.  Start with something simple and build out.


Dirty and clean interface on DMZ gateways

Since your DMZ host is basically a firewall, the design you described does not make sense, you are completely right. This is no better than one-interface firewall (which is the weakest possible architecture).

When using a 2-interface firewall, the two interfaces have be on different networks - e.g. "internet" and the DMZ or the DMZ and the intranet.

At the same time, this confused design does not really do any harm, perhaps this is a historical archecture mishap of some kind.


Are password complexity rules counterproductive?

Password complexity rules are counterproductive -- for the most part.

Password complexity rules:

make users angry, and thus uncooperative and likely not to enforce password protection rules that only they can enforce;
incite user to choose creative workarounds to go past the password rules
are often grossly incomplete, and don't filter out some classic or soon-to-become-classic passwords which users find as workarounds, see point 2 above. For instance "Password1".

The only "reasonable" password complexity rule which I have encountered yet is a minimal password length. Requiring passwords to have at least 8 characters is not a hardship on users, it is understandable, and avoids passwords which are necessarily weak since they are in range of the most stupid of exhaustive searches.


How often should SSH_MSG_IGNORE messages be sent?

There if RFC 4251 describing when the SSH_MSG_IGNORE should be used:

  If there are no unsent packets, then a packet containing SSH_MSG_IGNORE SHOULD be sent.

There are also examples how this should be used in the same RFC. For more reference, you can consult OpenSSH implementation too, which sends this mesasage under this condition:

if (compat20 && c->isatty && dlen >= 1 && buf[0] != '\r') {
    if (tcgetattr(c->wfd, &tio) == 0 &&
        !(tio.c_lflag & ECHO) && (tio.c_lflag & ICANON)) {

In the english, when we work with TTY, there is something to write to the remote channel (other than newline) and terminal flags do not contain ECHO settings and there is canonical mode.


Well actually Removable media is a subset of physical media. Its the old "a cube is always a beam, but a beam is not always a cube." thing.

Boot sector viruses have been know to be spread through:

Hard Disks
Floppy Discs
CD/DVD/Blu-ray Discs
Tape's
Cartridge's
BIOS and Secondary BIOS infections
PCI equipment (I only know of lab-experiments like this, but they do prove its possible)
Firewire devices.
USB devices.
Networks
Downloads(quite rare there actually)

For most cases the way the work is the look for the Primary MBR (Master Boot Record) and modify its content with there own payload so the Virus is loaded on each boot. It usually have some companion app that it will retrieve as soon as possible to do the reinfection on different devices and redistribute the virus to other devices. so while on themselves they often do not pose a risk for removable media. They are hard to get  rid of. they are more a thing of the past though, since secure boot and the UEFI environment its harder to implement scheme's like this undetected.


What are the security issues can be exploited to VLAN switches to compromise network?

As an abstraction, the operation of a managed switch can be described with three planes:

Management plane used to configure the switch (SSH, HTTP...).
Control plane that controls how the packets should be forwarded (L2) or routed (L3). It can learn from MAC addresses from the packets it sees and there are protocols swithes can use to share information, prevent loops (spanning-tree) or handle shortest routing paths (OSPF).
Data plane or forwarding plane that does the actual switching job.

Leaving aside the possible software vulnerabilities in the switch itself, the main issue remains how well the control plane and the management plane are protected from the data forwarded in the data plane. The data plane handles also all the control plane protocol traffic between the switches, and if the packet seen must be processed by the control plane, forwards the packet to it.
In a secure configuration, every access port can only see the traffic inside its own VLAN, and the switch should not accept any control plane protocol traffic from them. If any of these protocols is open on an access port, an attacker connected to it might mimic another switch and

jailbreak from its own VLAN e.g. by

becoming a spanning-tree root or a node with MitM position.
activating trunking on the port and seeing all traffic with 802.1Q tags (DTP, VTP, HSRP...)

cause DoS attacks e.g. by flooding CDP table, or flooding any BPDUs that will cause too much processing on the control plane, exhausting its resources

disable 802.1Q VLANs altogether, making all networks see each other (VTP).

Yersinia is a tool that automates all these tricks...
The management plane must be secured, because by altering the configuration its possible to remove any lower plane restrictions the port has. Ideally, you'd have a separated management VLAN altogether.


Do I need to use the cipher command with a newer SSD to erase files?

There is an ATA Secure Erase specification for SSD drives. Not every drive and not every operating system supports this. The secure erase is a method that tells the SSD to clear all the memory cells simultaneously.  This erase method, instead of over-writing the memory cells, will tell the SSD to mark every memory cell as clear. This saves the drive from the additional damage of extra write operations. This is also secure, in that data recovery services will not be able to recover the data.

Secure erase implementations are available for Linux and there are many tutorials: SSD Secure Erase and SSD memory cell clearing.

An overview of secure erase for windows is available.  Cypher aparently does not work.  However PartedMagic does implement secure erase.  Some vendor's SSD drives will come with a vendor-specific implementation of secure erase.

This is related to another question about secure delete on SSDs: Can wiped SSD data be recovered?


Generate C File Stream Object on remote machine without fopen()

If by "full control over the stdin object" you mean provide stdin input to a, then this depends on the size and location of buf, the memory layout of a, and what len is. In this case, the way you pose your question does not provide enough information to answer this.
If you mean corrupting the pointers in the struct FILE, then yes, usually it is possible. Unless the file descriptor of a.txt is already present in the target process, it's unfortunately not as easy as overwriting the file descriptor and clearing the buffers in the struct FILE. It is however usually possible to gain arbitrary code execution by overwriting the stream buffer pointers and writing to stdin, which gives you a write-what-where primitive. The precise overwrite targets again depend on the target executable.
For a detailed discussion of a similar exploit technique, see the "Play with FILE structure" HITBGSEC 18 talk (video/slides/whitepaper).


How can we accurately measure a password entropy range?

The best work in this area I've seen is by Matt Weir in Reusable Security: New Paper on Password Security Metrics (2010).  He describes the difference between "Shannon entropy" and "guessing entropy".  He also has an interesting method of taking a password for a user, analyzing it, and offering suggestions to make it better:

  ....other methods for password creation policies, including our
  proposed method to evaluate the probability of a human generated
  password by parsing it with a grammar trained on previously disclosed
  password lists. This allows us to build a more robust reject function
  compared to a simple blacklist, while attempting to provide the most
  user freedom possible, given the security constraints of the system,
  when selecting their passwords.

Update: as user185 notes, Appendix A of the NIST Electronic Authentication Guideline from 2006, revised in 2013, is also very helpful.  It goes into detail on calculating these two terms:

  ” As
  applied to a distribution of passwords the guessing entropy is, roughly speaking, an
  estimate of the average amount of work required to guess the password of a selected user,
  and the min-entropy is a measure of the difficulty of guessing the easiest single password
  to guess in the population.

Note that this question is closely related:

Recommended policy on password complexity


Can attackers intercept my credentials on an insecure site if I log in through a 3rd party service?

They probably can't intercept credentials, but you might have a problem with tokens if you are using insecure pages and they could potentially authenticate in your name in future instances (as the Facebook Hack of last year).


The LM hash does not use a salt, and therefore any identical passwords will have identical hash values.

Another thing to bear in mind is that the LM hash doesn't process the password as a whole. Instead, it null-pads it to 14 characters (if needed), then splits that value into 7-character chunks and hashes each before sticking them back together. Thus, if the first 7 characters are identical to the last 7, the first 8 bytes of the LM hash will match the last 8.

The LM hash value for 7 null characters is AAD3B435B51404EE. Therefore a password less than 8 characters long will end with AAD3B435B51404EE, and an empty password will always (since LM hashing doesn't use salt) be exactly AAD3B435B51404EEAAD3B435B51404EE.

There is one more caveat, however. LM hashing does not at all support passwords of 15 characters or greater. When this is encountered, the user may receive a prompt asking them to confirm they want to use a password that will be incompatible with older (LM hash dependent) software. Then, the system will store a null LM hash for that user. I personally recommend that people use 15+ characters in their passwords for precisely this reason.

So, it is possible that those accounts you're looking at have completely empty passwords. In that case, those users probably deserve a stern talking to. It's also possible (and perhaps more likely) that those accounts are actually using longer passwords than most others, which should be applauded!


Is this symetric or asymetric encryption?

I think you're confused because of a misunderstanding between encrypting and hashing.  I'll try to clarify by quoting your original post.

"When you view the configuration of the appliance it shows the key as a cipher text (imagine perhaps the idea is stop people shoulder surfing the key of the appliance). So the plain text key I entered in the appliance configuration has been encrypted somehow."

The key is hashed, not encrypted. It is good practice to not store keys in plaintext because an intruder able to compromise the appliance would get access to all account passwords.

"An appliance will use my configured key with MD5 to hash messages between its self and another appliance. What confuses me is that when I configure a second appliance to talk to the first one I can either configure the same plain text key or I can copy the cipher text from the first appliance shown when viewing the appliance configuration and input that cipher text into the second appliance (specifying as I enter it that I am entering the cipher text version of the key not a plain text version of the key)."

Replace cipher text with hashed key here. Apart from that, everything is normal, the appliance allows you to enter the key either in plaintext or in its hashed form; that's a common feature.

"At this point I thought the cipher method used to store my key must be symmetrical. The 2nd appliance runs a decryption function that is the reverse of the encryption function and voila, it gets the plain text key so it can be used for the inter- appliance MD5 hashing."

There is no cipher method or decryption here, your key is stored hashed in the appliances. Appliance 2 is able to talk with appliance 1 because you entered the key in both devices. They can then use this key to communicate securely by encrypting the exchanged message with any symmetric cipher.

"After a little digging on the Internet I have found that the cipher method is using a salt. To the best of my beginner knowledge salts are used for asymmetric ciphers but these appliances exhibit the behaviour of a symmetrical cipher function because they can both encode/decode the same plain text to cipher text (or vice versa) independently of each other."

No, salt is used to secure the hash function used to store safely the key in the appliance. Salt has nothing to do with symmetric or asymmetric ciphers.

"So is this an asymmetric encryption cipher being used that is being “forced” to act symmetrically by given all appliances the same hard coded salt value, or can symmetric ciphers use a salt?"

None of the above, see previous answer.


How to sandbox Firefox ESR for normal browsing?

You have several ways to sandbox Firefox (or any similar application), depending on your exact requirements.

From the lighter to the heavier solution, you mainly have:

Firejail is a software precisely designed to easily sandbox other applications while keeping them on the same root filesystem. It relies on standard Linux features (namespaces and seccomp-bpf) and doesn't do any significant assumption on the underlying system, so it should just work on most common Linux distros. It supports sane X applications sandboxing solution (see the note about X application at the end), provides presets for common usages while supporting a wide range of customization.
Most probably overkill for personal usage, but might be suitable in corporate environment: you can customize AppArmor or SELinux rules to enforce the sandbox. You will most likely have to choose a Linux distribution which already provides a set of base rules in the option you chose. This provides a lower-level sandboxing, which can even be extended onto the network (at least with SELinux, I'm not sure that AppArmor support this), but lower-level mean a far higher amount of work to deploy this solution.
You can sandbox Firefox in its own environment, the lightest way being to use a Linux container (LXC), the heaviest being using a full-fledged virtual machine. By doing this manually you may also have to think of a way to securely transfer data to and from the FIrefox's sandboxed environment.
You can leave general public distros and switch to a security-oriented Linux distribution instead, such as Qubes OS or Subgraph OS. These Linux distribution implements software isolation at their core, Qubes pushing the idea the furthest by relying on a set of Xen virtual machines to also isolate device drivers and Subgraph relying on Linux containers instead. Sandboxing here is not a layer added on top of a general purpose distribution anymore, this means that each of these OS provides its own workflow to handle data transfers between each application, etc.
At last you can also use a dedicated computer for casual browsing, and another one for more sensitive tasks. This is not exclusive with the previous case as it may make sense in particular to run Qubes on such computers to isolate them from a otherwise potentially untrusted network (if you assume that the casual browsing computer may be infected, it means you assume that an attacker may attempt to attack your sensitive computer from within your internal network). This may seem overkill but it is common to use different computers for work and for home, this is no different.

Depending on the solution you choose, you may have to double-check how the display is handled as, under normal circumstances, each X application has access to the interface of every other application, allowing it to interact with them or capture their input and output. Here is a thread giving some clues if you need to build your own custom setup.


Can a connected USB device read all data from the USB bus?

Most likely yes, but it depends

Much like PATA, SCSI, and Ethernet devices, USB devices don't directly connect to the computer. They connect to a Host Controller that manages all signaling and communication. All ports are connected to something called a Root Hub, and to each Root Hub you may connect other hubs and subsequently more hubs.

Each of these hubs have multiple downstreams and exactly one upstream. "What does that mean?" you ask. Well, it means that whatever data sent by the hub is sent to all child hubs and devices, while data sent by the hubs and devices are only sent "upwards" to Root Hub.

So, if a number of devices are connected to ports that lead to the same Root Hub (they're all controlled by the same Host Controller), then any of the devices can sniff the data only in the direction Computer -> Device.

In my laptop, for example, the ports on the right side are controlled by a Host Controller, and the ports on the left side are controlled by another Host Controller.

Meaning that data sent to any device on the right side can be sniffed by any device on the right side, but not devices connected to the left side.

I remember a colleague of mine modifying a USB stick to prevent it from ignoring data sent to other devices. So if you plug that modified USB stick to a computer, you can capture all the files copied to other USB sticks on the same computer.

Update:

@Polynomial's comment made me question the whole answer, since my information is based on my colleague's description. To be sure, I tried to find some reference. I dug in the USB specs and I found this:

  ...
  In the downstream direction, hubs operate in a broadcast mode. When a
  hub detects the start of a packet on its upstream facing port, it
  establishes connectivity to all enabled downstream facing ports. If a
  port is not enabled, it does not propagate packet signaling downstream.

Also, a TOTAL PHASE KB article seems to agree

  USB 2.0 works through a unidirectional broadcast system. When a host
  sends a packet, all downstream devices will see that traffic. If the
  host wishes to communicate with a specific device, it must include the
  address of the device in the token packet. Upstream traffic (the
  response from devices) are only seen by the host or hubs that are
  directly on the return path to the host.


Server based pdf signing using etoken from a client browser

If the signature is supposed to assert document ownership or acceptance by the user, then the power to sign should remain in the hands of the user (precisely where his "USB etoken" resides). Since signature algorithms begin by a hash function invocation (the message to sign is hashed, and the rest of the algorithm uses the hash value as input), at least the hash of the PDF file should be sent to the user's machine.

Javascript in Web browsers does not have (yet) the ability to access hardware devices on the user's side. You won't be able to do such a thing without some kind of user-side native or pseudo-native code; this means ActiveX, Silverlight (subject to user's authorization), a (signed) Java applet, or some non-Web executable that the user runs on his machine. None of these technologies is really easy to deploy. None of these will work with tablets / smartphones (for these, a full-blown app will be needed).

Anyway, if you want the user to sign, then you want to potentially make the user accountable for whatever he signs. This is a partly legal issue, for which technology is only part of the solution. You will need a signature solution that would potentially "hold in court", which depends a lot on the local jurisdiction.