Why would a school need to install certificates on student laptops? This question indicates parents are to buy laptops for a school to install software and certificates.   I am seeking to understand reasons for site certificates installation:

Why would site certificates be installed?
What is the potential for issues with the practice?

I am seeking to understand both legitimate (constructive) reasons for certificates and potential for misuse / abuse.  It is unclear from the thread how schools could somehow decrypt traffic with certificates.

There are two different kinds of certificates you could install on a machine:

The first type of certificate is root certificate authority. A root certificate contains just a public key of the certificate authority. A root certificate is a trust anchor that is installed in your machine so that your machine can identify "trusted" sites to connect to, a certificate authority can issue a claim in the form of a server certificate that "X is owner of domain Y" and because your machine trusts the root certificate authority, it'll trust that claim. If the school/company installs a root certificate to your machine, your machine will trust whatever connections made to the school/company's server thinking that it is legitimate. If you install a root certificate, the school/company would be able to intercept any SSL/TLS connections made by your machine that runs through their network without triggering browser certificate errors/warning.
The second type of certificate is client certificate. A client certificate contains a private key that is unique to you and a certificate signed by the school/company's certificate authority. A client certificate is used for your machine to authenticate to the school's infrastructure, proving that it is you that is connecting. A client certificate is used as essentially a better solution to authentication credential than having to remember passwords. A client certificate cannot be used by the school/company to eavesdrop on connections made by your machine to servers that aren't owned by the school/company.

A client certificate is  fine to install and shouldn't cause any security concerns. In contrast, be very wary of installing a root certificate, as it is a cause for concern as the root certificate can easily be abused.


Signature Based Malware Detection I am developing software for detecting malware based on signature, in Java. I have researched a lot for the approach to move ahead.
I found that the basic idea is to store the existing malware signatures i.e. signed hashes in a malware repository and compare the presently scanned file with the stored hash values.
I am confused about how to get the existing malware hash values to build the repository. Any help regarding the problem would be very useful to me.

In order to get those hashes, you need samples of the malware that you want to detect. That is one of the reasons why AV companies have very large teams to hunt for and identify malware, and why their database of hashes tends to be guarded.

For your project, you will need to find (or write) malware and collect those hashes.


Authentication without login and password in mobile apps I'm getting started in app development and I'm thinking about the login flow of first app. Some other  apps like Whatsapp and Clash of Clans does not require any sign up or login process in order to connect. So, I tought about this methodology:

If it's the first time launching the app, it will send a "Sign up" event to the server with a username that the user chooses.
The server will check if the username is already in use, and if not, it will create an account in the database with the username and generate a access token of 64 characters long.
The server will send the access token to the client
The client will store the access token for further login requests and it'll be the only way of authentication.

All the connection process would be over TLS to a socket.io server.

Is this safe against a remote or local attacker? What would be the best way of storing the access token locally? Should I encrypt it locally? How should I encrypt? Should I encrypt it in the server database?

I work as an IT Security professional (IT Auditor), so can answer from experience.

First, I will define a secure token. In order for the access token to be secure: you would need to satisfy the below:

Token expires at some point
Token cannot be modified in transit between client and server.
User cannot modify the token.

  Token expires at some point

This requirement is the easiest. You specify a date when this token will no longer be valid, on the server side. If date of the login > expiration date of the token, then reject the token as having expired.

  Token cannot be modified in transit between client and server

As you are using TLS, (hopefully version 1.2 and updating to 1.3 when finalized) this problem should be resolved already. TLS provides confidentiality, ensuring that the access token is not disclosed without authorization to a third party.

  User cannot modify the token

This requirement is the most difficult. To accompanist this, you would need to use a digital signature with PKI. Do not use SHA 1 as the hashing function because this algorithm is INSECURE. Applying the hashing function to the access token results in a message digest. The message digest is then encrypted using the private key that only the user knows. Once the credential are decrypted on the server using the public key of the user, if the resulting message matches the credentials on the server, then it is guaranteed that no modification of the access token by the user took place.

The above method guarantees the C - confidentiality, and I - Integrity requirements of the security CIA triad. Non-repudiation (user cannot deny it is his credentials) is also guaranteed due to the public key of the user being able to decrypt the encrypted message received.

To answer some of your other questions:

  Should I encrypt the access token locally when stored?

Yes you should. The above pertains to data in transit, but not at rest. If a hacker were to compromise the local client machine, he or she can easily steal a plaintext token, and then impersonate the rightful owner.

  How should I encrypt?

You should use a strong encryption algorithm such as AES or RSA. Chose a long key length (ex: 256) to maximize security.


Should both user ID and Password be masked for online banking? Is there a best practice for security purposes requiring masking of both User ID and Password for online banking? Is there any rationale for or against masking both?

Best practice says that a username should be something that can be considered public information and thus doesn't need to be protected.  The fact that they find the username needs to be protected either means that a) they are doing something counter to best practices that makes it need to be kept secure or b) they are engaging in some security theater to make people feel more secure about their account and possibly make shoulder surfing minimally more difficult.

I can't see how it would give any real benefit as the password is already masked and thus, unless the keys are being logged or the keystrokes recorded.  If they are able to get the fully masked password, then they will also be able to get the fully masked username.

One measurable gain I suppose I could see would be if they cache the username.  This would mean that if you are accessing your bank account in a public place, the username could be displayed, already entered and masked, such that a shoulder surfer would only be able to get the password and not the username.


Appending a secret (pepper) to Argon2 password hashes I've read quite a bit of the StackExchange and HackerNews debates on the user of "peppers" in password hash security. There are a number of different implementations of the idea of a pepper, ranging from an additional hardcoded salt in the code hash(password, pepper, salt), to encrypting each password hash separately, in which case the secret key is the pepper.

In the case of one of the middle ground approaches, a shared and secret pepper is included via hash(hmac(password, pepper),salt). This is necessary primarily because of many hashing algorithm's reliance on the Merkle–Damgård construction which is vulnerable to length extension attacks.

However, Argon2 is not based on a Merkle–Damgård construction and therefore this attack would not apply. In using Argon2, can the naive approach of argon2(password, pepper, salt) be used?

Additionally, the Argon2 specification Introduction seems to indicate that using HMACs, peppers, or secret keys at all is unnecessary. Is Argon2ID with  strong memory, threads, and time costs enough on its own?

Argon2 actually allows a pepper in the algorithm itself, called the secret. This would be the ideal way to use a pepper, unfortunately most language bindings I've looked at don't expose this parameter (of the bindings listed on GitHub only 2 of them specifically mention supporting keyed hashing).

If the secret parameter can't be used, argon2(hmac(pepper, password)) is a reasonable alternative. argon2 can be applied outside hmac for simplicity, as the way it's generally used it'll give you an output that includes an encoding of the salt and options used. Using hmac outside argon2 should be comparable for security, but then you'd need to keep track of the Argon2 parameters yourself.

As for the spec seeming to indicate that a pepper isn't necessary, I assume you're referring to this:

  A trivial solution for password hashing is a keyed hash function such as
  HMAC. If the protocol designer prefers hashing without secret keys to avoid all the problems with key generation, storage, and update, then he has few alternatives: the generic mode PBKDF2, the Blowfish-based bcrypt, and
  scrypt.

The way I read it, what that's saying is that a keyed hash is actually the best way to hash passwords, so long as you protect the key really well (such as using an HSM). The problem is, protecting the key is difficult (HSMs cost money, supporting a pepper with an HSM takes development time), so slow hashes like scrypt, bcrypt, and Argon2 are used instead.

What it's not saying is that using a keyed hash in addition to Argon2 is a bad idea. Even if you can't protect the key with an HSM, it can still be worthwhile if it's better protected than the password hashes. The worst passwords will always be cracked no matter how high you set the cost (and your users' patience gives you a low upper limit); a pepper can prevent that.


Securing confidential information between users I know there are several issues about encryption, but my case is slightly different

Users have confidential information stored on their device
They have a RSA key pair
The information must be encrypted and sometimes shared with another user in a secure manner. The server in no case can know the contents of this information

Options

1) Encryption on the device with the public key and decryption with the private key. When the user wants to share data, encrypts it with the public key of the third party and sent by the server. The user decrypts them with the private key

2) There is a HMAC encryption key for data. The secret key is encrypted on the device with the public RSA key and decrypted with the private key to be used. There is an encrypted copy of the data in the server. When the user wants to share data, encrypts the secret key with the public RSA key of the other user and link to acopy of the data in the server

Pros and cons

1) Encryption and decryption slow. Data synchronization requires a copy per user. An evil user does not put the system at risk

2) Encryption is faster. There may be a copy of the data server and sent only the key. Delete a contact involves renewing the key and distribute?

My question is which option to choose and in the case of 2, which can have security issues

I would perfer Nr1 due to simplicity, but take Nr2 if:

(a) In your case, Encryption and Decryption really -is- slow for some reason. So slow that its a problem for Usability. Perhaps massive amounts of Data or user machines with very bad processing capacity.

(b) It was not a typo in Option 1 that they use a third party key. In my opinion they could make the public keys available to all system users, then encrypt data with the public key of the intended recipient user when the data is requested (then only he/she can decrypt it with his/her private key).

RSA have a padding issue you might consider reading about, What specific padding weakness does OAEP address in RSA?.

When it comes to these sort of things, SIMPLE is often the wise choice.

With the implementation of every encryption method, every little row of code there exists the possibility of absolute and crushing failure. Thus complexity of solutions should be reduced to as simple as it can possibly be, but not more simple then that.

