Netdiscover running on NAT interface not finding IP addresses on host-only network? I am practicing penetration testing techniques using Kali Linux (most recent distro) and various vulnerable virtual machines (DVWA, Metasplotiable).  My attack and targets are all running via VMPlayer.  The attack machine is on a NAT interface to enable access both to the internet and the targets, which are on the host-only network.  These networks are virtual networks via VMPlayer.

Netdiscover does not seem to find the IP addresses of the target machines (using sudo netdiscover -r 192.168.0.0/16).  The only IP's returned are the VMWare virtual network cards.  However, when I simply ping the IP, or use NMAP, I find that the host is up and responding (I am able to find the IP by logging into the target directly and using ifconfig, but obviously in a real pen test you cannot do that).

I realize I could use NMAP to scan the range of IP's, but it's slow, and I have successfully used Netdiscover in the past.

What could I be doing wrong?

Netdiscover finds IP addresses using the Address Resolution Protocol (ARP), which matches IP addresses to MAC addresses.  However, ARP by design will not cross network boundaries (see for example at https://superuser.com/questions/1003990/vmware-nat-not-populating-arp-with-ip-mac-from-vmware-host-only).  Therefore, there is no response to the ARP requests from Netdiscover from machines that are on the host-only network when a query is sent from the NAT network.

NMAP and Ping use different protocols which are supported across the virtual network.  This answer was confirmed by using Wireshark and then placing the attack machine on the same host-only network.  When the attack and target machines are on the host-only network, Netdiscover worked fine.

The issue is not with Netdiscover, but with the virtual network.  This issue turned out to be virtual networking and not information security, but other security testers may have similar concerns as they work on virtual networks, therefore answered here.


Is it safe to create a user account using the id_token provided by google's sign in? I have a chrome extension which allows users to exclusively login with google and no other provider.

In my (node + couchdb) backend I need to construct a user account from the auth Response provided by google's oauth2 api. I was thinking about using a hash of the id_token as a password after verifying the token using the tokeninfo api

I realize that the id_token changes from time to time. In that case I was hoping to update the user's password automatically.

Here is the flow I had in mind:

User signs in on the front-end and gets an id_token from google
Id token is sent to the server and verified using the tokeninfo api
If verified, a user account is created with a password being the hash of the id_token.

Do you see any security holes with this flow? If so, what are the alternatives?

Probably not.

The information provided by that endpoint is fairly deterministic in nature, so anyone with enough motive (e.g. has 20 minutes to kill) can guess the details and generate the same password as you for that user. Additionally, that hash will fail every time (or often enough) a new token is issued, so you need to always keep the record updated.

The basic process of registering the user works reasonably well, but what you need to do is generate the password randomly and figure out how to store it securely and send it to the client for it to use.

Now, if you can have CouchDB verify the token itself verbatim then you could just send that, but I'm guessing it doesn't have the ability to do that.


Identify the attestation certificate (X.509) in Fido U2F registration response I'm trying to identify the attestation certificate (X.509) in Fido U2F registration response as described in fido-u2f-raw-message-formats-v1.0-rd-20141008.pdf document:

  An attestation certificate [variable length]. This is a certificate in X.509 DER format. Parsing of the X.509 certificate unambiguously establishes its ending. - page 5

I need to know how can I get its length and identify all its fields.

The U2F Raw Message Formats document specifies that the attestation certification is encoded using the Distinguished Encoding Rules (DER). The DER are Tag-Length-Value (TLV) style binary encoding. Thus, you only have to read the first DER unit - and only the TL part of it (i.e. just a few bytes). Decoding the TL part of it gives you the remaining length of the certificate.


Is Nessus approved for PCI Scans? Question is in the title. I can't seem to find a straight answer and Tenable seem to be dodging a yes/no answer on their website. I was told a few years ago that Qualys was approved by PCI for PCI compliance, and that Nessus at the time was not. Has this changed?

11.2.1 Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel.

For internal scans you could use Nessus as long as you have documented procedures and the personnel are "qualified."

  11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

For external scans, the scanning must be performed by an approved scanning vendor (ASV). You can find the list of ASVs at https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors. In that case Nessus would not be usable by your own organization, as an ASV must be a third party.


How to pass cipher list to OpenSSL s_client How we can pass a cipher list to the OpenSSL s_client program?

We can pass single cipher by this:

openssl s_client -cipher 'ECDHE-RSA-AES256-SHA' -connect www.google.com:443

But how to pass a list of multiple ciphers?

As Steffen Ullrich has mentioned, you can pass a list of ciphers to the -cipher option of s_client. This is not a single item, but a specification and can also be used for the nginx ssl_ciphers option, or the Apache SSLCipherSuite option.

You can pass multiple ciphers using a space, comma or colon separator. Example:

openssl s_client -cipher ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-GCM-SHA384 \
    -connect example.com:443

The above list specifies two specific ciphers. A group of ciphers can also be passed. Here is an example of a cipher list specification that requires authenticated empheral ECDH key agreement (ECDH), RSA for authentication and only cipher suites that are considered of "high" encryption:

openssl s_client -cipher ECDH+aRSA+HIGH -connect example.com:443

What does this expand to? The openssl ciphers command can be used for this purpose:

$ openssl ciphers ECDH+aRSA+HIGH
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA

or more verbosely:

$ openssl ciphers -v ECDH+aRSA+HIGH
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1

For more information, read the ciphers manual page.


How is this MITM attack being performed and what steps can I take against it? Today, when I tried to access the internet (google on HTTPS), my browser (Google Chrome) gave me the following error:

I am on my own home Wi-Fi, which has WEP. When I tried to reload google on regular HTTP, I got redirected to

http://ezp-prod1.hul.harvard.edu/search?q=<search term>&...

which gave me a 404 error. Sites other than google seemed to work fine.

I assumed this was a MITM attack and so I changed the WEP key on my router and rebooted it. However, minutes later, the error page and attack was back.

My questions are:

How is the attacker still able to connect to my wi-fi, even after I changed my router's WEP key? I don't think it's possible to crack a WEP key in minutes, despite WEP's insecurities.
How is the MITM attack being made? Specifically, how can the attacker insert themselves between my computer and internet servers?
How can I prevent this from happening, now and in the future?
I am still under this attack, now using tor. Can the attacker still read data sent over SSL through tor?

If you are using a windows PC, run:

ipconfig /all | more

Which DNS servers come up? Your ISP's, Google, OpenDNS, or some unknown/unexpected IP?

If unexpected DNS IP, that's probably the answer. Either your router has been hacked and is serving a bad DNS IP over DHCP (for a DNS server that is redirecting you to the wrong place), or your PC has been reconfigured (by malware) for the same...


Renew letsencrypt certificate on jetty I successfully renewed my letsencrypt certificates. But, now, I need to feed my truststore with the new certificate for Jetty to accept it.

2 months ago, when I studied this whole letsencrypt certificates, I left a note to myself, saying:

//After each renew, do:
openssl pkcs12 -export -in /etc/letsencrypt/live/mydomain.fr/fullchain.pem -inkey /etc/letsencrypt/live/mydomain.fr/privkey.pem -out server.p12 -name mydomain
keytool -importkeystore -deststorepass xxxxx -destkeypass xxxxx -destkeystore server.keystore -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass xxxxx -alias mydomain
keytool -import -file /etc/letsencrypt/live/mydomain.fr/fullchain.pem -alias mydomain -keystore myTrustStore

That is what I did, but when I go to my web page, I still get an error saying that the certificate has expired.

What am I missing?

Edit:
After

keytool -list -v -keystore server.keystore -storepass <<password>> | egrep "Alias|Valid"

I get

Valide du : Thu Oct 06 13:54:00 CEST 2016 au : Wed Jan 04 12:54:00 CET 2017
Valide du : Thu Mar 17 17:40:46 CET 2016 au : Wed Mar 17 17:40:46 CET 2021

Try the following command to check the expiration dates of the certificates in the keystore

keytool -list -v -keystore server.keystore -storepass <<password>> | egrep "Alias|Valid"

This should tell you if the new certificate is in the store with the valid dates you expect.

If the certificate is present and valid then check the following

  If you imported the key and certificate originally using the PKCS12 method, use an alias of "1" rather than "jetty", because that is the alias the PKCS12 process enters into the keystore.

This is documented in the jetty documentation about renewing certificates found here.


Efficient way to demonstrate the value in Active Directory security improvements? Working hard on Active Directory security in a corporate environment: getting rid of excess permissions, monitoring, patching, etc.  Nothing comes free, and to keep the budget going, I need to somehow explain these improvements to the C-level.  They like charts and quantifiable data, which makes this task easy for Sales, but difficult for us in IT Security.

The executives understand the phrase "decrease exposure to security risks", but this is obviously not enough.  And I can't realistically take them to a room and show what's a pass-the-hash attack.

So, how do I demonstrate to the value in Active Directory security improvements?

You have two basic things you need to address:

1) Do you meet the current best practices for Information Security in your organization?

There are several good resources including the Microsoft Security Baseline Analyzer, and using resources such as NIST and SANS.

If your organization is large enough for an AD environment, they likely need and should have insurance in case of data loss. Most insurance agencies require a certain baseline otherwise your SOL at claims time and good luck with litigation.
Back to litigation, piss poor standards also set your organization up for negligence lawsuits from multiple sources. E.G Employee, Customers, Venders, etc. If the C-Level was made aware, did nothing, and tried to blame you or your team, you'd also have wrongful termination suit, etc.

2) What are your risks?

Information Security is very much like financial risks, you need to understand your goals, what's acceptable to your organization, and what you need to reduce. We tend to look at this through quantitative and qualitative risk.

To be frank, C-Levels don't really care about a specific attack being averted, they care about specific risk being reduced to manageable levels. For instance, you don't tell the CEO that you improved security by requiring and only using Third Party SSL certificates from verisign or wherever. You tell them you have reduced the risk of MITM attack and implemented policies to manage the risk. The third party certificates are quantitative representation of that risk and your servers which use it are its exposure.

BTW, this not trying to skirt around an issue or that your C-Level is to dense to understand SSL/TLS. It's communicating to them in the language they are familiar with and any good business person deals in risk.

For your particular example, making permissions easier is a technical function to reducing what risk:

reducing provision issues which expose additional risk?
exposing privileged information to unauthorized users?
all of it?

These are the items they want to hear about, what changes you make are your data for reducing that risk, also this is an extremely simplified way of looking at this.


Subdomains - Security Risk? I have just checked and found that I have a number of subdomains live that re-direct to sites which I don't recognise.

Is it possible for a 3rd party to own a sub-domain of my site?

From a security POV, should I be worried about these sites?

Is it possible for a 3rd party to own a sub-domain of my xxx.com site?

No, other folks cannot own register subdomains for a domain which you have already registered.

Here's the ownership tree.

The domain name (e.g. example.com) is registered by you with a Registrar. (e.g. Namecheap, Network Solutions, etc.)
On the registration, you can designate Nameservers. (DNS Servers) The nameservers provide a listing of subdomains, and where they are hosted.
For every subdomain, there is a designated Host. The Website and Email can be hosted separately, and you can also have separate Hosts for each subdomain if desirable.

  I have just checked and found that I have a number of subdomains live, which re-direct to sites which I don't recognize.

In your case, it sounds like either a) someone has added subdomain entries to the DNS so that they are hosted elsewhere, or b) the subdomains could be hosted in the same place as your main site, but something about the website configuration is causing the redirects you describe.

  From a Security POV, should I be worried about these sites?

Yes. Since this is your domain, and you control the Registration, (#1 above) you should be able to dictate what happens to all the subdomains. If you are unaware of these, you should get some IT person involved who can determine whether the faulty entry is at the Nameservers, or the Host, and help you to resolve the problem.

Feel free to ask additional questions if that would be helpful to you.


How could a scammer get my card details if I've never used it Today I had about $600US spread across 20 transactions taken from my debit card over the past three days (I notified my bank said they will give me a new card and will refund me)

This particular account I only use to transfer money in and out of to get bonus savings interest; I have never used it to make purchases online, the card has always been left in a draw and never been taken out of the house. I have never entered the card details into any form, nor stored the card details anywhere.

Given I have never entered the card details anywhere to make a transaction, and neither has the previous versions of the card ever been used, how could this have happened? I have never stored the card details anywhere.

Its unlikely the scammer could have enumerated card details (start from 0000-...-0000; 01/01 for expiry date and 000 for cvv and increment) as they would have also needed to get my billing address correct.

Thieves get card numbers and expiration dates from somewhere it is stored or processed.

That could be a local with access to your home, access to the originating bank that issued the card, the post office, or any merchant processor along the line.


What is encryption key reset and why it is safer than zero-write? I am about to return my ThinkPad laptop to my (former) employer. I found a very nice solution to erase / protect my private data -- ThinkWipe application in ThinkPad's BIOS. I made use of it right away.
However, to my kind of big surprise, it told me that:

2 seconds long encryption key reset is a safe method,
15 minutes long zero-write (single pass) isn't considered a safe method.

I'd like to update my knowledge in this area.
What is encryption key reset? Doesn't this simply mean that currently used (and valid for decryption) key will be replaced with some random one (and not valid for data decryption)? If that's true then this mean that my data is still there, encrypted of course. Doesn't this mean that if someone would figure out my "old" key or somehow could reverse encryption key reset process, would again gain access to my data.
Anyway, even if I am blind here, this still doesn't change the fact that my data is kept untouched (there is no way that 2-second long process is able to erase entire disk). How then this method can be considered safe while method of replacing every bit of data with zero isn't safe?
I understand that single-pass zeroing isn't "that safe" and only 3-pass can be considered as safe. But... still... I don't get how it isn't safer than just ecnryption key reset.
I have read this question, but it doesn't seem to be fully answering my question here, because it says pretty much nothing about encryption key reset.

Time spent on an operation does not necessarily relate to effectiveness of said method. Simply copying a file to an external drive is much faster and will yield better results than converting it to base64 and then typing it in.
Why is an Encryption Key Reset secure?
Essentially, it means you are okay with the attacker gaining access to your encrypted data, believing that they will not be able to decrypt it. While this sound strange at first, keep in mind that every sensitive information you have ever transmitted over the internet - ranging from your online banking credentials, over health-related data to pictures of your genitals - has undergone this exact process, and we still consider it secure.
We assume that AES-128 and AES-256 is in fact so secure, that without the secret key being known, it is physically impossible to recover the data That's right - we're not talking about statistics anymore, we're talking about physics. Thermodynamics, to be exact. There isn't enough energy in the universe to recover it. And AES has been around since 1998 and it shows no signs of weakness yet.
So when you do an Encryption Key Reset, what you actually do is just delete or overwrite a very small (128 or 256 bit) piece of data. You can do that countless times, very very quickly. As you yourself said, it only takes 2 seconds. I'm sure that after thousands and thousands of writes to the location of the key, it's not recoverable anymore.
Why is zeroing out a drive insecure?
Essentially, you're going down the hard route here. If your data is encrypted already, then zeroing it out or overwriting it with randomness is essentially redundant. Without the key it becomes unreadable anyways, as mentioned above. Zeroing it out certainly doesn't make it less secure, but it won't make it more secure either (practically speaking). What you actually end up doing by zeroing it out is adding wear to your storage, which is particularly bad with SSDs.
Now where zeroing something out is indeed less secure is if the data is stored in plain text, and you're trying to destroy it by overwriting it. Now, the question whether or not a single-pass of zeroing is enough to destroy the data permanently is being debated. Some say it's perfectly fine, others say that specialists can recover the data. I'm not an expert when it comes to forensics, so I will say "Some people claim that a single-pass of zeroing is not enough to fully erase all data" - which is the only factual statement I can give in regards to that.
In the end, zeroing out the key is probably the better method, for various reasons:

It's a lot faster.
It doesn't wear your storage device out.
It's just as secure.
You should use Full-Disk Encryption anyways.


What are the security benefits to block all http referer header requests for web browser? I would like to know also if you lose site functionality.

Is this a security benefit that is beneficial than compromising functionality (if compromising at all)?

What I mean by this is one a client side, home network. Does blocking any and all http referer  requests benefit the user in privacy? Will sites loose functionality if you do so?

Is this a security benefit

It serves no real security purpose, but it serves a privacy purpose.

By blocking the referrer then the sites you visit will not know what site you were previously on (maybe my visit to a clothing website was due to a link I found on a deviant sexual forum discussing how the clothing company has a sale on?).

A lot of companies especially commercial businesses analyse where traffic is coming from to their site, so the prospect of someone seeing a referring page URL is higher than you might think.

Often of course you will have got to the site with your search engine, so the search engine terms will typically be in the address bar and will be accessible to the site. If I searched "how to trick speed cameras" and the most relevant page was on my local police force's website talking about "speed cameras" where they list "how" many they have rolled out and how the new models are harder to "trick" then the search engine might have thought my terms were relevant but I have provided information I did not wish to share with that site (even though I am not ashamed of my choice of search engine, it's the URL which is private).

Finally, to use Tomasz's internal example but to use a scenario more likely, if you got to the link via a company web-page (http://ibm-intranet/Bus_Companies) then it reveals more information about me than I had intended (the fact I potentially work for IBM) to the site I visit.

For me the HTTP referrer represents no risk, but others may feel more comfortable blocking it.

  Will sites loose functionality if you do so?

Some sites hate hot-linking to images or files, so they will not allow access to images or files unless the HTTP Referrer states it came from their site and not some other site that happens to be using their resources (both the content and bandwidth) in a way it was not intended.

This wiki link about Referer Hiding (spelt incorrectly in the standards so "Referer" is correct) may be of interest


How does a trusted maps.googleapis.com in CSP enable an XSS vulnerability? (JSONP) I am testing out the tool CSP Evaluator, and have a question regarding the following content-security-policy:

  default-src https://maps.googleapis.com

The tool consider this as a high risk:

  maps.googleapis.com is known to host JSONP endpoints which allow to
  bypass this CSP.

My question is, how can a trusted maps.googleapis.com be exploited to perform an XSS attack?

Consider if something like this was attempted by an attacker injecting XSS:

<script src="https://maps.googleapis.com/foo?callback=alert"></script>

This would execute the foo function from the Google APIs JavaScript SDK, and upon it's return would call the alert. This demonstrates that an attacker would be able to inject inline code into the page, which would be executed. Therefore XSS is achieved which bypasses the blocking of unsafe-inline code.

Of course, what can be called would depend on the arguments passed and how exactly Google sanitise the callback parameter. It appears that CSP Validator just has a simple rule to flag these in the form "does the domain in the CSP support JSONP?" which does not take into account how the callback is executed.