One encryption method, one crypto library, one process to create one type of keys, few points of failure.

How often are data updated? How much does data storage cost? How is the HMAC generated? Such things needs to be considered.


Token based approach to authentication over SSL Rest API - refresh tokens I'm quite a newbie at security.

I'm developing an android app with a token based approach to authentication.
I'm not using Oauth as the OAuth 2.0 is not an authentication protocol but rather used to delegate authorisation: http://oauth.net/articles/authentication/.

Since I don't really want anyone else to use my API, I do not need to delegate authorisation so I have decided not to implement Oauth.

This is the flow:

The user passes a username and password to the server using SSL
The server verifies the username and password and passes back an authentication token using SSL. The authentication token is a random set of characters
The authentication token is saved on the app and then sent back to the server each time a REST request is made using SSL

My question: are refresh tokens relevant in this scenario?

The authentication token is already encrypted through SSL and replay attacks or man-in-the-middle are not possible.

Also the authentication token is used only for access my API and not used subsequently in any further API calls from server to server (like for example, if I call the google maps server from my server, I don't use my authentication token to make the call - the token is unique for my server).

I could make the flow more secure by hashing the authentication token and sending that over to the server so that the server can check whether the hash of the token stored matches the hash sent by the app...

Why to use refresh tokens when your authentication token is securely transmitted through SSL?

Sounds like a good plan. Some things to watch out for are

Be sure to store password securely on server. There are lots of references on that. Good strategies will likely involve salt and bcrypt or PBKDF2.
Always use SSL. Best to restrict non-SSL via Web server if you can.
Use a secure random generator to get token.

That said, using your app server's authentication is likely the safest. Existing security systems are generally considered more robust than new ones.


Security of OpenVPN against sophisticated DPI solution I'm planing to build a device (prototype) that act as a portable security gateway. To make this, I choosed OpenWRT running on Raspberry Pi with OpenVPN for VPN connection. My main purpose of this build is develop a unit (prototype), that single individual can use with easy configurations which protect him from DPI solutions.

As we know, there are many sophisticated network security appliances (NGFWs), that have state of the art DPI capabilities. As per the my knowledge, securing  SSL traffic from this kind of devices are impossible.

My question is: Can OpenVPN alone protect user from the kind of interception (and SSL decryption) or do they need further layers of protection?

DPI threats against OpenVPN is pretty hard, unless the attacker somehow grabs the random, freshly generated session keys which is transmitted over an SSL connection. The SSL connection, in turn, is secured using a pre-shared certificate and a secret server certificate. So an attacker would need to compromise the server itself. Usually, said attackers would not go through the trouble of compromising a very secure server unless the target is high-profile.

Deep packet inspection, as far as I know, is usually effective in non-encrypted connections. HTTPS is usually effective in foiling DPI unless you are up against powerful entities (rich kids, government, etc.)

This is the gist of my point. For further reading, refer to my sources below.

Sources:

https://openvpn.net/index.php/open-source/documentation/security-overview.html

TLS Authentication/OpenVPN/MITM Attacks on Public Wifi

How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?


Can a smartphone get hacked even when off? I've read that there are multiple batteries inside a smartphone, so even when you turn it off it can still communicate with other devices. So my question is, could a smartphone get hacked even when off? For example, if your smartphone is off and near an infected router, or some other device with malware, could it get hacked?

I believe it won't cause it's "turned off". But I think the case is different when your phone is "turned off and charging". You notice when charging that some stuff appears in your screen? Those are programs that run when the device detects that it has plugged into a charger.

But alas, I do not have the knowledge to exactly know the actual things happening underneath all those fancy displays when your phone is charging so I can't really tell if those programs could actually wake and take control of the wireless controller within your Smartphone. But even so, it's not possible to magically hack your phone with this fact because those programs would never wake the wireless controller even if they are capable of doing it.

The only case they will wake it up is if they have been infected/turned rogue by a hacker in the first place that was already able to get high-level access to your phone while it is turned on.

So to TL;DR answer your question.
No, it is not possible to magically hack your phone when it is turned off and even if it is "turned off and charging".

Side note: I do not know if it is possible to turn on a smartphone while it is connected through USB but actually hacking your phone involves it being turned on first. Only then can the hacking actually take place.


Is there any relationship in the output between SHA256 and SHA224? Say I have a message m.

m1 = sha256(m)

m2 = sha224(m)

Is there any relationship between m1 and m2? If I'm trying to hide the value of m, can a third party guess at m if they have these two values? I'm assuming the answer is no, but just want to make sure there are no caveats.

The reason I want to use two different hashing functions on the same message is to generate two keys that are different but still related to the same data.

From Wikipedia:

  SHA-224 is identical to SHA-256, except that:
  the initial hash values h0 through h7 are different, and
  the output is constructed by omitting h7.

So there's no exploitable relationship between m1 and m2, it's not easier to guess m from m1, m2 or both of them.

However, what you really want is a key derivation function. Do not roll your own crypto and do not reinvent the wheel.


Stopping a phishing email by blocking the ip address of the sender I would like to know whether there is anyway of extracting and verifying the ip address of someone who has sent you an email.

Is this typically stored in an email's header / metadata?

If so, can this ip address adequately identify the ip address of the original sender? If the original sender was using a VPN, would the ip address in the email header and/or metadata accurately represent the sender?

The main reason I am asking is that I am receiving quite of lot of spam emails that are coming from different email addresses but containing the same phishing email. I am confident these are coming from the same source. If I block the ip address recorded in the email's header/meta data, would this be effective? Or would I be blocking some (innocent) VPN server somewhere overseas instead of the actual culprit?

anyway of extracting and verifying the ip address of someone who has sent you an email.

While the IP address of the sender might be contained in the mail header it can easily be faked. Only the receiving mail server knows the real client IP address and if you trust this MTA you could check the Received-Header added by this MTA if it contains the clients IP address (not all do this). Not that depending on the path of the mail there might be several MTA involved and any MTA can change the header and the original sender can also add some fake Received-Headers to the mail.

  ... lot of spam emails that are coming from different email addresses but containing the same phishing email. I am confident these are coming from the same source.

Not necessarily. Spam/Phishing is often sent using rented botnets, i.e. the same mail comes from lots of different source IP address. Assuming the same sender IP all the time and blocking it would thus not help. But you might make use of real time black lists (RBL) which include typical source IP of spammers and also networks for "dial-up" accounts (i.e. home users) which are often unwillingly part of a botnet and thus used for spamming. See for example this multi-RBL check. Use of such RBL can often be added to mail servers and tools like Spamassisin can make use of RBL too.


How do you prevent physical backups from being stolen? I'm sure, by now, we're all aware of the need to encrypt backup disks, but what can be done on the physical security side of things to prevent backups from being stolen or damaged?

Particularly:

What physical security solutions are available for backup disks in long-term storage?
What physical security solutions are available for backup disks during transit?
What considerations should be taken for secure long-term storage locations?
Are there specific solutions for different types of media? e.g. DVD, hard disk, solid state, tapes.

On-site storage

Fireproof safe/cabinet in a access controlled environment is often considered safe enough, It is manual labor to actually put the drives/tapes into the container. Example:
Attached fireproof media container. An example here is SentrySafe. A cheaper example is ioSafe.
Site redundancy. When you already have site redundancy for your applications you may also have the backup redundant on both sites. This can be a cheap solutions if you already have site redundancy for your solutions. (Example: A site which is reachable, but site is both in UK and US. Often solved through global load balancing).

The not so obvious solutions for physical security:

Each storage device should be marked with unique identifier. This should be stored for bookkeeping. Bar codes can be a good solutions for easy scanning devices in and out.
Keep inventory of all backup devices.
Access control on access to storage room.
Keep records of who has access and who invokes access for what times. Keep in mind seperation of duties is important.

Off-site storage

Vaulting - You let someone else store your drives/tapes. Banks and security firms can often provide this type of service. They will however most likely store it just like they store other valuables.
Electronic storage - You copy the data to the other party who stores your backup. A simple example is Dropbox or Google Drive.

Storing off-site will most likely increase the expenses, but will help you a great deal in case of anything happening to the on-site property. This can often be considered as a last line of defense.

During transit

Drive Carrying Case, A Hard-shelled Waterproof Case - From Amazon

Backup media rotation

One should adopt a good backup strategy (like grandfather, father, son system). Once a system like this is in place it is recommended to rotate the use of hard-drives and tapes so you can easily identify how much the media device has been used. This is so you can easier calculate when to replace disks or tapes when their life expectancy has worn out.


Why do we need OMEMO if XMPP is already encrypted? I read that XMPP is encrypted. E.g. Wikipedia says:

Strengths
Security
XMPP servers can be isolated (e.g., on a company intranet), and secure authentication (SASL) and encryption (TLS) have been built into the core XMPP specifications.

OTOH, there are some additional encryption protocols, which seem to work over XMPP – like OTR and OMEMO.
So I wonder, why do we actually need any of these additional protocols to enable privacy, if XMPP is already encrypted in the core specs?

TLS (Transport Layer Security) simply encrypts the data in transit between two endpoints.  This is good for preventing casual observation, but doesn't protect the data from all vectors.  And TLS is between two parties, so a group chat would need a number of TLS connections with the associated encryption overhead (direct chat); or would not be secure (relay server chat) as you are only encrypting to a relay server that could read the entire conversation (necessary in order for it to forward the conversation to the other parties).

OMEMO is actual message encryption.  And, perhaps more importantly, it is a double-ratchet system designed for multi-party communications with the security maintained even if a client is offline and waiting for delayed delivery.

Think of TLS like an armoured car.  You put your private message in the armoured car and it is secure from outside parties snooping in, but anyone involved in the armoured car company can look in the back of the truck and see what you put back there.  And (a special case for messaging) if no one is at the destination when the armoured car gets there, the guards give up and burn the message.

OMEMO is like if you have a favorite book cypher that you use to write the message.  Even if the armoured truck driver looks at the note, he still won't be able to read it.  And since it is [payload] encrypted the truck driver can leave the message on the recipients door step, and it'll remain secured.


ZX Spectrum tape loader: how was copy prevention implemented? I am curious how copy prevention was implemented for games or other programs loaded from cassette on the micro computers of the early 1980s, such as the ZX Spectrum 48k. If I recall correctly, some games even managed to defeat direct tape-to-tape copying. How was this achieved, and does this technique or set of techniques have any application for modern IT security?

I am mainly interested in the ZX Spectrum, but the scope of this question also includes other micro computers of the early 1980s that loaded programs from tape.

Back then, tapes were just binary data on a magnetic film, with no "hidden" channels or out-of-band capabilities. Manufacturers that claimed to make tape-to-tape recording impossible often just made the tape look different, to deter would-be pirates. A regular tape recorder module was usually used to read them, so making "special" tapes couldn't really work.

The usual method was to ship a booklet (e.g. an instruction manual) with multiple pages, then ask the user to input a particular word from a particular line on a particular page. Code cards were also used, utilising embossed black text on dark paper to prevent easy photocopying.

Anyone could copy the tapes, but copying the booklet was more difficult at that time; nobody had scanners, and few people would go to the effort of photocopying a multi-page booklet at their local library. Even if they did try to copy the booklet, key words would often be darkened in the text to prevent them from being copied cleanly.

Some early video games included merchandise, code wheels, text on CD cases (e.g. Meryl's codec number in Metal Gear Solid), or other physical goods that were required to play the game (e.g. to solve certain puzzles), and these were reasonably effective deterrents. Other games simply shipped posters and action figures to make the original copies more valuable than a copy could be.

As a (slightly off-topic) side note, VHS tapes did have the ability to contain data that couldn't be copied by normal players. Essentially a VHS player works by running the digital signals from the tape into a digital-to-analog converter (DAC), which then sends that signal to the monitor along with an appropriate synchronisation signal. This analog signal is interpreted as a set of colours, but some subtle peaks were also used to send commands to the player (e.g. blank screen, reset vertical sync, etc.).

Macrovision (a copy-protect mechanism) encoded high voltages into the tapes, such that the player's protection circuitry would compensate. On the original tapes, the value would be interpreted as a glitch and be ignored by the player. On a copy, the recorder would reduce the signal level to that of the rest of the video. Once that part of the signal was reduced to a normal level, the player would interpret it as a blanking signal, causing the video to be entirely blank (usually blue). Other mechanisms relied on the same trick, but instead used signals that caused the video to be hue-shifted, or that caused most players' tracking mechanisms to malfunction.


What is the purpose of the CA-BUNDLE on a webserver? So I purchase a certificate from DigiCert.  The process goes like this:

Generate private key and CSR on web server.
Submit CSR to DigiCert.
Get a signed certificate back as well as their root certificate and intermediate certificate (CA-BUNDLE).
Upload the certificate and CA-BUNDLE to the webserver via cPanel, Plesk, w\e.

My question is simply, what is the purpose of the CA-BUNDLE?

My certificate gets signed by a DigiCert Intermediate CA which is signed by DigiCert's root CA.  All browsers inherently trust DigiCert (and I assume it's intermediate CA?).  The actual RSA encryption and AES key exchange is done using the values in my certificate, in fact the web server doesn't use any of the certificates in the CA bundle for anything.

With that being said, what's the point of it? and why do I have to upload it?  The only thing I can see is if the client doesn't have one of the intermediate certificates installed it can ask my web server for it (and verify it against the in-browser DigiCert root)?

All browsers inherently trust DigiCert

True enough.

  (and I assume it's intermediate CA?)

Clients may include trusted intermediate certs, but cannot be expected to.  It is your job, the server, to provide any intermediate certificates necessary to validate your certificate chain up to the root (RFC 5246 7.4.2):

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

  The only thing I can see is if the client doesn't have one of the intermediate certificates installed it can ask my web server for it (and verify it against the in-browser DigiCert root)?

Correct.  That's exactly the reason.


Why does Digicert have so many Root Certificates? Which one is right for me? I'm trying to add a system root certificate to a container that doesn't have any. Digicert is a CA that I've used before, but I've never had to add a root certificate to my system before.

Then I noticed that Digicert has loads of root certificates to choose from. Which one is right for me? Why are there so many?

Which one is right for me?

This depends on your specific but unknown use case. You need to add a new root certificate only if you need to verify certificates which were directly or indirectly issued by a yet untrusted root certificate.

Note that adding a root certificate does not help in the common case of a misconfigured server which fails to send the intermediate certificate.

  Why are there so many?

Some of these root CA come from acquisitions of other CA like CyberTrust. Some are used for different purposes - like issuing normal certificates vs. issuing EV certificates. Some have different types of keys, i.e. RSA vs. ECDSA.


Private generated and encrypted links show up in Yahoo search, but not Google A customer found a couple of generated links pointing to private data on their website. After looking at the links and searching a specific part of the URL on Yahoo, I found dozens of other private links available, from all our other clients (all different and privately owned domains) - this is really bad!

The links look like this:

https://domain.com/app/pagename.ext?aes_ctr_encrypted_data_encoded_in_base64

(The encrypted part is more than 100 chars.)

We send these links to clients by email only, we never publish these addresses on any web page, or do anything else with them.

How in the world can theses private addresses be indexed? Is it because Yahoo crawls private emails (seems really improbable)? Is it because these emails where somehow leaked on the web and Yahoo crawled them?

Also I was thinking, is it possible that clients copied/pasted the URL directly in Yahoo search, and then Yahoo searched for that and kept it?

Is it because Yahoo crawls private emails (seems really improbable)?

That's highly unlikely. E.g., Yahoo surely wouldn't index a password reset link that you get mailed to your private Yahoo inbox.

  Is it because these emails where somehow leaked on the web and Yahoo crawled them?

That's a plausible explanation. It's sometimes hard to reason how exactly a search engine has discovered content but it had to appear somewhere on the public Internet or be made accessible to the search engine. Another possibility that comes to mind is that the framework of the site automatically indexes all content in a sitemap (e.g. at yoursite.example/sitemap.xml) - it's something that Wordpress often does. Also, are you sure the content isn't visible via directory listing or a publicly accessible database dump?

  Also I was thinking, is it possible that clients copied/pasted the URL directly in Yahoo search, and then Yahoo searched for that and kept it?

I don't know if Yahoo automatically indexes the URLs you search for - this surely sounds risky from a security perspective. But I find it unlikely that multiple of your customers would put their URLs in the Yahoo search bar.

If you have request logs available, you could check which documents the Yahoo crawler was accessing in the past (look for a user-agent containing "Yahoo! Slurp").

Countermeasures

To prevent search engines from indexing sensitive content, you can add a Disallow entry to your robots.txt file with a * wildcard, like this:

Disallow: /app/secretcontent.ext?token=*

But note that not all search engines respect Disallow directives and robots.txt is one of the first places that attackers look at for information gathering.

More generally, you might want to let links to sensitive content quickly expire (or even turn them into one-shot links that can be only accessed once, if appropriate).

Another approach could be sending users the link to yoursite.example/secretcontent and the token separately. The site would then present a form where the user has to enter the token. This form would submit the token via POST so that the token is never visible in the URL and hence can't be indexed.


How to Minimize Apache Loadable Modules (serving MediaWiki) According to Guide to the Secure Configuration of Red Hat Enterprise Linux 6, there is this policy:

"In certain scenarios, it is beneficial to remove certain httpd modules to limit the functionality of the HTTP Server. To do so, simply comment out the entire line which loads the module you wish to remove in the /etc/httpd/conf/httpd.conf file".*

How should I know which modules are needed for some web application? Particularly I want to deploy MediaWiki. I searched its wiki, and didn't find such topic in its security page.

Unless MediaWiki's documentation details which modules are required then there is no way to know other than by trial and error... as @Tom Leek suggested, disable them one by one.  This can be a little tedious and time consuming but will achieve your goal.  Some of the modules should be obvious though.  For example, if the system is not a proxy you don't need mod_proxy.  If you don't do any URL rewriting then you don't need mod_rewrite.

Hopefully the list of Apache modules with descriptions will help narrow the field more quickly.


openssl_digest vs hash vs hash_hmac? Difference between SALT & HMAC? openssl_digest vs hash vs hash_hmac

I want to use SHA512 for storing password.
Which of the above methods are best to use? Why?

What is the difference between SALT & HMAC?

I just read that HMAC is built on top of hash function.

So is SHA512+SALT+HMAC really necessary or SHA512+SALT or SHA512+HMAC?

Short answer: use bcrypt.

For storing passwords, you actually do not want to store the password itself, only "something" which is sufficient to verify a password. This "something" should be the result of a deterministic function applied to the password. Preferably, the function shall not be reversible (because that's the point of not storing the password itself: preventing an attacker, who managed to obtain a read-only access to the database of a server, from immediately computing all the users' passwords). By the same reasoning, the password processing function should strive to make password guessing uneasy. "Password guessing" is trying potential passwords until a match is found (it's called a dictionary attack).

To make dictionary attacks difficult, the password processing function should have three characteristics:

It should be slow.
It should be distinct for each password instance.
The hardware which optimally computes the function should be exactly the hardware which will run it under normal conditions.

Slowness is about making each "guess" as expensive as possible for the attacker. This is usually done by iterating a one-way function; the number of iterations should be counted in thousands or even millions. Standard hash functions are very fast; a plain PC can evaluate SHA-256 or SHA-512 millions of times per second. We do not want an attacker to be able to try millions of passwords per second on a plain PC. Hence, we use many iterations. Of course, this makes password verification slower for us too -- but we do not have millions of passwords to verify per second, so we can tolerate a quite high iteration count.

Making the function distinct for each instance is what the salt is about. The salt is a parameter which alters the processing of the password (let's say that it is "hashed together with the password"). The salt is stored with the hashed password. The salt is chosen randomly when the user chooses his password; a new salt is generated when the user changes his password. The role of the salt is to make password processing different each time. This prevents parallel attacks. An attacker who got a copy of the server database may want to attack 1000 accounts simultaneously, by hashing a potential password and see if the result matches any of the 1000 stored passwords; this is a parallel attack and the salt defeats that. A precomputed table of hashed password, where a given stored hash password could be simply looked up, is also a kind of parallel attack, and the salt is still effective against that. Salting is good. Salts work optimally when no salt value is ever repeated; a big enough random salt ensures that with high probability.

Optimality of hardware is about making the attack expensive for the attacker. We have a server (i.e., a PC) which spends as much CPU as is tolerable on password hashing (the number of iterations is configured that way). This scheme would be weakened if the attacker could run his dictionary attack in a more cost-effective way by using another kind of hardware, in particular a GPU. A 500$ GPU will usually be able to try 10 or 20 times as many passwords than a 500$ CPU, if the password processing function maps well to the kind of operations that GPU handle well. Usual hash functions such as SHA-256 map uncannily well to GPU abilities. So, by using such a function as the basis for a password processing function, you are basically giving a 20x advantage to the attacker.

Choosing a one-way function which does not run well on a GPU, iterating it many times without compromising the one-wayness, and adding a salt, is very difficult to do correctly: security is a subtle thing, and cannot be tested, save by hiring a bunch of cryptographers and letting them work a few months on the subject. Even then, the cryptographers will not give you any answer more decisive than "we are the best of the best at what we do, and yet we did not find any weakness... for the time being". You are strongly advised not to invent your own scheme; that's the first and foremost lesson in such matters: handmade is bad.

Instead, choose a function which has been around, widely used, and not broken yet, for a decade. Fortunately, such a function exists, it is called bcrypt. If you work in a field which is inordinately concerned with administrative approval, you may want to use PBKDF2 instead; but PBKDF2 runs with a standard hash function, which means that a GPU-wielding attacker gets a bonus, which he will not have with bcrypt, which is deliberately hostile to GPU (see this previous answer for details).

HMAC has nothing to do with all that. It is a Message Authentication Code, aka a kind of "keyed checksum" used to verify integrity of a piece of data. HMAC uses a key, so it involves key management, which has never been a simple thing. Some people have advocated storing such keyed checksums as password verification tokens, the idea being that the attacker will not be able to "try passwords" even if he has a copy of the tokens, because they are useless without the key. But this assumes that the attacker could not get a copy of the key, even though he could access a dump of the server database. Therefore, practical applicability of this model is questionable. Key management is a can of worm; avoid it if you can.

HMAC is defined as operating with a hash function (any hash function); it invokes that function twice in order to be a proper, secure MAC, even with existing hash functions which have a few shortcomings.


How to setup cronjobs that do scp without saving the .pem file on either of the machines I have the following situation and want to know what are the best practices to do such things without exposing myself to security issues

I have two servers both use the same private key for login.
Server 2 copies files to Server 1 via scp (currently I save the private key on Server 2)

If any hacker ever gets control of server 2 he will also get the private key and hence both the servers will get compromised.

I am pretty sure that this is a very common scenario for most of the configurations and want to know what are the best practices in such cases.

The best practices you should be concerned with here are:

Don't re-use credentials for multiple purposes.  The two servers should not be sharing a private key.
Hobble automated processes.  Make sure that the SSH channel that is being opened up by server2 is limited to only copying files, and only to the intended directory tree.

The latter is important.  If you're saving the private key on the server 2 so it can be used via cron, you need to limit the damage that can happen on server 1 if someone takes control of server 2 and tries to use that key.  Give them an interactive login?  Very bad.  Overwrite arbitrary files?  Very bad.  Overwrite files in one tree, using a pre-determined command?  Much better.  Modern sshd_config can be written to powerfully limit a specific login.  Create a special-purpose login for this so that you can lock it down tight.  Don't use root.  No, really, don't use root.


Is bitlocker without a PIN as good as having no hard disk encryption at all? If bitlocker was configured for a user not to input a PIN; and the device got lost/stolen; is there a risk of the data on the hard disk being exposed?
With no PIN enabled; is that essentially as good as having no hard disk encryption at all?
Am i right in assuming that not enabling PIN; is a self decryption device?

Am I right in assuming that not enabling PIN; is a self decryption device?

Yes you're right in that without the PIN  enabled decryption will occur automatically without any user input/authentication required.
However this does not equal having no hard disk encryption at all. The data on the disk is still encrypted which means that if an attacker physically removes the disk to read it or boots onto another OS (from a USB), they will not be able to read the data on the disk. This could deter casual attackers with limited technical abilities.
More sophisticated attackers may be able to recover the encryption keys by other methods and thus will be able to decrypt the disk. This may be accomplished by first booting the operating system and then extracting the keys from memory. Alternatively the may attempt to extract the keys directly from the TPM chip. Or they might attempt to exploit unpatched vulnerabilities in the OS or services that launch on startup (like RDP or SMB) after booting to achieve Remote Code Execution on the machine.


Specific risks of embedding an HTTPS iframe in an HTTP page I need help listing the specific risks of embedding an HTTPS iframe that enables credit card checkout inside of an HTTP page. Are there security issues with embedding an HTTPS iframe on an HTTP page? provides some high-level concerns, but I'm looking to be as specific as possible about potential attack vectors. Click on Buy Now for a good example of a secure iframe inside of an insecure page, being used today for credit card transactions. Here's what I have so far:

Conversion will likely be lower because educated users will know not to enter their credit card number without seeing a green lock in the URL in the browser chrome. (Less knowledgable users may not know that they shouldn't trust a lock appearing inside the browser frame, as in the example above.)
Even if users are comfortable with this approach, it's generally a bad idea to encourage users to enter their credit card number when they don't see an SSL lock confirmation in the URL bar. It is teaching users bad security habits. This post makes the point that SSL is about security more than just encryption and authentication.
An active man in the middle could inject a rogue script into the parent page that could keystroke snoop. I believe this is what the Tunisian government did to steal dissidents Facebook credentials. (I believe the rogue script would be prevented from accessing the username and password from the secure iframe, but could still access keystrokes). Of course, a more determined government authority could subvert DNS and forge an SSL certificate as well, as the Iranian government apparently did, in which case a secure parent page wouldn't help.

I also have this list of unrealistic concerns:

Another Javascript object on the unsecure parent page could snoop the contents of the secure iframe. I believe this is no longer possible as long as only browsers IE8 and above are supported.
A rogue Javascript object on the parent page could do keystroke logging to capture a user's credit card number. This may be possible, but the risk is not affected by whether the parent page is served via SSL or not. A rogue script could keystroke snoop either way.
The user can't see the URL the secure iframe is being served from. With either a secure or insecure parent page, you would need to be a technically-sophisticated user to view the iframe source URL.

Could you please tell me what other realistic and unrealistic vulnerabilities I'm missing? I have no doubt that the best option is always to embed a secure iframe into a secure parent page. What I'm trying to decide is the relative risks and benefits of enabling a secure iframe inside an insecure page versus the poor user experience of jumping users off of the insecure site where they see the product in order to complete a secure checkout elsewhere.

An attacker who can embed a rogue script in the parent page can also simply change the URL for the iframe, redirecting it to an arbitrary location, at which point all kinds of phishing and man-in-the-middle setups are easy. No need to play DNS tricks at that level. That's the main problem with such an HTTPS iframe: you cannot easily know if you got the genuine thing (you have to fire up the browser debug mode to be really sure -- a cursory look at the page source is not ultimately sufficient because scripts loaded from the page can manipulate it at will at the DOM level, so what you seem to see in the source code is not necessarily what you get).

It really boils down to the lack of URL bar for the iframe. For an HTTPS site, the URL bar shows you that proper SSL is in place, with a valid server certificate, and it tells you the name of the server you are actually talking to. Remove the bar, and all kinds of nasty tricks become possible.

On the bright side, an HTTPS iframe, like a HTTPS target URL for a login form in an HTTP-page, is great against passive-only attackers (the kind of attackers who listens to all exchanged bytes but never injects anything on his own). It just happens that believing most attackers to be passive-only has become singularly naive nowadays.

As for user experience, the usual recommendation is simply to make the whole site HTTPS. It is much less expensive, from a computational point of view, than is usually believed. On a general basis, humans are not good at predicting performance issues. Performance is a matter of measurement, not guessing. I suggest that you try it out.

Also, as a user (albeit not necessarily a typical user), I kind of like the visible transition from HTTP to HTTPS. The checkout is about money, and, crucially, about my money. Thus, it is important.


Email from supposedly Apple (mycloud.ssl.com) I got an email where it says that Apple recently failed to validate my payment information and therefore they need to ask me to complete a short verification process in order to verify my account.

At the end of the email it says

  Copyright © 2016 Apple Inc. Apple Inc., Infinite Loop, Cupertino, CA 95014 Company Registration number: 15719. .

The email finished in @mycloud.ssl.com and I actually clicked on the link that they gave me.

I got this in my browser:

I know it is in Spanish but I'm sure you know this screen.
Did this screen avoided from attackers to take personal information?

Or is it already dangerous to have clicked the link?

If the link visible in the location bar of the browser is the same link you've clicked on then probably nothing dangerous happened.

But, it might be that the link in the browser is different from the one you've clicked on and that there were redirections and reloads before you've actually reached the site blocked by Google Safebrowsing. In this case it might well be that the attackers got notice that you've clicked the link and concluded that you might be a gullible person and that they will try this email again later. It could even be that they've mounted a drive by download attack to infect you with malware.


Double Submit Cookies vulnerabilities Is the Double Submit Cookies mechanism vulnerable anything other than XSS and sub-domain attacks?

All CSRF protection mechanisms are vulnerable to XSS, so that's nothing new. I'm just wondering if I can safely rely on this mechanism so long as I ensure I control all sub-domains.

NOTE: This question is a spin-off of How to protect against login CSRF?

According to a paper published in Blackhat 2013, it isn't enough for you to implement Double-Submit Cookies in its own sub-domain (e.g. secure.host.com). You really must control all sub-domains:

  2.1.1 Naïve Double Submit

  Double submit cookie CSRF mitigations are common and implementations can vary a lot. The solution is
  tempting because it’s scalable and easy to implement. One of the most common variations is the naive:

if (cookievalue != postvalue)
 throw CSRFCheckError

  With naïve double submit, if an attacker can write a cookie they can obviously defeat the protection. And again, writing cookies is significantly easier then reading them.

  The fact that cookies can be written is difficult for many people to understand. After all, doesn’t the same
  origin policy specify that one domain cannot access cookies from another domain? However, there are two common scenarios where writing cookies across domains is possible:

  1) While it’s true that hellokitty.marketing.example.com cannot read cookies or access the DOM from secure.example.com because of the same origin policy, hellokitty.marketing.example.com can write cookies to the parent domain (example.com), and these cookies are then be consumed by secure.example.com (secure.example.com has no good way to distinguish which site set the cookie).

  Additionally, there are methods of forcing secure.example.com to always accept your cookie first. What this means is that XSS in hellokitty.marketing.example.com is able to overwrite cookies in secure.example.com.

Secondly, this approach is vulnerable to man-in-the-middle attacks:

  2) If an attacker is in the middle, they can usually force a request to the same domain over HTTP. If an application is hosted at https://secure.example.com, even if the cookies are set with the secure flag, a man in the middle can force connections to http://secure.example.com and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies).

  Even if the HSTS header is set on the server and the browser visiting the site supports HSTS (this would prevent a man in the middle from forcing plaintext HTTP requests) unless the HSTS header is set in a way that includes all subdomains, a man in the middle can simply force a request to a separate subdomain and overwrite cookies similar to 1. In other words, as long as http://hellokitty.marketing.example.com doesn’t force https, then an attacker can overwrite cookies on any example.com subdomain.

In summary:

You must control all sub-domains.
You must set the Secure flag to ensure the cookies are only sent over HTTPS.
If you care about MiTM attacks, you must transition your entire website to HTTPS, set the HSTS header and ensure it includes all sub-domains. At this time, only 58% of browsers support HSTS (Internet Explorer being a notable exception). This is expected to change over the coming year.

See https://security.stackexchange.com/a/61041/5002 for a discussion of the token length and type of RNG needed to generate values.


Recover corrupted password protected Zip Good evening.
I have a password protected zip archive (Zip 2.0 CryptoZip) with a .txt file with sensitive info inside. The problem is that I can't extract it.

7Zip:"Data error : Wrong password?"
WinRar:"CRC failed in the encrypted file. Corrupt file or wrong password"

I'm pretty sure I enter the right password, because when I try any different passwords it just ends up with "wrong password".

I reproduced the same error by the following steps:

Created a password protected zip with a single txt file inside
Edited some of the bytes using Hex editor
Tried to extract the zip using my password and got the same error.

My question is simple: is there any way now to extract the txt file from this corrupted password protected zip?

I tried to "repair" the zip using WinRAR, Object Fix Zip, DiskInternals Zip Repair, Recovery Zip Toolbox, Zip2Fix. None of them could help me, the "repaired" zip is still broken and I get the same error.

Thank you.

If the ZIP file only holds that one TXT file, then I'm afraid chances of recovery are low.

Try visually inspecting the file's hex dump. A "true", undamaged ZIP file should contain high-entropy, random values (all the more so if it's encrypted too). If there are large swaths of repeated filler characters (0x00, 0xC0, 0xA9, 0xFF...), then that section of file is almost certainly corrupt.

On some systems (e.g. Linux console with no buffering) you can try and extract the file with unzip -c. This will result in the file beginning decryption and output, and failing as soon as it hits the corrupted block. The data up to that point will be extracted normally.

Special cases

A whole block of size 512, 1024, 2048 or 4096 bytes in the ZIP is empty (filled with zeroes, FFs, or the like). This is almost certainly due to the hardware support the ZIP file was on, going corrupt. The sector has been replaced by nulls. If you still have the original support you may try recovering that. If it was a hard disk, it was a bad hard remap of a damaged sector, and the data is lost (unless you can interface at a very low level with the disk itself, which is brand- and disk- dependent). Chances of recovery are essentially nil.
The ZIP file appears intact. No obvious blanks inside. There is a possibility: the file was transferred with CRLF conversion, and ALL its LF's have become CRLF's pairs. This happens once every 256 bytes on average and you can verify it by counting how many naked CR's, how many naked LF's, and how many CRLF pairs are in the file. If this is the case, you will have to locate all those pairs and remove the extra CR, and each time verify whether the decoding progresses or not. Usually, by re-zipping the partially recovered file (after truncating any ending garbage) with the same algorithm, you can come up with an intact ZIP file that you can compare with the damaged one to determine the position, in the ZIP stream, of the error (i.e.: if the zipped fragment is 7291 bytes long, then in the damaged zip file, at around offset 7291 relative, there is an error). I had this happen to me once, and was able to recover the file; I remember it took a whole night, though.


How is HTTP converted to HTTPS when no HSTS is present? Suppose you have a website http://example.com

Now, you also have an SSL certificate, which means users can access the site securely using https://example.com

But if I just write http://example.com in the address bar, how can the client get to convert it to https://example.com when it didn't use the HSTS response header (which forces the client to use https).

In other words, if I go to port 80, how am I redirected to port 443?

The site is manually redirecting you to the HTTPS version of the site, typically using the HTTP 301 redirect status code. This is not as secure as HSTS because it is vulnerable to a MITM attack, but it does cause you to transparently switch to the encrypted version of the site. This behavior must be configured in the server to work. The server can either be made to automatically perform the 301 redirect on all pages, or only for certain pages such as those with password input fields.
The client first sends a request to the non-encrypted version of the site:
GET /index.html HTTP/1.1
Host: www.example.com

The site then responds with a redirect:
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/index.html

This instructs your browser to send another GET request, this time to port 443 with TLS.
Note that, even when HSTS is used, this is still necessary for the first connection. HSTS headers are only allowed to be set over the HTTPS protocol, so a redirect is usually used to tell the browser to use the encrypted protocol the first time. Only after that will the browser remember that it should rewrite all requests to the encrypted version of the site without being told first.


X509 mutual authentication: is there a security flaw? On the client side, my application accepts the server's certificate in case of the client certificate being signed by this server cert. Is this correct or may it be dangerous? Is it better to ask a user to confirm security exception every time (e.g. like browsers)?

To clarify the question:
What I have: [server-cert][CA cert] (server chain); [client-cert][server-cert'] (client chain).
What the application does: if server-cert == server-cert', then the client trusts the server. I'm asking if this is correct behavior or it can cause flaws.

If the check you outline above is the only check made for authentication, then there are some major problems.

The check only tests the server's cert given to the client. The server never checks the client's cert. So no mutual authentication.
The client never has to prove knowledge of their private key
The server never has to prove knowledge of their private key

Furthermore, as pointed out by ewanm89, there are issues if the initial cert signing is not done over a secure channel.


Embedding a service subscription form (via iframe) in a landing page hosted by 3rd party - PCI DSS Complaince We have a SaaS application which requires the user to submit payment info upon sign up. Subscription fee is charge monthly. And we have to be complaint with PCI DSS.

Now, we are planning to use a marketing platform, such as hubspot / salesforce marketing cloud, to host our landing pages and automate our marketing effort on their platform. We wanted to embed our subscription form in an iframe on the landing page hosted on their platform. The landing pages will have a different domain origin (e.g. offers.mysaas.com) from the sign up form page (e.g. www.mysaas.com). offers.mysaas.com will only be allowed to render the sign up form via X-Frame-Options: ALLOW-FROM

In order to be complaint with PCI DSS, does the 3rd party landing page hosting service also have to be PCI DSS complaint? If not, is there any requirement that 3rd party service need to meet?

Thanks

In order to be complaint with PCI DSS, does the 3rd party landing page
  hosting service also have to be PCI DSS complaint?

Yes.

If you're talking about sending your customers off to subscribe via an iframe, you're probably hoping to manage your PCI Compliance under SAQ A.  Part 2f asks:

  Does your company share cardholder data with any third-party service
  providers (for example, gateways, payment processors, payment service
  providers (PSP), web-hosting companies, airline booking agents,
  loyalty program agents, etc.)?

and after you list them out, it reminds you:

  Note: Requirement 12.8 applies to all entities in this list.

which, among other requirements, asks:

  12.8.4 - Is a program maintained to monitor service providers’
  PCI DSS compliance status at least annually?

Someone like Salesforce is, in fact, a PCI-compliant Service Provider which as reflected in the Visa Global Registry of Service Providers.  Salesforce themselves has an answer in their knowledge base making it easier for their customers to get the attestations they need.


PSExec not working against windows XP (metasploit) I am following the book Penetration Testing: A Hands-On Introduction to Hacking from Georgia Weidman. In Ch 13, page 296 the psexec from metasploit is used against a Windows XP Profession SP3 (32-bit), but I got the following error:

Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with error: STATUS_LOGON_TYPE_FAILURE (Command=115 WordCount=0)

See above options for my exploit:

I have also set the windows xp machine to behave like part of a domain:
Start --> Run.. --> secpool.msc --> Security Settings --> Local Policies --> Network access: Sharing and security model for local accounts --> Classic - Local Users authenticate as themselves.

and set it up the SMBDomain to WORKGROUP. When using enum4linux, my user (shariff) is not enumerated, but this is the one that I use to login (I also have the hash for it but again not working). Does this suggest that there is some setting that is not allowing me to connect??

This is driving me crazy.. any suggestions or ideas to fix this? username and password is correct, but still login failure error. Is there anything that I am missing?? How I can test smb to see if I can login with my user??

Try setting the SMBDomain to a single dot "." or the system name rather than WORKGROUP and see what happens.


Is it possible to block third party cookies but allow them when they are first party? I have been using Cookie Monster in Firefox for a while now to great satisfaction. However, I haven't found a way to allow cookies like Google's on Google's services but block them when I visit other sites that integrate with Google (or Facebook etc.)

Safari blocks third-party cookies by default.  If you want to check your settings, click the gear icon and go to Preferences >> Security; under "Accept cookies", it should say "Only from sites I visit".  Click OK.

Firefox (without Cookie Monster) blocks third-party cookies if you untick the checkbox saying "Accept third party cookies".  You can get there from Options >> Options >> Privacy.

The RequestPolicy extension for Firefox can be configured to block those third-party requests (including cookies, but also the requests themselves).

Internet Explorer allows you to block third-party cookies.  Go to Tools >> Internet Options >> Privacy >> Advanced.  Tick the box labelled "Override automatic cookie handling".  Next to "Third-party cookies", select "Block".  Then click OK.

Opera allows you to block third-party cookies.  Go to Tools >> Preferences >> Advanced, select "Cookies" on the left, then select "Accept only cookies from the site I visit".  Click OK.

Chrome allows you to block third-party cookies.  Go to the wrench icon >> Options >> Under the Bonnet >> Content Settings >> Cookies, and tick the box labelled "Block all third-party cookies without exception".  Click OK.


Allow user to export data, what about security? We developers of course try to create the most secure (web) application out there that will not be hacked. While we already know it's impossible to know for certain that your application is secure, we at least do our best effort.

By choosing one of the big cloud platform solutions (Azure, AWS, Google) you at least know they do their best to keep hackers away from your web/database servers.

So, let's pick e-commerce for example: A lot of customers, a lot of personal data stored in one database and a lot of employees that want to "work" with the data.

Let's say Azure/AWS/Google does their job good at security and the developers do their job good at security. That means it actually comes down to your employees working with the data of all the customers.

You know, those employees who use the same password everywhere, ending with their birthday and a ! because some password fields require a special character. Those employees that would click on any link they receive in their inbox.

Most, if not all, web applications allow to export data. "I want to analyse last year's sales", "I want to analyse stock inventory". All valid reasons for employees to get your data in Excel and play around with the data.

Now what I am wondering, how do small to large businesses deal with security?

In theory, a employee could export all customer data, have it stored on their personal computer, the personal computer gets stolen and 5 days later an awesome database pops up online containing all your users information. Or these days it is not that uncommon for small and big businesses being hacked, so one of the employees could be the target where they are able to hack and get the data from their personal computer.

Do you:

Limit the employee in how much data it can export?
Somehow allow or deny access to exporting certain fields?
Enforce to always upload to a cloud storage like Microsoft OneDrive and educate the user not downloading it?
Use Active Directory while employees use their personal computers?
No export at all and provide dashboard graphs on-request?

What else?

The first questions to ask here are IMHO:

who is the owner of the data?
what is the responsability of each part?

For the first question the answer is the client not you. So if they want to publish their data on their facebook page, it is their problem, not yours. And as the owner of the data, they must be able to get it from you at any time, because they must be able to stop working with you and make business with someone else (not nice, but they can).

Your reponsability is to secure the data when it is holded by your application, and on the way between the client and the application. So you must make sure that you address the risks and threats that the client consideres important. In your example, choosing a big cloud platform is certainly a good choice for Availability, but did you considere Confidentiality? Can you say how many admins will be able to access the client data, and do you know whether it matters for your client? You say that you will do your best efforts to secure the application, but have you considered a third party security audit, depending on how much the client sees the security as important.

As an IT professionnal, you must also give advices to the client for all the processes where you are involved. Have you specified with the client the access levels if different persons can access the data, and the risks associated with each level? As you speak of poor passwords, have you spent some time to explain the importance of good passwords and have you proposed to pass automatic guess tools (John the Ripper for example) to control the weakness of passwords? If it matters, can you application log who retrieved what to later analyze the causes of a data leak?

IMHO, that is what you should feel concerned with, not what the client wants to do with their own data, beyond giving advices to them.


Implications of running script as argument to shell Context for the question is the following comment on one of my answers:

  @SergiyKolodyazhnyy Prefacing a script name with /bin/bash or even just bash is also a common way to solve the lack of executable permissions on the script.

I've refuted with the obvious remarks that there's danger in giving a potentially malicious script ability to do what it wants while file itself doesn't have executable bit set, and obvious incompatibility of script written for say c-shell being run with bourne-like shell ( and syntax incompatibility among Bourne-like shells themselves ).  And the way I see it in hindsight, it's almost close to faulty advise of doing curl somedomain/script.sh | bash.

However, I'm curious if there are potentially more severe implications.  I know that merely cat'ing a file can be dangerous and merely copy-pasting of a seemingly harmless script, but I'm curious if there's  anything not so obvious exists about running a script as argument to shell.

Not really. If someone can get you to run a malicious script -- whether with ./scriptname or with bash scriptname -- you're pretty much toast. Also, you shouldn't think of the execute permission as a protection against malware. Execute permission controls whether you are allowed to execute the script (via exec() and its relatives), not whether it is allowed to execute.


What encryption protocol is used by paragonie/Halite library by default? We're going to implement encryption between php server and python server. We decided to use paragonie/halite library (based on libsodium) on our php part. Python guy are asking what exact protocol from libsodium they should implement. And I don't know what to say them.

What encryption protocol is used by Halite library by default?

What encryption protocol is used by Halite library by default?

This is explained in the Halite documentation.

Halite uses XSalsa20 (the extended-nonce construction of the Salsa20 stream cipher) with a keyed BLAKE2b hash for the authenticator, Encrypt-then-MAC.

If you prefer to look at source code, see here.


When should I drop a packet with ICMP type 3, code 9 or 10, TCP RST, or TCP ACK? This answer says there are a few ways of dealing with a blocked packet at a firewall:

  At each of these levels a 1st IP packet (and any other protocol
  packet as an ESP or AH packet) might receive 4 types of treatment:

  the packet is simply dropped (not any form of reply)
  the packet is droped and an ICMP type 3, code 9 or 10 is returned,
  receive a TCP RST packet
  receive a TCP ACK packet

What is the difference between these choices, and when should I use them?

The difference is in the amount of information you provide to the sender of the packet.

says, essentially: "No-one here. Your SYN packet went to nirvana." It provides the least amount of information to the other end. It also slows down attackers because they have to wait for a timeout.
says: "Forbidden. There's someone here but they don't want to talk to you." It's the most helpful and polite response but may incite an attacker to try getting around the firewall.
says: "Port closed. The target machine exists but the port is not in use." It is somewhat misleading and may hinder network troubleshooting, or incite an attacker to proceed probing other ports.
says: "Port open. Will set up your connection." It doesn't make any sense to reply in that way to a blocked packet.

Which of these you choose is a matter of policy or personal preference. If you feel paranoid, choose #1. If you want to make the network administrators' job easier, choose #2. Personally I don't see much benefit in #3, and #4 is definitely out.


Does altering characters of a file url lead to another file? I have a link to a file which is stored in cloud:

  https://docs.google.com/file/d/0B8Tf19cw9c8SNnFPamhRWGFwaTq

(I have edited a character from the original for privacy)

So if the garbage string at the end is altered, what is the chance that a file stored in someone else's cloud gets accessed?

Is this possible?

The chance is N in 153,803,885,110,405,674,678,434,597,293,100,547,399,764,930,461,696 where N is the number of files stored under /file/d with public view permissions set (TY @Mike Ounsworth).

So, there's a chance, but it's not a great one.

The "garbage string" is a 28-digit name which appears to consist of uppercase letters (26), lowercase letters (26), and numbers (10).  So each digit can be one of 62 characters.  The number of possible combinations for that string are therefore 62^28.


Using ChaCha20 without Poly1305 Doing some lecture to choose a good configuration for my SSL certificate for my website (using a regular LAMP configuration), I'm wondering what are the possibles and secure alternative to poly1305 using the ChaCha20 stream cipher ?

And why I can't heard of ChaCha20 without Poly1305 ?

ChaCha20 and Salsa20 are stream ciphers. Their purpose is to provide confidentiality, as long as the key used to seed them remains secret. Poly1305 however is a Message Authentication Code (MAC), which is supposed to provide integrity and authenticity for the sent messages.

In general, it should be possible to use them separately as they do not seem to depend on each other (Poly1305 can, and does as far as TLS is concerned, use ChaCha20 as an underlying cipher, however). For example, the NaCl crypto library lets you do encryption using Salsa20, authentication using Poly1305 or authenticated encryption using both schemes.

However, it is not possible to use them separately with TLS. The reason for this is, that TLS uses a scheme to identify the combinations of Key Exchange Algorithm/Cipher/MAC called "Cipher Suites". As a client always sends all the cipher suites it supports in each "Client Hello" packet (the first packet needed to establish a TLS connection), all possible cipher suites are predefined, so a 2-byte ID is sufficient to represent a single cipher suite.

As RFC7539 states, the main reasons for including the possibility to use ChaCha20 and Poly1305 are to have an alternative to AES in case weaknesses are found and to have a fast alternative to use on slow hardware [Page 2].

You can see all the defined cipher suites and their representations at IANA's TLS parameter specification. Alternatively, have a look at RFC7539 (link at schroeder's comment to your post), which specifies all possible cipher suites using ChaCha/Poly.


GSEC or GCIH, for a Security Analyst? I've been with this confusion of getting a certification for a long time!! With the aim of becoming a Security Analyst/Tester, and for a good kick start, which one of these two is good?
GSEC or GHIC??
I took a look at the objectives of both these certs.
GSEC objects to end to end concept with a basic toolset/practical problems (IMHO)
GHIC objects to real problems/practical solutions.. (at least that's what i think).

P.S. I have some basic(Theoretical) understanding of security concepts

(Update) edit: omg!! i just took a look at their training program which costs $4000 !! real? also, i took a look at few gsec books at amazon and they were outdated.. so, is there a way to get a proper course-ware outside of sans and expect it to cover the syllabus?

I would say do both to be honest.

GSEC will give you the foundations that you need to know (similar to the information you would get from doing a CISSP) but it won't give you the knowledge you want to be a Security Analyst or Tester.

GCIH is all about incident handling and basic hacker techniques, and as your career progresses you'll learn that they are basic.

To be a good security analyst you need experience, but having those certs will get you on your way. I would also look at the OSCP offering by Offensive Security and the GPEN cert by SANS/GIAC.


Do incident response plans include playbooks? Do incident response plans include the playbooks or are the playbooks separate from the incident response plan?

The primary industry standard for playbooks is the Integrated Adaptive Cyber Defense (IACD) Research group, out of Maryland (John Hopkins).
These can constitute any type of cybersecurity response, at the event, alert, notable, or incident level -- for indications and indicators. Playbooks could be part of a CIRT (and therefore IR/DFIR planning), but they could also be part of other structures, such as Cyber Threat Intelligence, Threat Hunting, Security Operations, Security Engineering, Red Teaming, Cybersecurity Analytics, Cyber-Risk Management, and potentially many other specialty areas.
Playbooks are conditions, indicators, and controls that drive the need for cybersecurity responses [as] captured [via] orchestration services [for monitoring and execution].
Playbooks are process-oriented and:

Reflect an org's policies and procedures
List activities that may require human interaction
Made sharable from organization to organization

At the highest level of abstraction, playbooks are a set of process
oriented steps that enable an organization to meet the requirements
specified in their policies and procedures. They are a set of human
understandable actions that document an organizational process
performed in response to a cyber-event or other defined trigger
condition. Playbooks are meant to be generic enough for broad
applicability between organizations while detailed enough to meet
specific situations. Playbooks may invoke other playbooks, operate
either serially or in parallel, or initiate a workflow depending on
the situation or conditions facing the system.


Expert quote on entropy for uncrackable password Could anyone point to a quote in a published work - or suggest a recognised expert who might provide a quote - which answers the following question

  How much entropy in a password would guarantee that it is secure against an offline guessing attack even if the attacker has the most powerful hardware in the world?

I am writing an article about creating a secure password based on true randomness and I would like to include a figure for guaranteed security but I would rather not offer my own opinions and arguments, I would like to quote a recognised expert or published work.

In more detail what is meant above by these terms is as follows.

If a password has enough entropy then presumably it is uncrackable in our current threat model, which is the one where the attacker has a cryptographic hash of the password and is repeatedly making a password guess, hashing the guess and comparing the hash.

By entropy I mean that the password creator has chosen randomly, with equal probability for each choice, a password from N possible passwords.
The entropy in bits is then log₂(N)

So quote needs to cover how much entropy in bits (or how big is N) to guarantee that the password is secure against this kind of attack, even if the attacker has the most powerful hardware in the world.

There's a quote for you in this crypto.SE answer, by Bruce Schneier in Applied Cryptography (1996), pp. 157–8.

You can also find Bruce Schneier citing himself in his blog (2009), if you want an online citation.

Here is the full quote, in case of the links breaking:

  One of the consequences of the second law of thermodynamics is that a
  certain amount of energy is necessary to represent information. To
  record a single bit by changing the state of a system requires an
  amount of energy no less than kT, where T is the absolute temperature
  of the system and k is the Boltzman constant. (Stick with me; the
  physics lesson is almost over.)

  Given that k = 1.38×10-16erg/°Kelvin,
  and that the ambient temperature of the universe is 3.2°Kelvin, an ideal
  computer running at 3.2°K would consume 4.4×10-16 ergs every time it
  set or cleared a bit. To run a computer any colder than the cosmic
  background radiation would require extra energy to run a heat pump.

  Now, the annual energy output of our sun is about 1.21×1041 ergs. This
  is enough to power about
  2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a
  Dyson sphere around the sun and captured all of its energy for 32
  years, without any loss, we could power a computer to count up to
  2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

  But that’s just one star, and a
  measly one at that. A typical supernova releases something like 1051
  ergs. (About a hundred times as much energy would be released in the
  form of neutrinos, but let them go for now.) If all of this energy
  could be channeled into a single orgy of computation, a 219-bit
  counter could be cycled through all of its states.

  These numbers have
  nothing to do with the technology of the devices; they are the
  maximums that thermodynamics will allow. And they strongly imply that
  brute-force attacks against 256-bit keys will be infeasible until
  computers are built from something other than matter and occupy
  something other than space.

Update: If you want a citation to assess the strength of a randomly generated password, you can use this website that is regularly updated with recommendations made by different institutes. A random password is equivalent to a symmetric key, so this is the value you are looking for. (Here is a wayback machine link, if this website were to close.)


Digital signature using only x509 certificate Is it possible to digitally sign a document only with a x509 certificate (ie public key)?

We received a question from one customer saying that they wanted to sign a document using only a certificate. Is it possible?

I understand that the private key is needed in order to sign. The only case that I think this holds is that if the x509 certificate has embedded the private key, right?

In that case, even though it is password protected, if I hold that certificate I turn myself into the Single-Point-of-Failure if someone compromises my server and their password they can sign any document in their behalf. So, is embedding the private key less secure and it does not allow the public distribution of certificates?

Thanks!

No, but.

Yes, technically you sign (or decrypt) with the privatekey, not with the certificate itself. And a publickey certificate never contains the privatekey.

But a lot of software, and thus documentation, and other description, blurs this distinction. We generally use a privatekey with a certificate (with the exception of SSH, where we attach limited metadata -- a host name or address, and sometimes other restrictions -- directly to a publickey), and the certificate part of this combination is more understandable and interesting to humans.

For example, the Microsoft Windows "Certificate Manager" displays things that are labelled "certificates" organized into things labelled "stores". You can have entries that are simply certificates (for someone else, usually a CA) or entries that are certificates with a privatekey attached (for yourself, or someone you are acting on behalf of). The fields of the certificate are displayed and at least some are meaningful to people: the subject name(s), the validity period, the issuer, sometimes the keyusage and/or extendedkeyusage. (Perhaps the transparency SCT(s) -- well, no, probably not. :-) The privatekey when present is not displayed (for security) and if it was it would be weird incomprehensible gibberish to 99.99% of users.

When you want to sign your email with Outlook, you go to a "Certificate Manager" window and select a "Certificate". Outlook includes this certificate in the outgoing email, and when the recipient displays that email their MUA shows it was "signed by the owner of certificate X" often elided to simply "signed by certificate X". Outlook did in fact use the privatekey to sign as well as putting the matching cert in the message, but the users see and identify and focus on the cert not the privatekey.

This is also reflected in the API; to actually do signing (or decryption) in Windows you get an object of type X509Certificate2 either from the store or by loading a PFX/PKCS12 file, which actually contains both the certificate and the privatekey.

MacOS keychain is similar, for certs with or without privatekeys (it also does passwords, which are different).

The same is true for TLS/SSL/HTTPS server and optionally client auth -- the privatekey is used internally, but the user(s) and admin(s) see and choose and think about the certificate. This definitely includes IE and Edge, and Chrome on Windows, and to my understanding Safari and Chrome on Mac. Firefox (and NSS) uses its own "cert database" instead of the system one, but it also describes and displays the entries as certificates whether or not they have privatekeys attached.

We often (IME) do the same for certificates themselves, which are also signed objects. For example, a few years ago people experienced trust issues with Google's (then) internal CA, "Google Internet Authority 2", because of the timing of some cross-CA bridging certs, IIRC between Equifax and Geotrust (or maybe the reverse). In answering some of those Qs I believe I talked about, say "this google cert X signed by this other cert Y". That is technically incorrect; to be exact I should have said "this google cert X signed by the abstract entity which is or at the relevant time was the verified owner of the cert Y using the privatekey which is part of the same keypair as the publickey that is in the cert and owned by the same owner as the owner of the cert and generated as a mathematically related unit". If I had done so, and repeated this 5 or 10 times for all the needed links in the cert chain, I would probably never have completed a single answer because it would have been too much work. To someone who knows how public key crypto works, "cert X signed by cert Y" is easily understood even though technically wrong, and to someone who doesn't know, it doesn't make any difference.

BTW, Java goes the opposite way. It has "keystore" files (or sometimes nonfile storage like a PKCS11 token) that can contain (either) lone certs for others, usually a CA, or privatekey-plus-cert entries for yourself. People get these confused just as easily as they do the Windows/Mac/FF approach; I personally have answered at least a dozen Qs here and related Stacks from people who imported a lone cert to their Java keystore when they needed a privatekey plus cert.

GPG traditionally has a "key ring" which contains publickeys with added metadata and (canonically) signature(s) that are in effect certificates, though not called that, and (matching but separate) "secret" keys which are really privatekeys. (This follows PGP, which was designed back in the 1990s before the privatekey-vs-secretkey terminology was settled.) OTOH its newer GUI Kleopatra calls them (together) certificates. Pick your poison.


Phishing attack stuck with jsp loginAction.do page? I'm testing a phishing website on a staged replica of an jsp web-application. I'm doing the usual attack which involves changing the post and action field of source code to divert to my own written jsp script capture the logins and redirect the victim to the original website.

It looks easy, but trust me, it's has been me more then 2 weeks and I cannot write the logins to the text file. I have tested the jsp page on my local wamp server it works fine. In staged, when I click on the ok button for user/password field I'm taken to loginAction.do script. I checked this using the tamper data add-on on Firefox. The only way I was able to make my script run was to use burp proxy intercept the request and change action parameter to refer my uploaded script.

I want to know what does an loginAction.do? I have googled it - it's quite common to see it in jsp application. I have checked the code; there is nothing that tells me why the page always points to the .do script instead of mine. Is there some kind of redirection in Tomcat? I like to know. I'm unable to exploit this attack vector? I need the community's help.

You are trying to do a MITM attack by copying the files from the Google login page? We cannot help you. There are too many variables to consider and then this question becomes far too localized to your situation.

Check out SET for better, more complete methods of doing what you propose, and you will learn far more than the mini-tutorial you linked. Look through the SET code once a fake page is set up and you will learn far more.

For deeper knowledge, flip through The Web Application Hacker's Handbook. It is more detail than you need right now, but is the bible for web application hacking.


Hashing password to increase entropy Is it secure to hash a password before using it in an application to increase password entropy?

Does this practice increase entropy when a PBKDF is used in the application itself or does the PBKDF itself increase the password entropy?

If a random password is hashed with md5 will the output provide a 128 bit entropy?

EDIT: It is meant to use the result of the hash function as a password for cryptographic functions and applications like AES-256, email and access to computer systems.

The procedure used will be password -> hash of password -> application

EDIT 2: E.g if an email application requests a password during registration, the intended password will be hashed locally before being provided to it.

No, you don't increase entropy by hashing it once, or twice, or ten times. Consider entropy as it is seem from the input, not the output. You cannot add entropy using a deterministic process, as the entropy of the result does not count.

Even if you have some code like this:

$password = "123456";
$result = md5($password) . sha1($password) . hash('gost', $password);
echo $result;  //   e10adc3949ba59abbe56e057f20f
// 8941b84cdecc9c273927ff6d9cca1ae75945990a2cb1f
// 81e5daab52a987f6d788c372

And you end up with a scary looking 136-byte string, the password is still 123456, and any attacker bruteforcing your hashed password will have to try, on average, only once, as 123456 is the top worst password on almost every single list.

  If a random password is hashed with md5 will the output provide a 128 bit entropy?

No, MD5 is deterministic, so if the attacker knows the string is a MD5 hash, the entropy of it is the entropy of the random password you supplied.

To make the password more secure, use a proper key derivation (PBKDF2 is a good one), ask the user for a longer password, and check if the user is following basic password rules (no chars repeated in a row, proper length, mixed digits and chars, mixed case, things like that).


Is there a protocol that provides data integrity, but not encryption for HTTP? HTTP
I'm aware that HTTP sends plain text over the network which can be sniffed and modified if a MITM is performed.
HTTPS
On the other hand, HTTPS sends encrypted text over the network that can neither be sniffed nor modified.
Other?
I'm wondering if there is an in between where the traffic can be sniffed, but not modified. I was thinking the server could just sign every packet using a CA.
I'm also aware of manually verifying hashes of files downloaded, but seeing as those hashes are served over a modifiable means (HTTP), it doesn't seem that this really provides any authenticity as the hash could modified to match the modified file. As @mti2935 suggested, the hash could be sent over HTTPS, but I'm looking for a preexisting protocol to handle all this.
Why
I'm sure this question begs the question why.  So here are a few example scenarios.

A user wants to allow their network security device to scan files downloaded for malware without having to modify their trust store.
I'm a ham radio operator and I'd like to stream movies over ham bands, but I'm not allowed to encrypt.  I do care about the video maintaining it's integrity, but I don't care about someone else snooping.
Sites that only distribute data and don't need encryption but do need data integrity.

SSL/TLS before 1.3 has some 'with-NULL' cipher suites that provide NO confidentiality, only authentication and integrity; see e.g. rfc5246 app C and rfc4492 sec 6 or just the registry. These do the usual handshake, authenticating the server identity using a certificate and optionally also the client identity, and deriving session/working keys which are used to HMAC the subsequent data (in both directions, not only from the server) but not to encrypt it. This prevents modification, or replay, but allows anyone on the channel/network to read it.
These cipher suites are very rarely used, and always (to the best of my knowledge) disabled by default. (In OpenSSL, they not only aren't included in DEFAULT but not even in the otherwise complete set ALL -- to get them you must specify (an) explicit suite(s), the set eNULL aka NULL, or the set COMPLEMENTOFALL, which last grates horribly to any mathematician!) I very much doubt you'll ever get any browser to use them, and probably not most apps or even many packaged servers. But if you control the apps at both ends of an HTTPS connection -- or perhaps proxies for the apps -- this does meet your apparent requirement.
TLS 1.3 changes how cipher suites are used, and no longer has this functionality. As time goes on, 1.3 will become more widespread, and it is likely 1.2 and 1.1 will be dropped in the foreseeable future. (1.0 already has been dropped many places, though not all. SSL3 is badly broken by POODLE, and dropped essentially everywhere.)
Belatedly found dupe, from before 1.3: Can TLS provide integrity/authentication without confidentiality


Can an app access location services when I turn off location services? An app I'm using requires me to grant it the permission to track my location, which I grant.

But, if I manually toggle off the device's location service (for example in the settings or the drop down menu that appears when swiping down from the top of my screen), can the app still access the location service?

I know that the app might use other methods to track my location, like IP, but I'm asking specifically about the device's location service.

No, because ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permissions can't turn on and access location services if they are disabled (assuming your phone isn't rooted). However, the app could still try to enable location services or find your location with other methods.

Vulnerabilities have existed to turn on location services without user interaction, however there is no intentional way to enable GPS programmatically without user interaction.

Without allowing the location permission, apps can still see your external IP address and router BSSID. Your IP address can be used to
 try to find your location which will probably only be accurate to the city / region (iplocation.com).

Your router's BSSID could be used to find a more accurate location if somebody has used a wardriving service like Wigle to map out your WiFi network location on Wigle's global map. This would allow the app to enter your BSSID into Wigle's API and find a precise location. If you were to have enabled location services, the app could gather BSSID addresses of networks around you for a more accurate location.


pcap files for simulated attacks on SCADA systems? I need to get hold of some pcap files belonging to a simulated attack on SCADA systems. My goal is to then use Snort for the detection. Or if somebody can suggest a practical environment to create my own (there is time pressure), that would also be appreciated greatly.

Does anybody have any files at all?

If you want pcaps from scada traffic you can go to http://www.netresec.com/?page=PCAP4SICS. On the other hand, if you want to simulate a specific attack probably the best option is to use scapy to generate the (modbus, mqtt, coap or whatever) traffic yourself.


Bitlocker lock drive on standby or switch users Is it possible to autolock a drive with Bitlocker when the laptop goes on standby or sleep mode?
Or when the user is changed?
I want the drive to be accessible only by one user.

This is not what Bitlocker is for.

Full Disk Encryption (FDE) tools like Bitlocker are only meant to protect against off-line attacks. This is where the computer's operating system is not running.

Examples might be if the disk is removed and mounted in another computer, or if the computer is booted from a LiveCD or similar.

When the OS is running - which includes when the laptop is in standby - then it is the OS's job to protect the contents of the disk.