This seems fair, as CSP Validator will never know if any code alterations on the external domain ever introduce or patch such vulnerabilities so I think it is correct that this is flagged.


How less secure is an encryption if we know something about the original data? I have a number of files encrypted with a key derived from a password. In line with standard practice, I use a random salt and password and do many PBKDF2 iterations to obtain an encryption key and IV. I then use this to encrypt the data with AES-256 in CBC mode.

In what ways could the security of my data be compromised if an hypothetical attacker knows that the first bytes of every plaintext file are a fixed string such as "abcdef"?

If knowing part of the plaintext gives an advantage to the attacker in its efforts to guess or recompute other encrypted bytes, or the key itself, then this is considered a serious weakness of the encryption algorithm. No such weakness is known for AES.

The paragraph above needs some precisions. Indeed, if I, as an attacker, is given the knowledge that some plaintext bytes are "Pope Bened.ct XVI is resigning", with the "." being a byte unknown to the attacker, then I can guess with relatively high probability that the unknown byte actually encodes an "i". So the correct definition would be: if the attacker, given knowledge of some plaintext bytes and the whole encrypted file, can guess the missing bytes with higher probability of success than the same attacker who knows the same plaintext bytes but not the encrypted file, then the encryption algorithm can be considered as broken. AES is not considered as broken, so that's OK.

Another point is about active attacks. An attacker may want to modify the data so as to induce an honest system to work over fake data; and the behaviour of that system can give a lot of information about the unknown bytes (a variant of this attack is what is used in the BEAST attack on SSL/TLS). Knowledge of some plaintext bytes makes such attacks easier. AES-CBC, by itself, does not protect against active attackers. To defeat active attackers, you need to apply a MAC. Combining encryption and MAC is not easy; you'd better replace CBC with an encryption mode which includes a MAC and handles the hard work (e.g. GCM or EAX).

(The definition above is about "known plaintext attacks", where the attacker knows part of the plaintext. For active attacks, we would talk about "chosen plaintext attacks", where the attacker gets to choose part of the plaintext, and "chosen ciphertext attacks", where the attacker alters the ciphertext and observes more or less directly the result of decryption. Properly applied and verified MAC gives reliable protection against chosen ciphertext attacks.)


securing Ubuntu bootloader using TPM I am currently working with Ubuntu 16.04 , with an Intel CPU that supports TPM2 module.

I am trying to harden my boot-loader, i tried using trustedgrub2 fork that supports TPM2 , i understand that trustedgrub2 currently does not support UEFI BIOS so i switched to UEFI-CSM which should emulate the legacy BIOS , unfortunately after installing trustedgrub , the system still boots with the GRUB2.

I also tried using tboot , but it seems that there is almost no documentation to be found anywhere.

My questions are , is there any good tutorial for using/installing trustedgrub2?
or maybe is there any alternative to the options above to make the boot process more secure?

Thanks!

Ubuntu supports Secure Boot. This requires UEFI-only mode. Please disable CSM. The TPM can be used by the Linux Integrity Measurement Architecture.

Back in the day, apparently IMA was very immature.
Progress is made.
It seems like IMA is compiled into Ubuntu since 14.04, according to this page.

From what i've been reading, still some works needs to be done.


What does the Local exactly mean in CVSS? CVSS (http://www.first.org/cvss/) provides the keyword local in the base vector.
The definition given by FIRST is somehow not so clear for me: Local: Exploiting the vulnerability requires either physical access to the target or a local (shell) account on the target.
Can anyone provide me with clear definition for it? I mean is it localhost? is it desktop application that are not available through HTTP?

Simply put a local vulnerability means the attacker has prior access to the target.
That may mean already having an account on the machine. With an account already on the machine an attacker could raise their level of privileges with an exploit.

A good example of this being the latest Linux kernel exploit CVE-2010-3081. The exploit allows for a local, unprivileged user to escalate their privileges to that of root.


Does iOS use built-in certificates to authenticate peers when using ipsec VPNs? Suppose I am setting up an IPsec VPN for Apple iOS clients with the requirement that the iOS clients need to know that the server is legitimate and vice-versa.

I create a root CA and issue a certificate for the IPsec server. The CA certificate is installed on the iOS device.

In the case of a man-in-the-middle attack will other servers be able to impersonate my IPsec server using a certificate signed by another or rogue root CA?

I don't know about the specifics of iOS, but the principle should be the same.

In theory, if you get your clients to install and trust your CA certificate, then any certificate it issues will be trusted by those clients. A man-in-the-middle attack should not be able to forge these certificates, unless they grab hold of your CA private key. So in that respect, your solution should be protected against man-in-the-middle attacks.

The downsides of using such solution, as opposed to getting a certificate issued by one of the trusted root CAs is with:

Deployment : With your approach, you'd have to manually installed your own CA as trusted on all your devices. Users with other devices (without your CA certificate) won't have this installed and either won't connect, or will manually have to accept an unknown (and therefore untrusted) certificate. In which case, the man-in-the-middle attack is a real possibility.
Revocation : What happens if your CA or server private key gets exposed somehow. How can you tell all your devices not to trust it any more, and instead trust a new certificate? 3rd party trusted CAs usually provide service to perform revocation checks to avoid this. You might be able to do something similar on your own, but it increases the complexity dramatically
CA Security : Whilst this is not guaranteed, trusted certificate authorities are likely to have stricter security in place. This is their core business after all.
Price/Hassle : I imagine the cost of issuing a certificate to your server with a 3rd party trusted CA should be significantly lower than running this whole thing by yourself. This of course depends on your circumstances, e.g. how many devices, what security/resources you already have etc.


Deniable discussions online Consider this scenario:

Alice is a typical corporate shark. She wants to get ahead in her organisation.  Alice has a sensitive information security scenario, she needs expert consultation but she doesn't know any experts. Due to whatever she's consulting on, she needs to be completely untraceable. Same goes for the consultant too. She doesn't care where the consultant is from, Romania or wherever, just that he is capable, and as far removed from her as possible so as to avoid any compromising situations. She also doesn't care about the consultant, only that there is a complete separation between the consultant and her. His methods also do not concern her in any way.

Bob, her bestie, a little tech minded but not much, advices her to:

Set up Tor
With Tor, Register for a completely secure email account outside of the US.
With Tor, create accounts on security forums (with the email) and post job requests.
Conduct discussions+ by connecting to the email account [via TOR].
She might obtain attachments that she might have to transfer to her computer [via TOR]
For payments, use a crypto currency++.

I'm wondering how can one or all of 3 hostile entities - Her organisation, Her country security apparatus, and the security consultant - establish a link between her and anything related to the scenario. Worst case scenario is that the consultant is sloppy and makes a big mess and gets himself traced, in the early stages, during or later (an year later maybe).

What are the problems with the above approach, in regards to stealth, deniability, being compromised etc?

Update: Also, she & her computer, are the central nodes that know the whole picture. I'm thinking, cash only 2nd hand laptop, wipe it, use from crowded wifi hotspots. Keep moving. Once achieved overall aim, wipe & reinstall (change the network card too?) & sell away.

+ Please ignore the specific contents of Alice's emails. As @Schroeder said in comments below, it's probably too much for this question. I'll open a separate question on crafting/sending/receiving/handling data through properly established secure channels. Also please advise me regarding deeper technical aspects that I should open separate questions for. Thanks.

++ I'll open a separate question on obfuscating/removing digital currency trails. (thanks @Philipp)

Disclaimer: Purely theoretical question. However I'm keen on learning more on the subject. Yes I'm a responsible adult and I know all the legal stuff, so please don't lecture me on ethics.

Alice should definitely do this on her home PC and not on her work computer. It might be compromised by various spying methods by corporate IT. Also, when the corporate IT admins aren't grossly negligent, they wouldn't allow a TOR node to operate from within their corporate network anyway. A sufficiently configured corporate network doesn't allow workstations to connect to anything in the outside world except via the corporate HTTP proxy. TOR doesn't work under this conditions.
Many email providers do not allow registrations via TOR or other anonymizers to avoid abuse. But let's assume Alice finds one which allows this.
In order to give proper consultation, the consultant will need accurate information about what Alice wants to do, what technology they use and what their main problems are. Alice likely won't get around to send the consultant confidential documents from her corporation. She could try to anonymize them as good as possible, but when the consultant is smart, he might put together all the hints and be able to guess who Alice might be working for. This might be enough to deanonymize her and rat her out.
Alice should check her email client to make sure it is properly configured and doesn't leak any private information in the mail headers.
Attachments from untrusted sources can be dangerous. Alice would be well-advised to examine the attachments carefully and only open them with programs which are sufficiently patched.
Contrary to popular believe, cryptocurrencies aren't untraceable. Bitcoins and its many, many derivates have a blockchain which securely documents the transaction history of every single wallet. This makes it possible to trace accurately which wallet moved how much money to which other wallet and when. Then all you need to do to deanonymize transactions is to find out which wallet belongs to whom. The identity behind a wallet becomes easy to know as soon as the owner tries to convert cryptocurrency into real currency or vice versa, because this usually requires a conventional money transfer between a currency exchange and their private bank account. Another situation where a wallet gets compromised is when it is used to order physical goods which need to be delivered to an existing post address.


Why pull upgrade from production server rather pushing them from development server? I am reading a book on security which suggest that if you have both development and production server and if you make some change, you should pull them from production server rather pushing them from development server via some means of automated scripts. Here is the whole excerpt:

  Content should move to the production server by being pulled from the
  development server, not by being pushed to it. That is, the transfer
  of new content or software should be initiated from the production
  server. It might ask for updates at regular intervals (just as your
  workstation does), or it could require an administrator to log in and
  initiate the update. And of course, the process that pulls updates
  should have read access only on the development server.

So, my question is why this is suggested?

The primary concern is not giving developers write access to production systems. This goes well with the principle of giving someone the least amount of privileges needed to perform a task.

Giving developers write access to production systems poses a few risks. Developer machines are used to surf the net. It's expected because developers need to browse documentation, download software, use Stackoverflow etc. There is a slight chance of them getting compromised by malware. This of course spells disaster if the same developer machine has write access to production. Secondly, giving production write access to developers might open them up to the temptation of pushing to production directly, bypassing things like having review systems in place, ensuring all commits pass unit tests etc. This could very well lead to sloppy code which further opens up the application to compromise.


What kind of security injection are these traces of, SQL, javascript, or otherwise? I've tried to secure all information going to the server to make sure there are no SQL injections.

However there are new folders on my server with weird names.
One of our online services is such that with certain inputs, directories are made with that name, but only after using mysql_real_escape_string.

These are the kind of folder names now on my server:

<script>alert(42873)<

\'\"

%27

!(()

\r\n SomeCustomInjectedHeader:injected_by_wvs

\0dir\0

&dir

�\'

What kind of injection was the hacker trying to make? Are they the kind of thing to expect from SQL injections? Or javascript injections?

This is the code I'm using to create folders:

$path = "designs_".$design->getDesignerType()."/product".$design->getProductID()."/template".$design->getTemplateID()."/".$design->getID();
if(!is_dir($path))
    { mkdir($path, 0777, TRUE); }

I actually AM using exec, but not to create folders. I'm using it for other things like creating PDFs using a binary source file, like this:

 exec("prince /home/zeejfl6/public_html/printshop/".$filename.".html /home/zeejfl6/public_html/printshop/".$filename.".pdf");

and making images, like this:

$cmdi = "convert -density 300 -resize $io /home/zeejfl6/public_html/printshop/$filename.pdf  -quality 100 -flatten /home/zeejfl6/public_html/printshop/$filename.jpg";
exec ($cmdi);

injected_by_wvs is used by Acunetix Web (w) Vulnerability (v) Scanner (s) (wvs). This is a Cross (x) Site (s) Script (s) - XSS - which is being inserted into a parameter (usually a form: name, date, time, age, etc). SQL based injections will contain a portion of a SQL statement (SELECT * FROM, INSERT INTO *), which are visible most of the times but can be obfuscated. That answers what kind of attack this is.

You may want to look into using escapeshellcmd() versus exec() to prevent someone from trying to insert characters. I disagree with the statement HamZa DzCyberDeV made with regards to exec(). It is not that serious if you take the time to sanitize input.


Is password strength exclusively a function of character set size multiplied by password length-in-characters? My team is responsible for the creation and management of many passwords (hundreds), which we do almost exclusively programmatically (all generation is random-enough).  We leverage a variety of of tools for automating different aspects of our infrastructure, including but not limited to Ansible, Docker, Jenkins, and Terraform.  These tools all have their own peculiarities as to how they consume and expose strings in various contexts, of which POSIX shells or shell-like execution environments are worth noting specifically.  We frequently call these tools from within one another, passing context between then for a variety of purposes.
The problem: it is frustratingly common to spend a great deal of time investigating mysterious bugs, only to find out that the root cause was the corruption of (or failure to properly parse) a password at some point in the chain of context passing, often (but not always) in a POSIX shell-like context, due specifically to the presence of special characters in the password.
The question: given a requirement for password complexity that is expressed in password length for a given set of characters, is there any difference from a security perspective in achieving the same complexity by constructing a password of greater length, from a reduced set?
To put this concretely: if we have been generating "sufficiently strong" passwords of length x from the 95 printable ASCII characters, and we reduce the character set to the 62 lowercase, uppercase, and numeric ASCII characters, will there be any loss of password security whatsoever by constructing passwords of length y, where 62^y >= 95^x?
Edit: Please read this as a technical question about the definition of password complexity.  For our purposes,  please assume that the password generation is truly random.  The definition of "sufficiently strong" is outside the scope of this question; the premise is that it is acceptable.

Is password strength exclusively a function of character set size multiplied by password length? Well, to be precise... not exactly.
Technically, entropy alone is not enough to guarantee you have a strong password. Strong passwords are supposed to be generated with enough entropy, and also look random enough to defeat dictionary-based attacks, or other related attacks. Also, technically, if a password with enough entropy and that looks random enough has been leaked and can be found in leaked databases, then it's not strong enough anymore.
What I mean in practice is that a 8-char randomly generated password might look like 49thS1bp, or might look like 123abccc. The second password though, unfortunately, by chance, contains patterns that make it easier to attack. As another example, by chance, you might end up generating a passphrase like correct horse battery staple, or orange banana banana orange, and those will not be considered safe enough (by the way, correct-horse-battery-staple has also been found in leaked databases). Also, consider what would happen if you used a custom word-list for generating your passphrases, so instead of the typical English-based word-list for diceware you would be using a list of words in your own native language, some other foreign languages you know, and maybe some local slang. The entropy will be the same (same size of the list, same length of the passphrase, etc.) but strength will be increased, because dictionary attacks will be less likely to succeed on average.
In your case, if the method of generating and checking the passwords is always the same, then you can just use the formula C^N for estimating your password strength, where C is the alphabet size and N the length of the password, exactly like you said. Also, if C and N are large enough, you can even forget about checking for patterns or checking in leaked databases, because those weak points will become less likely.
To sum up, even with perfect randomness, C^N technically defines the password entropy, not necessarily the strength. However, if C and N are large enough, this distinction becomes less important.


Session sync between two web apps on the same domain I have a Laravel 6 site, and a legacy Drupal 7 site. Both are served under the same domain, and both share the same user database table.

I'd like users to be able to log in via Laravel (never via Drupal) and then browse between the two systems freely, being logged into both.

Rather than attempt to reverse-engineer one or both systems' session handling in order to implement it in the other, I have come up with an alternative. The idea is to embed a very simple page from system A into an iframe in each page served by system B and vice-versa.

Laravel could load a Drupal page such as /session-check?token=12345. Drupal would recognise this token (using a shared db value, shared app secret, or private SSL key perhaps?) and log the user into Drupal, if not already. Otherwise it would just refresh the (Drupal) session lifetime. Thus sessions in both systems would initiate at pretty much the same moment, and stay fresh for the same timeframe. In all other respects the sessions would be independent, and entirely native to their original system.

Drupal would only need to load a very simple page from Laravel which refreshes Laravel's native session. Thus if you browse only Drupal pages, Laravel's session is still kept fresh.

I have all this working just fine, using a simplistic token mechanism, but wanted to ask the following:

am I overlooking potential security implications
are there suggestions on the best "shared token" method in this case, given that the two apps can access each others' cookies and databases.

I've read you should never attempt "home-grown" security, but it seems my scenario is sufficiently unique that the usual options aren't exactly what I'm after. That said, I'm keen to integrate existing solutions where possible, at least for the token system.

I definitely sure , we can have one jwt token server in php.
also i think we can have central token server in multi language env. like nodejs laravel lumen Django and etc.
im sure that here in this video you can find some basic informations about this concept.( in second half of this video)
if you like, case study samples, like me, you can watch and enjoy.
the concept is:

jwt use keys named private key.

if we have single private key and then use it in two separate server, you can do what you want.

i think this answer help you. https://stackoverflow.com/a/47329159/308578


Does storing all the passwords a user has ever used create a vulnerability in the broader password environment? By saving all the passwords for all users forever, are companies accidentally creating a less secure environment?
Related to this question:
Why do some sites prevent users from reusing their old passwords?
I understand that companies feel that they need to be protected, but by everyone taking the same strategy, it creates a poor security environment. It seems less secure to me. Am I missing something?

Just to be clear, they shouldn't be storing previous passwords, but hashes, preferably salted. Storing a password in plaintext is a no-no.
Storing hashes for the last few passwords may be reasonable although debatable. Storing the whole history sounds overkill. You are wasting storage in a vain attempt to protect people from themselves.
Too many password policies are outdated or downright nonsensical. Insisting on special characters or non-intuitive patterns is indeed a reason why people rotate their passwords or they change just one character. The result is that they end up using predictable patterns. Whereas a passphrase long enough would be more memorable and as secure. The longer it is, the harder it would be reverse it from a stolen hash. Ironically, many sites don't allow long passwords, like > 20 chars.
Which leads us to another question (that was not asked). Does it make sense to force people to change their passwords every 3 months or so (which is the main reason why that "password history" exists in the first place) ? If people were using unique passwords for each site, then there would be less worry about a password being compromised at one particular place. (A simple solutions exists: using a password manager).
To answer the question: that could be a possible security risk, depending on implementation. Storing plaintext passwords: red flag. Storing salted hashes: better. But what are they actually achieving in terms of security ? Very little I'm afraid.


sanitizing likes/unlikes in application? I've got a function in my app where users can click on a "thumbs up" image and a like is recorded in the database; all that's recorded is the user's ID and the ID of the post that the user liked.

I know user input can't be trusted--am sanitizing user inputs, validating user inputs (server-side), escaping outputs, and escaping db queries.

In this case, the user is clicking the image, but there is no form. However, data is being passed to the database, using JS. Note, there is no user input between any script tags (the like script is on a page that isn't served).

My plan is to validate (server-side) that only numbers are being sent to the database, but how do I sanitize this "like"/thumbs up input to protect against XSS?

Note: I'm currently reading through OWASP's XSS Prevention Cheat Sheet and Mozilla's Secure Coding Guidelines, which is how I started wondering about this.

Sanitation is trivial,  as this variable can only be two values. You could make it an integer,  and have a value of 1 for an up-vote and a value of -1 for a down vote,  no other value is valid.  Of course all security based validation must always be done server side.
But that is the least of your security concerns.   The real concern is forcing other to vote on an attacker's behalf. This can happen a number of ways. An attacker could make a clickjacking  game where by each time the user clicks to fire a rocket at some kind of space invader they are in fact clicking on an invisible iframe which is firing a new vote at your system.
An even more virulent attack would be to use Cross-Site Request Forgery (CSRF) to fire off these requests en-mass when one of your users visits an attackers website.  The CSRF Prevention Cheat Sheet is a good resource.
Almost all Anti-CSRF measures are defeated by XSS,  so make sure your entire website is immune to this attack. The Sammy Worm used XSS to defeat MySpace's Anti-CSRF token.
Also,  don't forget about automatic account creation, make sure your users have to solve a strong captcha like Recaptcha before they can make an account.  Email verification is trivial to automate and I don't believe its a real security measure.  If they have too many failed logins they should also be prompted with a captcha.


Create a web session from within a 3rd party website using an existing oauth2 token We're trying to allow a trusted 3rd party web application to automatically authenticate users in our own application. We thought about using oauth2 for that matter.

In our scenario we would provide an oauth2 server and the initial handshake would look something like this (which imho is the regular oauth2 3-legged mechanism). Let's say acme is the name of our service.

3rd party app has a connect to acme button
User clicks on that button and is redirected to the acme service
User logs in via form based login on the acme site
The Acme service presents the user with the 3rd party wants to access your account dialog
User clicks accept
Acme service generates an oauth2 token and redirects back to 3rd party
3rd party stores the generated token for future interactions with the acme service

Now if the session on the acme website is expired, the 3rd party app could automatically re-authenticate the user in the acme web application by sending an ajax request to an authentication endpoint on the acme server.

It will send the previously stored token in via https as a http header to the acme endpoint, where the oauth2 server will validate the token and authenticate the associated user in the web application.

We're wondering if this implies any security issues or if this is a safe oauth2 pattern for automatically re-authenticating existing oauth2 tokens with a oauth2 providers website.

You got things confused a bit. In OAuth2, you have 3 things :

OAuth2 Service Provider (acme in your example)
OAuth2 Client (3rd party in your example)
OAuth2 User (the browser of the physical user in your example)

Now, what happens is that it's always the client that authenticate himself with the service provider and then the client authenticate the user in its application. The client authenticate the user in its application either by doing it himself (ex. session variable) or constantly re-sending the access token to the service provider.

  Now if the session on the acme website is expired, the 3rd party app
  could automatically re-authenticate the user in the acme web
  application by sending an ajax request to an authentication endpoint
  on the acme server.

The wording of that part is strange. It looks like it is the client that is controlling the service provider which makes no sense. The client doesn't really have any control over the service provider. If the session on a service provider is expired and the client ask the service provider if a particular user is still connected, then the service provider will just tell him that he's no longer connected.

Now, what you probably meant is :

The user session with the client (3rd party) is expired, how can I automatically re-authenticate him if the user is still authenticated with the service provider?

Well, there is a couple of ways but first let's talk about the access token. What the user receives from the service provider and then passes to the client is an access token. Access tokens often have limited validity time for multiple reasons check here :

https://stackoverflow.com/questions/7030694/oauth2-why-do-access-tokens-expire

The way to get new access token depends on the service provider. Sometimes the client receive a refresh token that can be used to receive a new access token. See google api for example :

https://developers.google.com/identity/protocols/OAuth2?csw=1

With other providers, the chain of redirect might be automatic if the user is still logged in with the service provider. So, while it do the whole OAuth2 protocol all again, the user only see a page reload.

Additional Note

I saw you mentionned the word "ajax" in your question. There is no ajax in OAuth2 as the security depends on full redirect working properly. Also, it's the client that send the access token to the service provider. The client is a web server, it doesn't do ajax request like we do when we use a browser. And finally, the user cannot send the access token to authenticate himself for so many reasons...


Is my computer trying to download something malicious from Dropbox? My wife's computer was recently compromised and I have tried to clean it.

I installed Microsoft Network Monitor to see if there was any unexplained internet traffic and I noticed a connection to Dropbox. Here is the given details:

URI: /subscribe?host_int=34404476&ns_map=162130732_8752065324,26351085_36339744642541,129513375_382381602719&user_id=16845707&nid=0&ts=1386575431

Host:  notify8.dropbox.com

Process Name Dropbox.exe

Note, neither myself nor my wife use Dropbox. I checked the install date for the instance of Dropbox that is on her machine and it has an install date of May this year, so this was probably not installed as part of what ever virus etc. infected the machine.

I tried to do a reverse lookup on the IP 108.160.162.115 and I got nothing.

Does this look like my wife's machine is trying to connect to a particular Dropbox account to retrieve some software (possibly malicious)?

If your system has been taken over an attacker could manipulate the install dates of any software, so anything you see on a hacked system must be treated with doubt. The IP address you listed is a valid dropbox IP, however that means nothing - if I was writing malware I'd seriously consider using dropbox to distribute it. It's robust, completely free, and people are likely to discount it as a threat vector: "Oh that's just dropbox, don't worry about it."

So it is entirely possible that the malware installed uses a dropbox labelled process to actually connect to dropbox and download latest versions of malware and operating instructions, although that scenario is not particularly likely. It is much more likely that this is actually a completely legitimate dropbox installation that you don't remember installing, and therefore a red herring. Unfortunately, there's no way to know for sure as once a system is hacked you can never trust it again. Your best bet is to wipe your system and start over.


If my protonmail password is compromised, does that potentially mean that my whole account is, permanently? My (limited) understanding is that my password is used to encrypt the keys which are used to encrypt my mail messages on protonmail's servers. Does that mean that knowledge of my password could potentially let an adversary find out what the keys associated to my account are, and thus render password change useless? Or are keys periodically subject to change as well, and all my emails re-encrypted? Or have I got it completely wrong?

No.

According to the ProtonMail Team, ProtonMail uses perfect forward secrecy:

  We use PFS in our TLS cipher suites for both web access and SMTP, and have since the beginning

This means, that if correctly implemented, it gives assurances that session keys will not be compromised even if the private key of the server is compromised.

It protects past sessions against future compromises of secret keys or passwords.


How does Square Reader comply with EMV pin entry requirements? Square recently launched their Square Reader physical device. AS well as accepting NFC based payments (e.g. Contactless or Apple/Android Pay, it also accepts Chip and PIN authentication.

However the PIN entry takes place in an app on the smart phone using software rendered buttons. How does this meet the EMV requirement for the PIN Pad to be a "tamper evident" device(as described in the EMV specifications, book 2 section 11.1) - pushing buttons on an app that talks over bluetooth doesn't seem to be tamper evident to me.

The full flow is that the retailer installs the Square app onto their Android/iOS device. They then pair with the Square Reader over bluetooth. At payment time the retailer opens the Square app, and enters the items/total as per a usual Point of Sale system. When they total it and proceed to the payment step the customer then inserts their Chip and PIN enabled card into the Square Reader and then, on the retailers smart phone, validates the amount to be charged and enters their PIN into the app to authorize the transaction. The PIN is presumably sent over the bluetooth connection, with the amount, to the Square Reader where it then is passed into the Chip.

Am I misunderstanding the requirements on PIN Pads, or am I misunderstanding the functionality of the Square Reader?

From what I have seen of the device, your description of the Square Reader and it's operation is spot on. The requirement for a pin pad to be tamper evident is however no longer required.

The update was published here on May 2015:
http://www.emvco.com/download_agreement.aspx?id=1113

And contains the following excerpt:
"remove a requirement for PIN Pads to be tamper evident, since PIN Pad security is addressed by individual payment systems."

That being said, the actual update to Book 2 section 11.1 without knowledge of the intent statement above, still does not make it clear what is required in my opinion.


Is there a website or free downloadable program to identify and remove malware from an ISO file? Is there a website or free downloadable program that allows a user to identify and remove multiple types of malware from an ISO file?

it could issue updates through fully functioning bitmap

So you're talking about stripping out steganography rather than neutralizing malware - in which case you'd get some mileage out of converting the file format (then possibly converting it back again). However it is technically possible to embed the content in such a way that it is still recoverable (IIRC the hidden WoW user id is extractable from a photo of the screen in addition to a direct image grab) e.g. if the image is of a barcode, then converting the format is not likely to disrupt the value embedded in the bar code.


Why triple DES used in EDE mode? Why is triple DES is calculated in encrypt decrypt encrypt mode? Why a decrypt in the middle? And isn't decrypt = encrypt since DES in a symmetric cipher?

It is for backwards compatibility with normal DES. If you use the same key for the first two operations, they cancel out and you are left with a ciphertext encrypted under a single DES key.

Decrypt is not the same as encrypt. Symmetric refers to the fact that both use the same key but the actual steps are effectively reversed.


hijacking fedora or ubuntu or windows upgrades on the fly is It theoretically possible to hijack (I mean substitute on the fly) the fedora or ubuntu or windows packages upgrades if a cracker has owned the company's firewall/proxy ?

Trying to replace the packages with other files is certainly possible and even quite easy for an attacker who took control of the firewall or proxy. However, these packages are digitally signed with a private key which is owned by the people at the Fedora headquarters, and the attacker will not be able to forge that; his fake packages will be rejected by the Fedora systems which try to use them. This signature uses GnuPG; see this page for details.

Of course, such an attacker will still be able to prevent upgrades by simply blocking the relevant packages. This alone can be a problem, because it allows him to indefinitely extend the lifetime of known vulnerabilities.

Edit: the same applies for just about every other modern OS out there: they all use some sort of signature mechanism on authentic updates. Linux-based OS tend to use the OpenPGP format while Windows relies on derivatives from the X.509 world, e.g. authenticode; but that does not change the concept.


What encryption schemes require two or 3 private keys to read a message? I would like to encrypt some data so that it can only be read if two or three people use a private secret to decrypt the data.

  What is the best / most modern way to accomplish multi-person decryption?

Some thoughts I am thinking of

X people has N characters of a password that is X*N characters long
Re-encrypt the message with PGP or some PKI/RSA etc
A mixture of the above...

The threat I want to prevent against is the forced decryption or modification of an encrypted message without all parties present.

There's Shamir's secret sharing, but it doesn't involve PKI.  Rather, it's more like ensuring that all passwords need to be involved in order to unlock the secret.  The secret, in this case, could be a singular (private or symmetric) key.

I don't know of any widely accepted implementation of the scheme aside from the top few hits you get from Google.


philosophical: restricting the password space increases security This is more of a philosophical question.

Suppose that you are trying to choose a good password for a particular online service, say your bank's e-banking service. Now the bank has some restrictions on the passwords that it allows: you can only use (lowercase) letters and (decimal) digits, and the password can be up to 6 characters long. So what is a "good" way to select such a password?

One could do the following (call this scheme 1): select randomly 6 characters from the set [a-z0-9] with uniform probability. This scheme has the disadvantage that it may produce "weak" passwords such as those containing only letters or only digits (there is a 14.2% [1] chance of this happening).

So here's another idea (call this scheme 2): select randomly (and uniformly) one letter, one digit, and 4 characters from the set [a-z0-9]. Then use a random permutation of these 6 characters as the password. This guarantees that the password will have characters from both classes (letters and digits).

So the question is, which of the two scheme produces "better" passwords?

On the one hand, the second scheme produces passwords that will likely be more resilient to simple brute force attacks. On the other hand, the first scheme allows strictly more combinations than the second one: 2^31.0 [2] vs 2^30.8 [3]; in fact the set of passwords of scheme 1 is a superset of those of scheme 2.

Note: I'm looking at this from the perspective of the party that generates the password and not the party that sets the password policy.

[1] (26^6+10^6)/36^6 = 0.142

[2] log2(26^6) = 31.0

[3] log2(36^6-26^6-10^6) = 30.8 i.e. all combinations of 6 characters excluding the ones with only letters (26^6) and the ones with only digits (another 10^6)

tldr; Restricting the password space does not help against brute force attacks, but may against intelligent attacks, but there is an even better way.

First off, you're asking the right question, but using the wrong terminology here:

  ...the second scheme produces passwords that will likely be more resilient to simple brute force attacks.

(I think you mean intelligent attacks.)

A brute force attack is one that attempts every possible combination without added intelligence. Brute force in your example would be something like:

a, b, c, ... y, z, 0, 1 ... 9,
aa, ab, ac, ... ay, az, a0, a1 ... a9, ba, bb, bc ... 99,
aaa ... 999,
aaaa ... 9999,
aaaaa ... 99999,
aaaaaa ... 999999

Anything other than that would be considered an intelligence strategy. For example, before you try brute force, you may be able to save some time with this strategy:

Attempt only numbers.
Try words found in a dictionary.
Try the top X most popular passwords.
Try combinations of the username or user's initials, current year or last year, etc.
Try brute force.

Your goal, as the creator of your password, is to make sure that the first 4 options always fail to discover your password. In other words, you need to make sure that the only way to discover your password is by brute force, and also make sure that if brute force is used, that it will take a long time before finding your password.  However you do that is up to you, given the constraints of what types of passwords are allowed.

As for your particular question, I would approach it more like a random password generator- it generates one for you, you look at it, and if you believe that it could be guessed with a method other than brute force, you simply generate another random one until you're happy with it. (This would be Scheme 1 with a twist.) If you really wanted to quantify this, you could have your intelligence strategies built and ready to go (all strategies except for brute force). Then you can test them against your randomly generated password and if it is found, you generate another one until all intelligent strategies fail to discover your password. You then would be left with a password which is only discoverable by brute force. Using this method you can achieve better entropy than by restricting the password space in the way you described.

Note: with the password rules you supplied, my twist to Scheme 1 may end up looking somewhat like Scheme 2, however, as the number of allowed characters and password length increases, the Scheme 1 twist should provide more entropy.


What are all of the issues with storing a cleartext password? I know, I know, cleartext passwords are terrible and you should always store a hash!

However, I'm interested in all of the issues with storing cleartext passwords so I can make a reasonably secure choice. Are there any issues other than the obvious two??

Many people reuse their passwords and you're putting them at risk
An attacker can now login as the user to your site (although couldn't they just change the hash in the database to be a new password at that point / they already have access to all the information anyways?)

Motivation:
If the password in question is randomly generated and only used by the server to authenticate on behalf of the user to a service (an attempt at "single sign-on"), the primary reuse risk is negated. If an attacker compromised the database, they'd be able to login directly to the 3rd-party service. But if having your database compromised at all is orders of magnitude worse than having an attacker gain access to the 3rd-party service, is it still an issue?

DETAILS ADDED FROM COMMENT:
I'm trying to authenticate from a server with health information on it to a 3rd-party Jabber server, so the client never has to know login credentials to the Jabber server. Then authenticated tokens can be passed from the server to the client so the client can communicate directly with the Jabber server.
Obviously, access to the health data in the database is orders of magnitude more disastrous than gaining access to the Jabber service.

I'm trying to be careful here because I'm very wary of cleartext, but it seems like the best approach in this particular situation.

I know this does not directly answer your question, but another approach would be to have the application authenticate itself to the service to set up a trusted channel between the two.  The app could then just pass identity assertions on behalf of the user, and no per-user passwords would be needed.

The assumption here is that the service is happy to trust the application.


Hash on all previous messages I'm implementing a TLS-like system, and I'd like to set up a Finished message, to prevent the replay attacks.

As far as I understand TLS, it contains a hash on the previous handshake messages, encrypted and signed with the chosen algorithm.

The server first builds his Finished frame, with a hash of all the previous messages. Then it's sent to the client.

Does the client have to take the server's Finished message as a "previous message" ? (to compute a hash)

Because if not, the contents to hash are just the same as the server, but in a different order (which will produce a completely different hash).

They say this in the chapter on the Finished message :

  All of the data from all messages in this handshake (not
           including any HelloRequest messages) up to, but not including,
           this message.

In my opinion, the client indeed has to take the received Finished message (from the server) along other handshake messages.

That section of the RFC also states:

  The value handshake_messages includes all handshake messages starting
  at ClientHello up to, but not including, this Finished message.  This
  may be different from handshake_messages in Section 7.4.8 because it
  would include the CertificateVerify message (if sent).  Also, the
  handshake_messages for the Finished message sent by the client will
  be different from that for the Finished message sent by the server,
  because the one that is sent second will include the prior one.

The client sends its Finished message first, and then the server sends its message, including the previous Finished message from the client.

  But won't be the hash too long ?

A cryptographic hashing algorithm always outputs hashes of the same length. Adding more length to the input does not increase the output length.


Securing user postal address in a database? I've been assigned a web project that deals with shipping goods between two parties. I am unsure what a secure database scheme (if any) would be for storing the recipient's postal address and whether or not there are data privacy laws in regards to how these addresses should be stored? Both the recipient and the sender will require access to the address in the system.

Or unlike passwords, would it be okay to leave them as plaintext? Amazon is an established company, and when you log in to your profile, they would show you your address. This implies that Amazon stores them either in plaintext or in a decryptable state.

As you mentioned, password hashing is a great way to secure a client's password in a database (if done right). However, if you/your app needs to know the data that is being hashed then hashing alone cannot work as you need to encrypt the data.

I assume you are concerned with data breaches themselves (attackers gaining access to the database and thus 'seeing' all this plaintext info). If this is the case, having a strong and secure (encrypted) database will be a life[money]-saver assuming the decryption keys are not also compromised...

Here is an article on how to encrypt sensitive data properly.

Here are some common mistakes.

Also, just because you 'see' Amazon's data (the addresses) doesnt mean it was stored in plain-text, it just means that -like you said- it is decryptable.


Should we encrypt in-app user messaging? We have an app running where among other things people can send messages to each other. Obviously admins and content managers that have access to CMS can see what people are sending to each other. Is this usually encrypted and if yes, how, with what encryption?

UPDATE

The entire site is SSL encrypted, I'm specifically talking about admins being able to read users' messages between themselves. Sure, we can prevent certain admins to have access to that, but to be honest I would like to even hide it from the super admin with encryption. But then, in case one needs to read those for any purpose, how to decrypt them, how to structure the admin protocol for that?

We have no way of knowing.

What needs to be done is:

Identify the risks arising from this vulnerability. (What bad things might your admins do? What bad things might other people be able to do if the messages are not encrypted?)
Assess the severity of these risks.
Decide if these risks are acceptable or if they must be treated.
Identify suitable ways of treating these risks.
Treat the risks.

To do all that requires a good understanding of what your app is used for, what your customers want, what the law requires of you, what your contractual obligations are, what resources you have available, what security capabilities are in your infrastructure, and what level of risk your business finds acceptable.

Not the kind of answer you hoped for, I fear, but if security is important then you need to make good, informed decisions about it.


Preventing Client PC's from accessing C&C machines At my office I find us constantly fighting with malware. All users run under the "user" level, we have McAfee and have recently reviewed the Best Practices guide to ensure we adhere to it, all of my systems are patched with WSUS, and we regularly push FireFox and Flash updates via GPO.

Despite all of these measures, I still find users getting Malware on their PC's. For the most part this Malware is just "Scareware" however it looks as though it's put there from a dropper of some sort. While the Scareware is cleaned easily enough, I'm more concerned about the dropper putting a Trojan or Rootkit on a machine and that machine sending information offsite that it shouldn't be allowed to do.

My question is if we can't completely mitigate the infection of PC's, can we at least prevent that machine from connecting to the outside world? Firewalls will only go so far as they're stateful and will maintain a communication with external computers so long as they're the one that initiated the communication. Can this communication be effectively prevented?

You can't, not without imposing an unwarranted intrusion on people's ability to get work done.

You could turn off all networking (or forbid all outbound connections), but then no one could get any work done.  Not a helpful solution.
While it might be possible to build a blacklist of known C&C servers and prevent machines from contacting any server on that blacklist, this is not likely to be a useful defense.  Where would you get that blacklist?  You're not gonna compile it on your own; this stuff changes too fast.  And if someone has analyzed the bot software to identify the C&C server, they've probably also identified it to find a fingerprint that can be added to anti-virus software.  So I would expect any bad stuff that's blocked by this defense to already be recognized by anti-virus software.   In short, I don't think this offers much value over just running anti-virus software.

In conclusion, I don't think this is a promising direction to solve your malware woes.

I think it's a better bet to focus on standard practices: automated backups, bring everyone up to the latest version of the OS and software, turn on automatic updates.  For Windows users, get them on the latest version of Windows (XP must die), give them a modern browser, uninstall Java, Quicktime, and other unnecessary software (unless they need it), and give them antivirus software.  If they get infected, wipe and reinstall their machine and give them some quick informal, impromptu security training (e.g., about clicking OK on dialog boxes). Also, Secunia PSI can help you keep your users' software up to date on the latest security patches.


unique certificates and TLS protocol I know we can use TLS protocol to create a secure connection between a server and a client.
My question is : Certificates ,which use in TLS, are unique for each connection (pair)?. e.g. in a data-center with thousands of switches and hosts, Secure connections between a main controller and devices (like SDN controller and  southbound devices) will happen with thousands of certificates? or using a certificate (or a pair? "i don't know") in whole of network or a part of it?

A certificate serves to identify a connection endpoint, like a device or user.  Any of the client computers can verify a server's certificate was signed by the company's root certificate, which can assure them that they're connecting to a genuine trustworthy endpoint.  So each server needs only one certificate.

Similarly, the (optional) client certificate is issued to a machine or user.  The server can validate that the client is who he says he is; plus, the server can read a value from the Distinguished Name field on the certificate to ascertain the client's identity.

So when using certificates for authentication, you don't need to establish one pair of certs between each communicating pair of endpoints.  You just need one cert for each server and (optionally) one for each client.


VirtualBox + VPN with Win10 Host - how secure is it? I got a notebook running Windows 10 from my company which I am officially allowed to use privately. I have to travel a lot. I don't want to carry a second notebook.
Since the admins have access to the device, like for company administered browsers,  updates or whatever, I don't want to use it without an extra layer of protection from their monitoring.

So I installed VirtualBox with a Mint OS guest. The virtual drive is encrypted. Inside the guest system, I installed mullvad VPN.

How safe is this setup? Is there any possibility to check if there is maybe a keylogger or something like that running in the host system compromising my security? Where are the potential pitfalls of this setup?

I don't want to use it for illegal things (of course) but I don't want my company to be able to read private emails, chats, know my account balance when I check my credit card bill abroad, see what I watch on Netflix or whatever, see what I shopped and stuff like that.

What's your opinion on that?

Security and Privacy is a relative thing. The configuration you describe is pretty solid and is likely sufficient for most situations.

However there are less likely possibilities that can effectively defeat the described configuration. You mentioned one already, “Key Loggers”. Another is a host level process that can access the running unencrypted virtual system once you start it.

It’s unlikely that a legitimate company will deploy the kind of extreme level surveillance necessary to thwart your approach, but it’s technically possible. It’s far more likely that admins will note your encrypted virtual disks and ask about it, as well as your use of a VPN. If a response of, “Personal Stuff” would be acceptable, then your protections are likely sufficient.

If you are concerned about the less likely more extreme monitoring potential, then an external bootable OS that completely bypasses all corporate software is necessary.


Password reuse for similar accounts Assume I have two Github accounts, one for regular use and one for testing purposes. Or two PGP keys, one for pass and the other for encrypted email communication, and my backup scheme is exactly the same for both keys.

Now assume I use a single password for my two Github accounts and another single password for my two PGP keys.

To what extent is my overall security diminished by this practice?

This answer to a related question states that

  you should never use the same password in different places, unless that password protects the same data or gives you the same privileges

In my hypothetical case, a single password would protect different data, but the threat model would be very similar.

The purposes of those accounts are different, and so is the data protected by those passwords. If only one password gets stolen, the attacker will be able to access both the services / data / accounts / etc. So to reduce the impact of a possible attack or at least to slow down the attacker, those passwords should be different. Even if the threat model makes you suppose that both passwords will be stolen anyway, there might be some cases where you will be able to detect the attack before both accounts are compromised, so having different passwords will help.

That said, in theory you shouldn't even be asking this question. Why? Because you probably already have tons of accounts with tons of passwords that should all be different, and to manage all this data you will probably have a password manager (or write them down somewhere, etc.). So it should not be a problem for you to use different passwords in this case as well.


Can a USB with an infected MBR or GPT harm an OS that reads it? Assume a USB drive has an MBR or GPT that has malware in it. I already understand that booting from such a USB device would execute the malware as part of the bootloader. If I understand correctly, if a clean computer was booted into a traditional OS (macOS, Windows 10, Ubuntu, etcetera) and then the infected device was inserted then the OS would not execute code but would still see the MBR or GPT.

Is it correct that

A: an infected MBR or GPT introduced to a clean, already-running OS would have no malicious effect at that time...

And B: would have to remain inserted during a reboot (and be the booted device called by the BIOS) in order to have a malicious effect?

Please note that this question is limited in scope and does not pertain to the firmware layer of the USB drive, nor to the data on its data partition. IMO those questions should be handled discreetly, not conflated.

For classical boot-sector viruses, generally no.  Those require execution of actual code embedded in the boot sector (which happens to coincide with the partition table in MBR arrangements, but not in GPT configurations), and no sane OS executes code from the boot sector of removable media.

There is at least one notable exception to this though, the Amiga Rigid Disk Block (RDB) partition table format can embed filesystem drivers in the partition table itself, so it is theoretically possible for malware to be spread that way, though it's extremely unlikely (it would only work on systems running AmigaOS or compatible operating systems, and the market for such malware is nearly nonexistent).

There's a relatively small but still present chance however that the OS itself may have a bug in the parsing of the partition table that would eventually allow for an ACE exploit that could be used to infect the system.  For an MBR, this is extremely unlikely, the format has been around for decades, is a fixed size, and is trivial to parse.  For GPT, it's a bit more likely, as the GPT structure is variably sized (though it's rare to see one that isn't the standard 128 entries).  Other partition table formats would have varying probabilities, but probably don't matter much anymore today.


Sniffer attack on mobile I have Nokia lumia 625. And a guy hacked it using sniffer. That's how much I know about it. He has access to all my online texts(eg. Whatsapp, messenger etc) . and also to offline carrier text messages. What do I do to resolve this problem? I have tried factory resetting but it does not work. What is a sniffer and how do I handle it?

There are a few possibilities how he did it:

You and him were connected to the same WiFi network and he used a software like Dsploit that allows him to intercept the traffic and performing man in the middle attack - solution to that is use VPN software that will encrypt the connection.
More advanced attack. He forced your mobile device by using Karma and WiFi Pinneaple to connect to his rouge access point - The best way to protect yourself from this kind of attack is to 'forget' networks as soon as you have finished using them, just remove them from the list.
He had access to your mobile device and he installed a keylogger - solution is to reinstall to whole system in your device.


P12 - Extract public part (certificate) without knowing the p12 password I would like to extract the public part of a revoked P12 which doesn't belong to me. I can't open it with KeyStore Explorer because I am prompted for the password, is it possible with OpenSSL ?

The password only protects the private key(s), not the certificate, am i right ?

It can be done with openssl. In a terminal type:

openssl pkcs12 -in myfile.p12 -nokeys -nomacver

And just press ENTER when the import key is requested. The certificates contained in the PKCS12 file should be printed (en PEM format) on the standard output.

NOTE: even if the certificates are present in plain text in the PCKS12 file, the file full content integrity is protected by a Message Authentication Code (MAC). Without the password you are not able to verify that the file has not been modified and it means that anyone who could access the file would be able the add, remove or modify the certificates. It may be a security concern, not necessary in your case, but you should keep that in mind if you want to reuse that tip in other circumstances.


Can You Prove a Chat Happened Online? With so much communication happening online nowadays the needs to verify information is obviously an essential.  However, let's say something was said in an online chat room/or private chat client, such as skype, and you need to share that information.  Is it possible to verify this information and present it to other people authentically?  Obviously screen shots and copy pastes of chats are not verifiable or reasonable for evidence.  Is there any way to implement a method of authenticating that a chat actually happened?

I'm thinking this is perhaps impossible with P2P clients like skype, as the server doesn't even have logs of the chat.  What then can you do?  Does anyone have any theories or ideas?

One use of PGP is to provide message authentication; so if the chat messages were signed, you would have good confidence that the person on the other end has access to the corresponding private key.  The other party could still claim their key was stolen, however.


Encoding HTML email content Say I have a form on my website.

The input elements of the form are: email address, name and some feedback textarea.

The server-side application that this form is submitted to will send an HTML content-type email to the email address you specify supplying all the input fields you specified.

For instance

  Hi {Name},

  Thanks for your feedback. Your feedback was: {Feedback}

  The email you provided is: {Email}

My question is:

Should I encode the {Name} and {Feedback} variables in the email? Given the fact that no current modern email client or web mail interface will run any script or load external resources by default?

The reason I ask is because I reported such an "issue" to a very big public company. The security engineer I talked to, told me that they don't worry about such things, and these kind of things are expected to happen.

He suggested that it's the user's fault for not using a more secure client (if the client executes the javascript).

Thanks.

Should I encode the {Name} and {Feedback} variables in the email?

Yes - for correctness, even if there is no practical threat. If the feedback-giver includes a less-than sign in their feedback, it should appear in the mail as a less-than-sign, and not get treated as part of a markup tag. Handle text context injection correctly, get the security piece for free.

Attacks using HTML injection are much more limited in mail than on a web page because it is assumed that there is no origin associated with the sender that can be usurped to get cross-site-scripting, if scripting executes at all.

However it's not just JavaScript: markup injection would still get you the ability to reformat the mail in general. For example you could inject a spoofed link into what looks like the sender-specified part of the mail, or some styled markup to overlay custom content over the whole mail body. Depending on who the Big Public Company are there might be an increased phishing risk here.


Can a session be hijacked if the user is redirected from HTTPS to HTTP after login? I am developing a web app, which makes HTTP calls as long as the user is not logged in.
Once the user clicks the login button, he is sent to a "login page" that is HTTPS.

The login makes an Ajax call to a servlet, where some specific attributes are added to the session.
Then, to solve the problem of "session fixation", the current session is invalidated and a new session is created.

After login, the user is redirected to the application page but using HTTP.

Now in order not to lose the session attributes (between HTTPS and HTTP) I overrode the default Glassfish mechanism by caching the JSESSIONID cookie and sending it in response: (this is a j2ee application)

  Cookie cookie = new Cookie("JSESSIONID", request.getSession().getId());
  cookie.setMaxAge(-1);
  cookie.setSecure(false);
  cookie.setPath(request.getContextPath());
  response.addCookie(cookie);

It works fine, but I have been reading on Stack Overflow, IT Security and generally online that the session could still be hijacked. For example this answer mentions that is a very bad idea, and that a man in the middle can hijack it.

I am no security expert, but I would like your feedback on the following mechanism which I built:

When typing web app URL, the first landing page is HTTP. All the mechanisms are HTTP.
When the user decides to "login", he is redirected to a page, and that "landing" page is HTTPS (enforced through j2ee CONFIDENTIAL security constraint)
On servlet, session fixation is taken care of by invalidating session and creating a new one. Then session attributes are added.
In order not to lose session attributes while returning to HTTP, a cookie is manually overridden with the same "Session ID", and set to "non secure".
All app requests are HTTP again.

Is this still an easy target for session hijacking / MITM / or any other security flaws?
I would appreciate feedback as I am not very experienced with security details.

Whenever you are requesting a page with HTTP, everything is sent plaintext, that means the session cookie containing the id is sent plaintext as well (even for image requests). That makes it an easy target for MITM attacks. You can configure the cookie to be sent to HTTPS pages only, but of course you will loose the session then on HTTP pages.

The best way to deal with this problem is, to make the whole site HTTPS only, you can avoid a lot of troubles this way. As long as your site doesn't have very high traffic, it should be no problem for todays servers.

If you really have to switch between HTTP and HTTPS pages, you could separate the two concerns of maintaining the session and authentication. You can add a second cookie only for authentication and restrict it to HTTPS pages only. The session cookie can then be used for both HTTP and HTTPS requests. I wrote an example of how this could be implemented (it's written in PHP, but the idea can be implemented in other environments as well).


Exploiting Writeable SNMP So, I've come across a couple of devices that are using default writable community names for SNMP such as 'private' (on windows machines) and 'Secret c0de' (on Brocade switches).

I'm aware of the implications in terms of using SNMP for recon, and i'm aware of the attacks against Cisco devices to both reset the device passwords and to dump the configuration of the switch. With that in mind, it appears that back in the day it was possible to dump hashes from Windows machines by running something along the lines of

C:\NTRESKIT>snmputil walk public .1.3.6.1.4.1.77.1.2.25

Unfortunately, that no longer works for more modern versions of Windows (I'm actually testing a relatively up-to-date server 2003 box and it's not working) and I'm curious if there's any other methods to dump passwords (Local/Domain hashes or anything else) via SNMP available (either for Windows or for other switches like the aforementioned Brocade switches).

Is there anything else a writeable SNMP community string might be useful for as an attacker that I'm forgetting?

1.3.6.1.4.1.77.1.2.25 is only one OID (Object ID, or some people call it 'MIB value') you can use to extract some information from an enumerable SNMP service. OIDView keeps a comprehensive list of more than 7000 MIB values from more than 500 vendors.

My personal favorites for Microsoft Windows are

1.3.6.1.2.1.25.4.2.1.2 gives you a list of all running processes on the machine. Very handy to figure out the possibility of, say, future escalation vulnerability if a specific application is running.
1.3.6.1.2.1.25.6.3.1.2 gives you a list of installed software and Windows hotfixes & updates. Very useful to probe for missing patches in, say, IE. Now you can send a link to a specific exploit to the user of that machine via email.
1.3.6.1.2.1.25.6.3.1.5 gives you a list of when those patches were installed. Very nice to know how often the system is maintained. Gives you ideas on how to proceed with your post-exploitation.
1.3.6.1.4.1.311.1.13 gives you entries in the vent log. Very good to trace crashes in certain applications.

and the list goes on and on, and not just for Microsoft Windows, but also for hundreds of other products.


Jump box DNS in the public We have a jump box that allows people to connect via SSH into the system.

Would it be a security concern by adding a public DNS entry that points to the jump box? (Would this not be security through obscurity?)

Assuming our system is hardened, there is really nothing wrong with having a DNS entry to the jump box.

I suppose in principle that the DNS entry leaks a tiny amount of information, but assuming your DNS servers are tied down against third-party zone transfers, the only way to extract this from the DNS is to know it exists, so no information leakage there.  Most ssh attacks come from bots stepping through the whole IPv4 space looking for responses on port 22, and DNS entries have nothing to do with that.

I would probably name it something innocuous, though: ssh-gateway-to-the-vital-code-repository.example.com is not a great idea.

As you note in passing, there are a bunch of other measures well-designed for securing a jump box (including non-standard sshd ports, rate-limiting, disallowing password-based authentication / requiring 2FA, hardened OS).  I'd put a lot more time into them than into worrying about my DNS entry.


Partially forgotten encryption password for Windows users I encrypted important files with Veracrypt and I remember most of the password but some parts are forgotten. I need some advice as to what would be the most efficient way of getting the encryption password.

My operating system is Windows, I tried BASH solutions but I opened the Veracrypt volume via use of a hex editor and there was some data but I wasn't sure if it was the header key or what to do with it. When I tried using vUte with bash.exe binary for Windows it didn't work well and crushed. Is there an easier way to do this, especially for Windows users?

I've been trying to get the password for months now. Any help would be appreciated.

The reason no one has been answering your current question and the follow up question is that there is no existing Windows brute forcing software for the Veracrypt header. Your best bet would be to find a way to brute force the Veracrypt header with THC Hydra/Cygwin.


missing ESSID from aircrack-ng I'm using Mac OS X and I was able to sniff packet from my homeNetwork (in order to learn more about how things goes on).

I'm sending a deauth command to all my devices to disconnect them and then start sniffing. I've captured a handshake and I can tell that it's valid by testing it against aircrack-ng like on the image bellow.

But the problem is the missing ESSID that couldn't be verified even after using the suggested -e option.

Does anyone have an idea how to solve this?

This is the handshake .cap file if someone wanted to take a look at it. The ESSID is ooredooF00F62.

I just realized (with more research) that aircrack-ng needs a management frame containing the ESSID (it can be beacon/probe response/reassociation request) and two data frames containing the EAPOL messages.
so i just captured a beacon frame from the AP and then used the wireshark's mergecap tool to merge the 2 .cap files (beacon.cap and eapol.cap) and that worked perfectly!