What are effective ways to prevent targeted phishing? Phishing is a very serious problem that we face. Popular banks are often the biggest targets.  What methods can a bank website use to protect its self from phishing attacks? What security systems should someone use to protect themselves?   Why do these methods work?

I am assuming that the bank wants to protect its customers from phishing.  (Not its employees; that's a different problem, and if you want to know about that, you should ask that one separately in a different question.)

The bank should take several steps:

Avoid emailing out links to the site.  Go clobber the marketing team and get them to quit doing that.
Don't rely too much on passwords.  Use machine authentication, too.  For instance, you might use a secure persistent cookie, a Flash cookie, or some kind of fingerprinting of the user's browser and machine.  Passwords are inherently insecure against phishing.  The advantage of machine registration is that it authenticates the user's browser with a secret the user doesn't know.  If the user doesn't know the secret, the user can't be tricked into revealing it.  With the combination of machine authentication plus a password, the machine authentication does most of the authentication work, and the password just enables one to distinguish between the user and their roommate/spouse/child/etc.

Don't rely upon challenge questions to authenticate the user when the user logs in from a new computer.  Studies have shown that phishing sites can capture the answers to challenge questions, just like they do passwords.  Consider other methods of registering a new machine, e.g., email-based authentication.

Use back-end fraud detection methods, to detect malicious use of a stolen password.  You can look at whether this is a type of transaction the user has performed before, to a payee they have transacted with before, whether the amount is large or not, whether the user IP address and geographic location and browser fingerprinting looks like one that has been seen before, and many other statistical measures.
Participate in anti-phishing working groups.  Work to take down phishing sites quickly.  Support use of phishing blacklists in users' browser.  If a user logs in with a browser that is so old that it doesn't support a phishing blacklist, give the user a message that encourages them to upgrade their browser and gives them an easy link to do so.

Participate in anti-fraud working groups, and pressure the banking community to shut down global banks that facilitate online crime.  A recent study found that just 3 banks accounted for monetization of 95% of spam; if those 3 banks were shut down or cracked down on spammers, we might see a huge decrease in spam.  There is reason to believe that a similar phenomenom may hold for other elements of the underground economy, too.  Making cybercrime less profitable will benefit bank security across the board (not just in phishing), so is a promising angle.

Use site-wide SSL for the entire site and your entire online presence.  Buy an EV cert.  This gives users an extra cue (the green glow) that may help some alert users notice when they are under attack.
Enable Strict Transport Security (HSTS).  This tells browsers to only connect to you via HTTPS.  Paypal uses it.  You should too.  It is supported in recent versions of Firefox and Chrome.
Don't put padlock icons on your pages (e.g., positioned next to login forms), or otherwise spoof chrome elements in the content of your page.  When you do that, you are training users in a way that makes phishing attacks easier.
Digitally sign all email sent to customers.  There is some reason to believe that most customers have software that can check these signatures, and the signatures won't cause problems for the software that doesn't check the signature.  (Thanks to @AviD for this suggestion.)
Don't use SSNs for authentication anywhere in your business.  Make it less valuable for phishers to steal SSNs and other personal information.


Should I report to abuse@ about network scans? On one of my servers I run ssh on non-standard port, but still it was discovered by some botnet which is now trying to connect to my server (and, I believe, it scans Internet looking for ssh-enabled servers).
I use DenyHost, so their IPs are banned with netfilter and I also use keys instead of passwords so they probably do not have a chance, but my daily report is full of:

Failed logins from:
5.2.182.5 (static-5-2-182-5.rdsnet.ro): 1 time
5.135.140.175 (ns2312134.ovh.net): 1 time
31.131.250.186 (rg1.rivegauche.ru): 1 time
34.232.136.66 (ec2-34-232-136-66.compute-1.amazonaws.com): 1 time
...

I have 44 records today.

As a "good guy" what should I do about it? I can fetch abuse emails and write them i.e.:

$ whois 31.131.250.186
...
% Abuse contact for '31.131.248.0 - 31.131.255.255' is 'abuse@selectel.ru'

but is it worth doing? Will it help?

You could try to use ipset and just drop everything:

ipset create BlockTheRussians hash:ip

Next

ipset add BlockTheRussians <IP Address>  <-- Repeat for each IP

Finally

iptables -I INPUT -m set --match-set BlockTheRussians src -j DROP

Another thing worth installing is Fail2Ban.


Can wiped SSD data be recovered? I was reading another post on destroying IDE drives, and how you could remove data, wipe it, or just destroy the drive. The removed data would still be there in some state, although not easily reachable without software. Wiped data is just removed data, but it has been overwritten and is essentially gone. A destroyed disk, if done well enough, will remove everything, or make it nearly impossible to recover anything. According to my understanding.
What about a solid-state drive? Can the data on one of these be recovered once deleted? It seems that this would be the way to go if you constantly dealt with and removed sensitive data, but SSDs only have so long of a life span (again, as I understand).
Can data from an SSD be recovered in any way once it is removed, even if it has not been overwritten?

Yes.  If you do a normal format, the old data can be recovered.  A normal format only deletes/overwrites a tiny bit of filesystem metadata, but does not overwrite all of the data itself.  The data is still there.  This is especially true on SSDs, due to wear levelling and other features of SSDs.

The following research paper studies erasure of data on SSDs:

Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson.  Reliably Erasing Data From Flash-Based Solid State Drives.  USENIX Conference on File and Storage Technologies, 2011.

One takeaway lesson is that securely erasing data on a SSD is a bit tricky.  One reason is that overwriting data on a SSD doesn't work the way you'd think it does, due to wear-leveling and other features.  When you ask the SSD to "overwrite" an existing sector, it doesn't actually overwrite or delete the existing data immediately.  Instead, it writes the new data somewhere else and just change a pointer to point to the new version (leaving the old version laying around).  The old version may eventually get erased, or it may not.  As a result, even data you think you have erased, may still be present and accessible on the SSD.

Also, SSDs are a bit tricky to sanitize (erase completely), because the methods that used to work for magnetic HDDs don't necessarily work reliably on SSDs (due to the aforementioned wear levelling and other issues).  Consequently, utilities that are advertised as providing "secure drive erase" functionality may not be fully secure, if applied to a SSD.  For instance, the FAST paper found that, in most cases, performing a full overwrite of all of the data on the SSD twice was enough to sanitize the disk drive, but there were a few exceptional cases where some of the data still remained present.  There may be other reasons not to want to perform repeated overwrites of the full drive: it is very slow, and it may reduce the subsequent lifetime of the drive.

The FAST paper also found that degaussing (a standard method used for sanitizing magnetic hard drives) is not effective at all at sanitizing SSDs.

Moreover, the FAST paper found that standard utilities for sanitizing individual files were highly unreliable on SSDs: often a large fraction of the data remained present somewhere on the drive.  Therefore, you should assume there is no reliable way to securely erase individual files on a SSD; you need to sanitize the whole drive, as an entire unit.

The most reliable way to securely erase an entire SSD is to use the ATA Secure Erase command.  However, this is not foolproof.  The FAST paper found that most SSDs implement this correctly, but not all.  In particular, 8 of the 12 SSDs they studied supported ATA Secure Erase, and 4 did not.  Of the 8 that did support it, 3 had a buggy implementation.  1 buggy implementation was really bad: it reported success, but actually left the data laying around.  This is atrociously bad, because there is no way that software could detect the failure to erase.  2 buggy implementations failed and left old data laying around (under certain conditions), but at least they reported failure, so if the software that sends the ATA Secure Erase command checks the result code, at least the failure could be detected.

The other possible approach is to use full disk encryption: make sure the entire filesystem on the drive is encrypted from the start (e.g., Bitlocker, Truecrypt).  When you want to sanitize the drive, forget all the crypto keys and securely erase them, and then erase the drive as best as possible.  This may be a workable solution, though personally I would probably want to combine it with ATA Secure Erase, too, for best security.

See also the following questions on this site:

Is it enough to only wipe a flash drive once?
SSD (Flash Memory) security when data is encrypted in place
How can files be deleted in a HIPAA-compliant way?
Have anyone tried to extract the encryption key from a SSD?


How to get "Policy: X509v3 Any Policy" in a certificate generated with OpenSSL? I am trying to generate a certificate through OpenSSL which has the following line

X509v3 Certificate Policies:
    Policy: X509v3 Any Policy

But I end up getting

X509v3 Certificate Policies:
    Policy: itu-t

What change do I need in my openssl.cnf to get "X509v3 Any Policy"?

I don't see any itu-t reference in my cnf file - so I don't know where that is coming from?

There is probably a more elegant way to do it, but I add the following option to the [ v3_ca ] section of my OpenSSL configuration file:

certificatePolicies = 2.5.29.32.0

The OID values are available at http://www.alvestrand.no/objectid/2.5.29.32.0.html .


Has Linux Mint updated the OpenSSL library for LMDE (Heartbleed bug)? Background
I am using Linux Mint for one of my servers and have been trying to find out if the Linux Mint Debian Edition(LMDE) has updated their repositories with patches for the OpenSSL bug.

I have a different pure Debian server and Debian was quick to remedy the problem. However, after running an update on my LMDE system the the OpenSSL package version was the same as the compromised versions.

Question
Is there a LMDE patch for the OpenSSL libraries?

I am running LMDE as a workstation and I am afraid as of now (Wed Apr  9 11:28:14 UTC 2014) no patch has been released yet. All available patches have been applied by me and right now # openssl version -a shows OpenSSL 1.0.1e 11 Feb 2013.

You might want to consider changing your sources to point to Debian repos directly in order to get the update. I'll be doing this soon.

Just as a side note, LMDE is a desktop- rather than server-targeted distro. If you wish to be secure you should rather stick to Debian stable.

EDIT
If you wish to update the package please follow the steps:

Edit your /etc/apt/sources.list file, comment out whatever you have there and add the following line: deb http://ftp.us.debian.org/debian testing main contrib non-free (Note: you might just as well do this with apt-pinning but this way it's easier to go back to LMDE repos right after the update)
aptitude update
aptitude install openssl libssl1.0.0 to update the packages
aptitude show openssl to verify you have 1.0.1g-1 version (see here for explanation of version number)
Edit your /etc/apt/sources.list again, uncomment what you previously had there and comment out the deb http://ftp.us.debian.org/debian testing main contrib non-free line.
aptitude update and you're good to go :)


What does using a VPN offers over HTTPS + DoH in terms of protection? What are the security risks that someone using HTTPS (everywhere) + DoH is vulnerable to, comparing to someone using a "trusted" VPN?

A VPN provides an encrypted tunnel from the VPN client to the VPN exit. All that somebody in the path of the tunnel (like the ISP) can see is that there is some traffic between client and exit, including how much traffic and some timing. With HTTPS + DoH the application payloads and DNS lookups are encrypted too, but much more meta data are visible: the IP address of the servers visited, the domain names accessed since the majority of the TLS handshakes still use plain SNI (and no ESNI), the communication pattern to specific servers instead of only the aggregated traffic between VPN client and VPN exit etc. Based on these available information an active man in the middle can with a VPN only block the whole VPN, but with HTTPS + DoH do more targeted blocking for specific domains and IP addresses.
But with both VPN and HTTPS it is not possible to modify the traffic, only gain more (HTTPS+DpH) or less (VPN) information and do more (HTTPS+DoH) or less (VPN) targeted disruption of the traffic.


HPKP-based persistent denial-of-service attack on web sites HTTP Public Key Pinning (HPKP) is a standard that allows a HTTPS website to specify which certificates it trusts, and instruct the browser not to allow any connection to that site that's secured by any other certificate.

Can this be used to facilitate a persistent denial-of-service attack on a website? Suppose an attacker compromises a website like cnn.com (say). It seems like the adversary could configure the webserver to enable HSTS and HPKP, with a pinning policy that specifies a certificate controlled by the attacker. The attack might be discovered and the legitimate administrators regain control, but everyone who visits cnn.com in the meantime will receive a HSTS and HPKP policy and their browser will cache it. As a result, their browser won't allow any HTTP connection to cnn.com (due to the HSTS policy) and will only allow HTTPS connections if the server uses the pinned certificate and public key. But since the attacker specified the pinned cert, it might be using a private key controlled by the attacker and not known to cnn.com. Consequently, after the attacker is kicked off, cnn.com has no way to terminate a SSL session using that attacker-chosen private key. So, all future connections from those browsers to cnn.com will fail.

The HPKP standard does suggest that browsers should set a maximum age for these policies, but it also suggests setting the maximum age to 60 days. So, if I'm understanding this correctly, it means that if an attacker temporarily compromises a website, then the attacker can ensure that the website will be absolutely unreachable for the next 60 days for all users who visit the website during the brief time when the website is compromised. Basically, any user who visits the website at a time when it is controlled by the attacker is "poisoned" for the next 60 days, and the website appears simply unreachable.

As website breaches are not unheard-of, this seems like it would be a rather severe outcome. This is a rather unusual sort of denial-of-service attack: it allows for irreversible vandalism of a site that there's nothing the website admins can do anything about, except to wait. the It also looks like this attack could be exploited against any website, even one that's not currently using HPKP, HSTS, or even HTTPS.

Have I understood this correctly? Are there any mitigations that a website can take to prevent itself from being DoS'ed in this way? Is there an argument that HPKP doesn't introduce any new DoS risk that's any more severe than what already existed before HPKP? Has this kind of persistent DoS attack ever been observed in the wild?

I've read RFC 7469, the standard that describes HPKP, and it doesn't seem to have any mitigation. It appears the attack I described would qualify as an instance of 'hostile pinning', but the standard doesn't seem to mention any useful mitigation for hostile pinning (apart from the max-age).

Reading through this memo, a link is given to the un-pin draft of Perrin here. I see two countermeasures against the scenario which you describe in this draft:

Let's start with the first one, which can be interpreted in different ways:

  Whenever a client performing "pin activation" sees a hostname and TSK combination not represented in the "pin activation" pin store, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days.

In my interpretation, the implementation of the above paragraph would mean that an attacker can only activate new pins for a very limited timespan. However, the attacker could still revoke older pins, it seems. Therefore, we move on to the second countermeasure described:

  Nonrevokable tacks:
  A tack with generation 255 cannot be revoked. Such tacks MAY be used to minimize the risk that a compromised TSK private key could be used to affect site availability.

Thus, a server that has issued a non-revokable tack, could in fact keep using this tack forever. How I read that is that a server could create a key pair which is does NOT use, but for which it creates a non-revokable tack. (In Perrin's implementation, this would become one of the maximum of two PINs which cannot be deleted). In case the server is compromised, this key can be retrieved and used to undo the attacker's changes.

Whether or not this is implemented in current browsers, I don't know.

Edit:
As @StackzOfZtuff pointed out in one of the comments, there is actually a transcript of an email conversation between IETF:WEBSEC and Perrin, pointing out to implement a TACK-like mechanism for HSTS.


Is it safe to upload a read-only encrypted volume to a cloud folder? I know keeping an active encrypted volume (like a VeraCrypt drive or a simple zip folder encrypted with AES256) on Dropbox/OneDrive/Gdrive/etc. is risky; data can be corrupted and the pattern of modifications can be a clue to an adversary, as is well explained in this thread. But what if it is never modified or shared, is it still risky?

If it is never modified, and is always at rest, then the confidentiality of the contents will be as strong as the encryption key. In other words, an attacker would need to know the encryption key (or the password it is derived from) in order to decrypt the contents. However, know that VeraCrypt uses XTS mode, which is not authenticated. An unauthenticated mode means that it may be possible for an attacker to make predictable modifications to the plaintext just by modifying the ciphertext, without even knowing the key. For XTS, an attacker can randomize any 16 byte sector. If integrity is not part of your threat model (for example, if you digitally sign the volume), then this is not an issue.


Can a DV CA issue IP certificate I understand that according to CA/B, CA can issue certificate to a public IP address if the validation challenge is satisfied. But can a DV CA issue IP certificates? (If their CA policy allows) Does CA/B allow a DV CA to issue IP certificate?

(Since most CA providers only issue IP certificate to OV identity...)

Does CA/B allow a DV CA to issue IP certificate?

No, CAB Forum baseline requirements don't mention DV or OV requirements for IP addresses. However, DV certificate issuance to IP address is not allowed by validation procedures. You will have to prove that you own specified public IP address. IANA and delegated regional registrars (RIPE, ARIN, etc.) lease IP addresses only to organizations. As private person, you can lease IP address from ISP, but you can't prove to CA that you own this IP address. Therefore, private persons can't pass IP address ownership validation procedures.
Here is a link to relevant CAB Forum page: https://cabforum.org/2019/02/09/ballot-sc7-update-ip-address-validation-methods/
And some excerpts:

IP Address Contact: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.
IP Address Registration Authority: The  Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
<...>
The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the IP Address Registration Authority as representing the IP Address Contact for every IP Address being verified using the email, fax, SMS, or postal mail.

Given this, as long as you are not identified by IP address registrar, you barely can prove that you own the IP address in the request.


When detecting a DDoS attack, do you just block that with your firewall or do you report it to the source providers? We are receiving a large load of connections, over 10 million per day, over multiple ports (80, 443, 8080, 8888, and 4072).

This has been going on for 4 days now and it does not look like it is going down.

99.9% of those are blocked at our firewall, a few go to Apache. It is difficult to say how much of our system it uses, I would say less than 3%.

Now, it feels like the attack is not going to stop by itself any time soon. Once you protected your system, do you generally contact the ISPs that "participate" in the attack to ask them to stop the offenders?

The attack encompasses well over 2,000 IP addresses from many different providers. So it looks like a rather daunting task to work on such a large number of people, especially because they generally are suspicious of you rather than the attackers/offenders... (i.e. maybe I'm trying to stop a competitor's business and not a hacker.)

Would there instead be a blacklist place were I can provide all the offending IP addresses?

Its not just like this, you should always report such incidents to abuse mail ids of concerned infrastructure.

Many a times the machines involved in DDoS is not known to the owner of the machine, like for ex :-
1. person hosted DNS server and unknowingly left it open for world (open resolver kind of stuff).
2. machine is under the control of RAT or TROJAN

Informing such incidents will help all of us to overall reduce the impact of DDoS which has gone up to 1 Tbps in the recent past.

Moreover you can contribute to centralised repositories too.


MySQL vulnerability bind address 127.0.0.1 Am I safe from MySQL access from another host even if they know the credential of my database, including the port?

As far as I know the bing port doesn't allow any remote access. Correct me if I'm wrong.

Am I safe from mysql access from another host EVEN if they know my mysql credentials and port?

I wouldn't say "Yes". It, however, doesn't allow remote connections.

It's very likely that you'll have some sort of application hosted on the same server. So, if you leave anything like phpMyAdmin or Adminer, an attacker can easily get in using your credentials.


How to refuse delivering emails that are not signed by trusted PGP keys? I'm fed up by spam and would like to have an email address that will only deliver mails signed by users I declared trusted. Some kind of purgatory for mails the signatures of which are trustworthy by a Web of Trust connection would of course also be a nice feature. Is there a either provider that offers this service, or at least a (preferably FOSS) mail server setup for self-hosting?

Any Unix MTA can pipe mail to a script. Run signature checks on the server and if the script returns true, pass the mail on. See your favorite MTA's documentation for an explanation of how. This is the same kind of setup used to create listserves.


Can MitM spoof a signed certificate by imitating the Certificate Authority? I understand that a signed certificate is a server public key signed by the private key of a certificate authority. As a result, a client allegedly rest assured that the signed public key is for the desired server. Really? How does the client get the public key of the certificate authority? Can't the attacker just sign his own public key and spoof the CA by providing the client with the wrong public key to decrypt the certificate? I'm assuming, of course, that the attacker has control of the network, including DNS.

My guess is that the CA's public key has to be a preshared key or else you're vulnerable. In my browser I see a list of certificate authorities like verisign and digicert. If these are preshared (say at windows/browser install), what happens if that store is ever updated or compromised (say by a virus, official looking request to install a new one, or an unscrupulous network admin). Could you then steal whatever you wanted? Answer goes to clear, concise explanation that shows how this really works and addresses these either real or perceived vulnerabilities.

How does the client get the public key of the certificate authority?

The certificate store is created at (OS/Application) install time, and updated as part of normal secured (OS/Application) updates.  Firefox is notable as an application that uses it's own cert store.  Because root certificates are pulled from a local store rather than over the network, they are immune to MITM attacks.

  what happens if that store is ever updated or compromised

If a bogus root certificate is added to the cert store, then its owner can forge certificates for arbitrary destinations (e.g., your-bank.com) and intercept your communication.  In a corporate environment, that's called SSL Interception and it may be performed legitimately, with your administrator installing the necessary certificate.  Yes, (an attacker | your employer) can use this to view and modify your web sessions.

If an attacker manages to do that, you're in trouble, but then, if they have the access and privileges to do that, you're in pretty big trouble already - your PC is already compromised enough to be keylogged.

It's possible to detect this sort of MITM by reviewing the certificate used in a session; in Chrome, this can be done by right-clicking on the lock icon and selecting "Certificate".  However, that's a manual process, and hard to do at scale.


Is there any risk in allowing ping packets *out* through a firewall The company I'm currently doing work for does not allow ping requests out through their firewall, for "security reasons" and I'm baffled as to why this is a concern.

Before you point me to (e.g.) this question, note that I'm not talking about responding to ping requests made from outside the network.  I'm talking about pinging from inside the corporate network.

So, for instance, I was trying to resolve a networking problem on a Linux VM, and (naively) assumed pinging google.com would tell me if I had any connectivity at all(mtr was not installed on this VM, or I would have used that), and all signs pointed to some network problem, or change in the configuration of the proxy server I had previously been able to get through (using cntlm).

Is there really a legitimate reason to prevent your own users from pinging outside servers?

If you're allowing ICMP echo requests (type 8, code 0), then presumably you'll be allowing ICMP echo replies (type 0, code 0) back in. ICMP echo replies can be used for inverse mapping of a target network, even when there's a filtering device (such as a firewall on the perimeter). This is an old attack though and modern firewalls can easily block it (assuming they're correctly configured).

The Smurf DDOS attack first exploits an intermediary network that'll respond to broadcast icmp message and in turn sends out IMCP echo requests to a subsequent victim.

Here's a white paper on ICMP attacks - it's old but still valid and contains good information.

C&C communications is already well covered above but here's a another old paper on covert channels that shows some examples, specifically around Loki's use of echo requests and replies.

It's also possible to use ptunnel to set up a TCP connection using ICMP echo requests and replies, thus bypassing other firewall restrictions (if you've allowed ICMP requests out and replies in). In previous testing, this connection has been reliable and resilient.


Are photographs of fingerprints a security risk? It should be trivial to get fingerprint patterns for many of the most important people in the world, as they frequently (enough) wave their hand, palms forward, to many HD cameras.
Is it possible to gather this information of fingertips to overcome fingerprint security systems?

I understand that fingerprint security systems would always use defense in depth strategies, but if peoples' fingerprints are so easy to obtain (by just analyzing their photographs), why respect them as secure in the first place?

An excellent slideshow on this topic (in my opinion) is the one from Marc Rogers.
Basically, he says the following:

Most fingerprint systems can be hacked
Fingerprint security provides convenient security, not military grade security

I also like the analogy in his explanation:
Door locks have been defeated with increasing elaborate picking techniques
as long as they have been around.... but we still use them.
 - Security DOESNT have to be perfect.
 - It just has to be ENOUGH.

Fingerprint manufacturers are constantly looking for mechanisms which can detect 'liveness'. See for example this research.

In an ideal situation, fingerprints should not be used as the only factor to authenticate someone, but they can be used to provide access in case the system is 'almost' certain it is you that wants to enter (e.g. because it recognizes your clothes, or because your voice sounds familiar). If the system is not certain at all, it must still fallback to a better security measure (such as a complex password).


How to separate storing sensitive data and hash passwords? Scenario: I have a web application with an authentication system (classic). The application is basically an interface to a DB (MongoDB) which holds sensitive data. I properly hash the stored passwords.

Assuming hashing prevents the attacker from knowing the passwords when he already gained access to the DB:

Question 1: Is there a point for hashing passwords when you store all the data in one DB?

Question 2: What's the right way to separate sensitive data and credentials? Separate databases? Using Mongo's built-in auth system for user authentication maybe?

Regarding Question 1:

In general case — yes, it does. You don't know the details of a potential future attack so your job is to make an actual exploitation of any vulnerability as hard as it possible.

As you know, information security mission is to provide three values: confidentiality, integrity, and availability. Let's assume that a hacker gained a full copy of your DB (which affects confidentiality). Being able to log in as a user, he can take over integrity (by modifying user's data and performing actions on their's behalf) and availability (e.g. by changing email which can be used to regain access.

Before switching to question 2. As far as I know, MongoDB also has access control on a collection level, so it could help to limit attack propagation. You can also consider encrypting sensitive entries in a DB so unauthorized read-only access will won't be as critical.

Regarding Question 2:
There is no a right way because security decisions need to be done based on many factors which can be derived from risk-analysis. You can store user creds in a different DB or create a separate auth server, or use 3rd party auth services (OAuth).

The main goal here is to keep a balance between the price of implementing, supporting those security controls and a potential loss you might have in case of a data breach. My intuition is to keep it simple and follow basic security recommendation (like password hashing and access segregation using MongoDB access control tools) combined with other security controls of the system (like strict user input validation) you can find, for example, in OWASP ASVS checklist.


Are there services to detect data breaches? There have been quite a lot of data breaches in the past and I wonder how the companies got to know them. Were they only finding it in the news? Did individuals inform them?
What about small data breaches, e.g. if you have a user who has an account that was hacked but the exact same (email, password) combination is used in my service. Is it possible to get to know that and thus block the user?
If you have thousands of image/document files, is it possible to have something like a google alert to get a notification if the document has been shared (e.g. by creating a hash of the file)? Are there services providing that already?

There have been quite a lot of data breaches in the past and I wonder how the companies got to know them. Were they only finding it in the news? Did individuals inform them?

Depends on the person who hacked them. If its someone who does it for fun/research they may contact the company and tell them about their findings.

What about small data breaches, e.g. if you have a user who has an account that was hacked but the exact same (email, password) combination is used in my service. Is it possible to get to know that and thus block the user?

You can check that user's email on  www.haveibeenpwned.com

f you have thousands of image/document files, is it possible to have something like a google alert to get a notification if the document has been shared (e.g. by creating a hash of the file)? Are there services providing that already?

Yes you can. There are services for that.


Is there a way to verify a signed XML in Java .NET has this great way to sign and then verify the signature of an XML file. Is there a way in Java to verify an XML file that .NET has signed this way?

I'm no expert but I believe to suppliment what user2316037 stated I believe javax.xml.crypto.dsig which allows you to sign and validate an XML digital signature.I believe that is what you are looking to use.

Retrieved from:
http://www.oracle.com/technetwork/java/javamail/dig-signature-api-140772.html


How do I demonstrate OpenSSH redhat/centos patchlevel to auditors? A common problem is that Redhat backports security fixes leaving OpenSSH with an old, but not vulnerable, rpm version and ssh version string on Redhat and CentOS. This fools auditors.

Apparently, the solution is to provide the Redhat SAs to the auditor. But which ones?  How exactly do I do this?  Do I need to compile an SA for every vulnerability?

(What I'm trying at the moment is upgrading to the rpm most recently listed in a SA, then just providing the most recent SA should demonstrate the most recent package fix.)

Providing the SA and version should be good enough since the SSH patch has been implemented. If they have problems with this then they would have to take it up with Redhat version control themselves.

After all if you can demonstrate that the attack will not work because it has been patched, version number means nothing. It's already patched regardless of what the version says.


XSS prevention via JavaScript I am working on a XSS prevention via Javascript. I am using the following JS-Code for that:

(function () {
/*
XSS prevention via JavaScript
*/
var XSSObject = new Object();
XSSObject.lockdown = function (obj, name) {
    if (!String.prototype.startsWith) {
        try {
            if (Object.defineProperty) {
                Object.defineProperty(obj, name, {
                    configurable: false
                });
            }
        } catch (e) { };
    }
}
XSSObject.proxy = function (obj, name, report_function_name, exec_original) {
    var proxy = obj[name];
    obj[name] = function () {
        if (exec_original) {
            return proxy.apply(this, arguments);
        }
    };
    XSSObject.lockdown(obj, name);
};
XSSObject.proxy(window, 'alert', 'window.alert', false);
XSSObject.proxy(window, 'confirm', 'window.confirm', false);
XSSObject.proxy(window, 'prompt', 'window.prompt', false);
XSSObject.proxy(window, 'unescape', 'unescape', false);
XSSObject.proxy(document, 'write', 'document.write', false);
XSSObject.proxy(String, 'fromCharCode', 'String.fromCharCode', true);
})();

Using that script, it is not possible to execute the functions alert, confirm, prompt, unescape, write and fromCharCode.
Is there a way to bypass this prevention? If so, how and why?

Yes, there are ways to bypass this security measure. As pointed out in a comment:

var iframe = document.createElement('iframe');
iframe.srcdoc = '';
document.body.appendChild(iframe);
iframe.contentWindow.alert.call(window, 'hello');

The problem is that successfully blacklisting individual functions in such a complex language is an exercise in futility. Trying to prevent real-world attacks by blacklisting is downright quixotic.


Web & insecure HTTP - Using RSA for encrypting passwords on the client side I used client side password hashing in my register and login project.

Its purpose is to prevent passive adversaries/eavesdroppers from discovering users' plaintext passwords when HTTP requests are in transit.

But still an attacker can perform a brute-force attack against the hash; And i think most or at least many passwords will be discovered this way, because they are too weak to resist against powerful  brute-force attacks.

So I recently thought of using asymmetric encryption.

Passwords will be encrypted with a public key on the client side (with randomized padding to make brute-force attacks impossible).

Is this a good idea?

Is it worth its costs?

Do u know about any problems regarding such a scheme?

Any related info is appreciated.

Firstly, I'm assuming that you're doing this to weaken man in the middle attacks (which really are the only problem when it comes to plaintext passwords over insecure HTTP)

Client side hashing has little to no benefit. An attacker, on picking up the hash will not need to brute force the hash. All your server needs is the hash, so the attacker can simply craft a POST request with the hash in it and send it over. One doesn't need the plaintext to get in to the system.

Regarding your solution:

If you're using the same public key for all clients, then the situation is effectively the same. As an attacker all I need to sniff is the ciphertext you send over, and I can impersonate you by sending the same ciphertext.

What if you gave different public keys to each client on each login? Then I could launch a man in the middle attack where I swap the server's public key with my own, decrypt the ciphertext you send (this getting your plaintext, even better), and encrypt it with the server's public key.

There has got to be a way for the client to know which public key is correct. For that you'd need some kind of trust system. Where clients know which public keys correspond to which server. But that will lead to millions of public keys being stored in browsers. So you'd need some sort of certificate chaining system. And I think you realize where I'm going with this ;-)

TL;DR: Use HTTPS, client side encryption without a trust system is not any more secure than no encryption at all.

If you're worried about shared passwords on other sites being detected after breaking the hash, then both hashing and public key encryption are fine (public key encryption is better due to rainbow tables). Note that these will only foil the plans of a passive attacker. If the attacker mounts an active MITM attack, then they can change the JS code that you send and remove the encryption bits entirely.


Disable DES-CBC-SHA in schannel I have several IIS servers in house This includes IIS 6 and 7.x. When I have my external PCI scans run I'm still receiving alerts for having the weak protocol DES-CBC-SHA enabled.

I have the following registry keys set to disable weak protocols. My understanding was that shutting this protocol off this was included under the DES entry on the top line.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Ciphers/DES 56/56:  Enabled=0
Ciphers/RC2 40/128: Enabled=0
Ciphers/RC4 40/128: Enabled=0
Protocols/SSL 2.0/Server: Enabled=0
Protocols/PCT 1.0/Server: Enabled=0

My report indicates that this protocol is enabled for both TLSv1 and SSLv3.

What if anything am I missing in my settings that would make this display? How can I diagnose this internally to verify the scan is accurate?

Assuming IIS 7.x the settings you're looking for are located here:
Start > gpedit.msc > Computer Configuration > Admin Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order

To set the order in such a way as to eliminate your issues, check my answer here:
How to fix SSL 2.0 and BEAST on IIS

Also, though I doubt it's as comprehensive as your PCI compliance scans, you can check your setup at Qualys SSL Labs Server Test as an indicator of how you're progressing with the fix.

Unfortunately these settings are baked in for IIS 6.0 with no solution available.


Using credit card on non-secure website I have a question around giving credit card information on a non-secure web-site, with a seemingly sub-site that's secure. Is this truly secure? I read on another question answered on the forum to check for the source code and look for "Form Action = ", but there's nothing like that on the source page
No HTTPS on credit card entry form - can it be safe?

Here's the website: http://thaigardenoc.com/onlineorder.html

Thank you for your responses!

While the page itself isn't loaded over HTTP, the order display is an Iframe that's loaded over HTTP, but posts to an HTTPS page.

While the form itself posts to an HTTPS page, the loaded frame itself is HTTP.

This is insecure due to the fact that the content of the iframe has no integrity. The page itself could be modified by a MITM to post the form to a rogue service. If you inspect the form, you can see it's sending the payment to "spreedly", which upon searching is a credit card processor.

However, there is a click handler and submit handler for the forms.

These handlers have the ability to hijack that URL, and change it right before it actually posts. Creating another avenue for your card information to be stolen.

The ordering form itself is hosted on another site, http://onlineorders.wawio.com/menu/535fe1caf61e46ae172330d8 however when I try to put https I get an invalid name error, instead identifying itself as a site called "OpenDining". If you accept the error, it'll show you the page you requested.

Don't order through them. If you want to complain to them, go here http://www.wawio.com/es/contact-us


Odds of two messages sharing the same hash prefix If only the first h bits of a certain SHA256 hash H of a certain message M are known, and one had managed to successfully guess an input message M' whereby SHA256( M' ) yielded an H' whose first h bits match the known h bits of H, is there any way to formalize what the likelihood is that the guessed M' is identical to M?
ie.:

Pick any M, set H = SHA256( M )
Pick any M', set H' = SHA256( M' ), such that:
H[0..h] == H'[0..h]
What are the odds that M == M'?

Given that SHA256 is expected to be cryptographically unbiased, is it fair to assume that the likelihood is h / 256?
Bonus question:
What about HMAC-SHA256, where the message is also a given but the key is being guessed?
Barring an immediate answer, how would I approach this problem?
Edit:

My original question did not bound for the size of M. Let's assume a known fixed-length M of size m. Bonus points if you can describe a way to loosen these bounds and still formalize an approach to calculating collision odds.
If any additional bounds are required in order to formalize a response, feel free to introduce and justify them.
The best answers are supported by a rational that can be checked, followed and validated, not merely statements of fact.
I assume the overall odds of a hash collision in SHA256 will play into the final solution.
Bonus points if you can generalize your answer beyond SHA256.

In the problem description the length of the original message is not known or in any way restricted*. With this condition there is an unlimited number of messages which result in a specific hash. The odds that a single message is the correct one from a possible unlimited number of message with the same property (i.e. same hash prefix) is practically zero.

* This was true for the original problem description. The OP did change the question many hours after it was asked and answered, to add a restriction about the message length. For this see the other answer.


Isn't OAuth, OpenID, Facebook Connect, and others crazy from a security standpoint? I work with APIs all the time and I work with web developers who insist that OAuth, OpenID, etc are far superior than a home-brew method. Every site seems to be using these as well now for ease of use to the user, but also for security. I hear it every day almost that it's more secure, but I find that extremely hard to believe for a few reasons:

If a hacker somehow gets your password to one site, he know has access to the majority of the sites you visit now.
It makes phishing 10x easier. With so many people using the same logins and doing it over, and over again people are less likely to actually read everything and check the URL up top.

Could you list of more reasons why it's unsafe or could you explain to me why it is more safe? I don't see why you would put up with the hassle of integrating one of these when it seems like a user would be fine entering in 3 fields (username, password, email) instead of clicking service logo to login (Twitter, Google, FB etc), entering in their username/password, clicking submit, clicking approve.

==Update==

To expand on my question as per request.

To my two points above, #1, doesn't matter how the hacker gets it. I'm not sure how to expand upon it exactly. You could brute force it, guess it, use the forgot password and do a dictionary attack on common questions, etc. But however you do it my point is, 1 password to access 1000 servers is far less safe than 1000 passwords to access 1000 different sites. I can personally guess a few of my friends' and family's passwords and ill have access to all kinds of accounts. I wouldn't even have to look for them. As i browse the web ill just be logged in... If i was a hacker, many of these passwords are very easy to crack. Some of my friend's passwords are, pepsi, tina(then birth year), 123456, and other stupid ones. My favorite though is tomcruisesucks LOL.

For #2 point, to expand further, I might go to http://wired.com, http://klout.com, http://twitter.com, http://thenextweb.com and they all have a Twitter login. I trust the sites (for the most part) so, honestly, I don't check the URL of the popup window that comes up to login anymore and I assume most do not. That popup window could have been easily hacked by a hacker getting on one of their servers, or an evil employee, or just a fake app site that a bot is sending to people over twitter that multiple people then login to this fake app, but using the Twitter login.

People are so used to seeing the same login pages they don't look anymore. If this thread gets popular enough I can easily do a super simple test on Twitter or FB by sending everyone a link to a fake app, have a popup window that looks like Twitter or FB and they'll login. I guarantee it. If i make the login screen go to, lets say, http://bankofamerica.com or http://paypal.com they'll ask themselves why am i here, why do they need this info, etc. The same sites used to login over and over again is extremely bad in practice.

That's my expanded discussion point ;)

I guess there is no really good solution for everday websites (e. g. not high profile sites such as banks for which users accept and economic allows a two factor authentication). One can only pick a solution which as little negative impact as possible.

Unfortunately people are not good at remembering a huge number of passwords. This results in either them reusing the same password on different services or writing them down (on paper or a password manager). Yes, there is the advice to create a password system including the site name.

But people are lazy. Password reuse is worse than a central account because it means that a vulnerability in any applications reveals the password.

In the Stendhal game most of the account hacks are done by family members. I guess that is special for games. The next group is random guessing of usernames/passwords. But there is a small number of hack attempts that are based on getting access to the email account. While we do not allow automatic password reset using email, many website do. Twitter's upper management was hacked exploiting an expired Hotmail email account and reused passwords.

So if you consider to allow password reset via email, there is little additional risk in delegating the authentication process to the big companies. All of them have measure in place to make it more difficult for attackers (recovery via mobile phone messages in case of suspicious activity, login history, warnings about login attempts from other counties, etc). It is a lot of work to implement those in your own site.

On a personal note, I would have preferred the Account Manager approach (specification) over trusting one of those companies. Plus, it does not have the phishing problem. Unfortunately the project does not seem to make any progress.

In the end we decided for Stendhal to support both OpenID and local accounts and let the users decide.


Insider threats vs. insider attacks I understand that a threat is a possible security violation that might exploit the vulnerability of a system, and a attack is an action on a system that harms the organisation in some way. Therefore, we should detect attacks and prevent or mitigate threats.
However, when I look on multiple cybersecurity sources focused on insider issues, the most of them talk only about the insider threats and do not talk about the insider attacks at all. In addition, they multiple times use the term insider threat even for actions that should be considered as attacks. You can see it, for example, in:

https://www.researchgate.net/publication/332216404_Insight_Into_Insiders_and_IT_A_Survey_of_Insider_Threat_Taxonomies_Analysis_Modeling_and_Countermeasures
https://link.springer.com/article/10.1186/s41044-016-0006-0
https://ieeexplore.ieee.org/abstract/document/8278157

Can, please, someone explain me, what is the difference between insider attack and insider threat? Why it seems that it has a different meaning regarding insiders than in general usage? Why is mostly used term just insider threat?

When we look at basic definitions of the terms threat and attack, we assume that there are two different entities while most don't realize that one could very easily be the cause for the other. Meaning, a threat exists and hence an attack would be possible. So when you talk about a threat, you are automatically talking about all the possible attacks that the threat might result in.
Having a weak password policy is a threat, and hence someone guessing your password as an attack is a very plausible scenario.
So when we talking about Insider threats, we are usually also combining the possible insider attacks that could result due to the presence of this threat.
Not having adequate controls over access and auditing of an employees actions is a threat, and this threat may result in a number of insider attacks which may include things like "An employee stealing or leaking confidential information".
When talking about insider threats, we usually will only see these "insider attacks" after it has happened, and not while the insider threat is being exploited, unlike external threats where we define marked boundaries between internal and external attack surfaces. So you can easily position a system at this boundary and detect an anomaly and maybe stop it before it causes harm.
To give a very basic example, for my home, I can have a security guard or an alarm system to alert me of any external threat/attack and you may prevent it with its help. My kids can steal a cookie from the cookie jar, which is an insider threat and all I can do is put it high above their reach to eliminate the threat.
Hope that helps clears your confusion.


Gmail X.509 certificate chain I have asked about this on several forums but never got a straight answer. If the root certificate on a certificate chain has a different fingerprint to the root certificate available for download on the CA's website, does this mean the chain is faked?

The GeoTrust root certs can be viewed here
None of them match the root cert on my chain which is;

GeoTrust Global CA
Identity: GeoTrust Global CA
Verified by
Expires: 08/21/2018

Subject Name
C (Country):    US
O (Organization):   GeoTrust Inc.
CN (Common Name):   GeoTrust Global CA

Issuer Name
C (Country):    US
O (Organization):   Equifax
OU (Organizational Unit):   Equifax Secure Certificate Authority

Issued Certificate
Version:    3
Serial Number:  12 BB E6
Not Valid Before:   2002-05-21
Not Valid After:    2018-08-21

Certificate Fingerprints
SHA1:   73 59 75 5C 6D F9 A0 AB C3 06 0B CE 36 95 64 C8 EC 45 42 A3
MD5:    2E 7D B2 A3 1D 0E 3D A4 B2 5F 49 B9 54 2A 2E 1A

Public Key Info
Key Algorithm:  RSA
Key Parameters: 05 00
Key Size:   2048
Key SHA1 Fingerprint:   C0 7A 98 68 8D 89 FB AB 05 64 0C 11 7D AA 7D 65 B8 CA CC 4E
Public Key: 30 82 01 0A 02 82 01 01 00 DA CC 18 63 30 FD F4 17 23 1A 56 7E 5B DF 3C 6C 38 E4 71 B7 78 91 D4 BC A1 D8 4C F8 A8 43 B6 03 E9 4D 21 07 08 88 DA 58 2F 66 39 29 BD 05 78 8B 9D 38 E8 05 B7 6A 7E 71 A4 E6 C4 60 A6 B0 EF 80 E4 89 28 0F 9E 25 D6 ED 83 F3 AD A6 91 C7 98 C9 42 18 35 14 9D AD 98 46 92 2E 4F CA F1 87 43 C1 16 95 57 2D 50 EF 89 2D 80 7A 57 AD F2 EE 5F 6B D2 00 8D B9 14 F8 14 15 35 D9 C0 46 A3 7B 72 C8 91 BF C9 55 2B CD D0 97 3E 9C 26 64 CC DF CE 83 19 71 CA 4E E6 D4 D5 7B A9 19 CD 55 DE C8 EC D2 5E 38 53 E5 5C 4F 8C 2D FE 50 23 36 FC 66 E6 CB 8E A4 39 19 00 B7 95 02 39 91 0B 0E FE 38 2E D1 1D 05 9A F6 4D 3E 6F 0F 07 1D AF 2C 1E 8F 60 39 E2 FA 36 53 13 39 D4 5E 26 2B DB 3D A8 14 BD 32 EB 18 03 28 52 04 71 E5 AB 33 3D E1 38 BB 07 36 84 62 9C 79 EA 16 30 F4 5F C0 2B E8 71 6B E4 F9 02 03 01 00 01

Extension
Identifier: 2.5.29.35
Value:  30 16 80 14 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 98 90 9F D4
Critical:   No

Subject Key Identifier
Key Identifier: C0 7A 98 68 8D 89 FB AB 05 64 0C 11 7D AA 7D 65 B8 CA CC 4E
Critical:   No

Basic Constraints
Certificate Authority:  Yes
Max Path Length:    Unlimited
Critical:   Yes

Key Usage
Usages: Digital signature
Critical:   Yes

Extension
Identifier: 2.5.29.31
Value:  30 31 30 2F A0 2D A0 2B 86 29 68 74 74 70 3A 2F 2F 63 72 6C 2E 67 65 6F 74 72 75 73 74 2E 63 6F 6D 2F 63 72 6C 73 2F 73 65 63 75 72 65 63 61 2E 63 72 6C
Critical:   No

Extension
Identifier: 2.5.29.32
Value:  30 45 30 43 06 04 55 1D 20 00 30 3B 30 39 06 08 2B 06 01 05 05 07 02 01 16 2D 68 74 74 70 73 3A 2F 2F 77 77 77 2E 67 65 6F 74 72 75 73 74 2E 63 6F 6D 2F 72 65 73 6F 75 72 63 65 73 2F 72 65 70 6F 73 69 74 6F 72 79
Critical:   No

Signature
Signature Algorithm:    SHA1 with RSA
Signature Parameters:   05 00
Signature:  76 E1 12 6E 4E 4B 16 12 86 30 06 B2 81 08 CF F0 08 C7 C7 71 7E 66 EE C2 ED D4 3B 1F FF F0 F0 C8 4E D6 43 38 B0 B9 30 7D 18 D0 55 83 A2 6A CB 36 11 9C E8 48 66 A3 6D 7F B8 13 D4 47 FE 8B 5A 5C 73 FC AE D9 1B 32 19 38 AB 97 34 14 AA 96 D2 EB A3 1C 14 08 49 B6 BB E5 91 EF 83 36 EB 1D 56 6F CA DA BC 73 63 90 E4 7F 7B 3E 22 CB 3D 07 ED 5F 38 74 9C E3 03 50 4E A1 AF 98 EE 61 F2 84 3F 12

Some public CAs have multiple roots, and more use multiple roots.

Assuming gmail means mail.google.com, as the (currently two) reports at SSLLabs show google uses its own intermediate CA, (CN) Google Internet Authority G2 issued under (CN) GeoTrust Global CA.

That Geotrust CA has a root cert with (SHA1) fingerprint beginning DE28, but also a nonroot bridge cert (included in server handshake) with fingerprint beginning 7359
under (OU) Equifax Secure Certificate Authority; that Equifax CA in turn has a root cert with fingerprint beginning D232 which was issued in 1998 so it was pretty well established and trusted when GeoTrust started in 2002 and initially was not trusted. Today the bridge cert shouldn't be needed, and pretty soon it will actually hurt because its chain expires sooner.

For more on Geotrust (and Google) anchoring, see:

google certificates correct CA
Different SSL cert behavior with Chrome on desktop vs. Chrome on iOS
What happens when certificates further up the chain expires before mine? (Equifax/GeoTrust)
https://serverfault.com/questions/589590/understanding-the-output-of-openssl-s-client

@Steffen's answer points to a comparable but slightly different case, multiple generations within Verisign.

UPDATE 2017: The Equifax root cert, and thus the GeoTrust bridge cert, are no longer valid using the MozillaNSS-also-curl truststore, see https://serverfault.com/a/841071/216633 .


Timeless timing attacks and response jitter I've been researching timeless timing attacks, ie: timing attacks using concurancy rather than round trip time. Here is an article by portswigger with links to the origional article by Van Goethem. Basically it says that if you pack two requests into a tcp packet for http2 or tor, then it will cancel out network jitter. I understand how this works when going from client => server, but when the server responds the http responses are in different packets again and so wouldn't they be effected by jitter on the return trip and could potentially arrive out of order? I haven't seen any mention of network jitter on the return trip from any of the articles I've read

Both requests are sent simultaneously, and are executed by the remote server concurrently. All the attacker needs to do is know which response came back first. Although there is jitter on the return path, they can tell at the very least which one was sent first (e.g. by TCP sequence numbers). The attack actually relies on the fact that the target server will not multiplex the response and will send each response in series. The order they come in tells the attacker which finished execution last.
The attacker doesn't need to worry about the response that was sent first "overtaking" the other response on its way back because these protocols typically contain information that ensures that packets will not be received (or at least processed) in a different order than they were intended.
This is not an attack against a specific application, and the attack is not a risk if the target server is not running any code that is vulnerable to timing attacks, but it does illustrate that existing timing attacks that were once thought to be too hard to exploit over a network may actually be exploitable.


Risks associated with distributing encrypted private key with our software? Our software contains two executables that need to serve data over SSL (and several that need to do requests over HTTPS)).
I notice that it is distributed with some .PEM files created with OpenSSL. These files are read by the software when it needs to consume or serve over HTTPS.
The second file says: BEGIN ENCRYPTED PRIVATE KEY

Question: If private keys should never be distributed, is it OK to distribute the encrypted version?
Do we run any risks with that?

I have read Is it bad practice to add an encrypted private key to source control?, but I'm still unclear about the possibility for others to do something malicious (spoofing?) with that encrypted private key.

(BTW There is actually a third intermediate certificate because of the issue of RapidSSL certificates not being trusted on Android, but that seems irrelevant to the question).

First file

Header:

Bag Attributes
    localKeyID: 01 00 00 00
    friendlyName: TimeTellbv wildcard
subject=/serialNumber=34VD79pOnKBR2dM5LC69jkD7PGuRM6VC/OU=GT04962750/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.timetellbv.nl
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
-----BEGIN CERTIFICATE-----

Converted to text with

c:\OpenSSL-Win32\bin\openssl x509 -in tt_https.pem -inform PEM -noout -text >tt_https.txt

it reads:

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 962889 (0xeb149)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=GeoTrust, Inc., CN=RapidSSL CA
    Validity
        Not Before: Oct 23 04:44:55 2013 GMT
        Not After : Oct 25 11:45:46 2016 GMT
    Subject: serialNumber=34VD79pOnKBR2dM5LC69jkD7PGuRM6VC, OU=GT04962750, OU=See www.rapidssl.com/resources/cps (c)13, OU=Domain Control Validated - RapidSSL(R), CN=*.timetellbv.nl
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:d4:a4:bf:b9:bb:cf:f9:e9:88:95:f3:e5:c7:b9:
                [snip]
                e7:27
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Authority Key Identifier:
            keyid:6B:69:3D:6A:18:42:4A:DD:8F:02:65:39:FD:35:24:86:78:91:16:30

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Alternative Name:
            DNS:*.timetellbv.nl, DNS:timetellbv.nl
        X509v3 CRL Distribution Points:

            Full Name:
              URI:http://rapidssl-crl.geotrust.com/crls/rapidssl.crl

        X509v3 Subject Key Identifier:
            CA:86:AC:B6:13:D3:96:F8:60:5F:DF:B2:F6:FA:28:E0:75:30:DB:D0
        X509v3 Basic Constraints: critical
            CA:FALSE
        Authority Information Access:
            OCSP - URI:http://rapidssl-ocsp.geotrust.com
            CA Issuers - URI:http://rapidssl-aia.geotrust.com/rapidssl.crt

        X509v3 Certificate Policies:
            Policy: 2.16.840.1.113733.1.7.54
              CPS: http://www.geotrust.com/resources/cps

Signature Algorithm: sha1WithRSAEncryption
     56:b9:59:c1:ed:d1:a5:84:2a:ce:96:14:0e:ad:db:fc:80:80:
     [snip]
     c7:7c:10:fb

Second file

Header:

Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: 01 00 00 00
    friendlyName: le-0f8807ed-4cbe-43a6-84a9-94ef82e3fd39
    Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
    X509v3 Key Usage: 10
-----BEGIN ENCRYPTED PRIVATE KEY-----

Conversion to text form fails:

c:\OpenSSL-Win32\bin\openssl x509 -in tt_https_key.pem -inform PEM -noout -text >tt_https_key.txt

unable to load certificate
2180:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib
.c:696:Expecting: TRUSTED CERTIFICATE

There are cases where you can actually distribute the private key (even unencrypted) but they are really borderline (for instance, you might want to lower the amount of ssl connections your server will accept before even performing client authentication but might not have the possibility of properly issuing each client his own client auth cert).

It doesn't looks like that's what you're doing here, though: that certificate is a wildcard server certificate certificate for the timetellbv.nl domain. It makes little sense to use that for client authentication (you would be better of using your own CA for that) so you're probably using it to serve file.

So, the next question would be: what type of deployment are we talking about ? If you're talking about a single-site deployment (i.e. that is your own certificate and you're deploying your own app on your own server), then it might be bad practice to place the certificates in the deployment package (see the question you linked), but it's not making your whole security invalid.

If, however, you're deploying an application from or to a third party, then this is a big no-no: the only way to make use of such certificate is to use it incorrectly: it is improper for identifying ANY system but the ones under the *.timetellbv.nl domain and shouldn't be used.

(As a side note, https://www.timetellbv.nl returns an invalid certificate: the DNS name does not match)


Could it be possible to diminish the damage of having one's VPS inspected by the host? I'm planning to run/have some quite sensitive data on a VPS, however, knowing well that the host could at any time access the data (rare but as long as it could happen in theory, I would very much like to have some sort of contingency planning down). Could it be possible to practice some sort of "damage control"?

For example, the method mentioned in:
https://www.howtogeek.com/123568/how-to-get-email-notifications-whenever-someone-logs-into-your-computer/

Would it be enough, as one would be notified whenever someone else accesses the server? Or can a host easily bypass it regardless? For example via a "maintenance" and then extraction, where internet would be off?

Although since most VPS providers claim 99% up-time and assuming that an "evil host" would probably initially check what's on a machine through internet first, inevitably having to log in. Would this be an okay method regardless?

Unless of course they have a very elaborate and near-impossible to detect monitoring software installed on every machine, which for example, occasionally takes screenshots, giving the provider information on which machine could be "interesting" to inspect further... although could this also, simply be combated by a re-formatting before usage?

Looking forward to any and all feedback

If you don't own the physical server, you cannot protect yourself. A VPS is virtual, so the hypervisor have total and absolute access to any data inside it. It can start a memory dump, or clone the disk, and your server don't even know.

They don't have to login, or take screenshots, or even reboot in a maintenance mode. They own the memory, they own the disk, they own the processors. They can even clone your VPS disk, put it on another VPS, and access everything. And all monitoring programs you have will not detect anything at all.

If you own the physical server, you have a better degree of protection. Depending on your budget, you can protect the chassis with an array of sensors that clears the RAM and resets the OS. An array of accelerometers can detect if your server is physically moved, and magnets and Hall Effect sensors can detect case opening. Light sensors and sound sensors can detect changes too, if they cut the case to avoid unscrewing it.

You will need to build this security appliance, wire it inside the case, and have your provider sign a document acknowledging they will not handle the server in any way without you being present. With this, you have a reasonable security, but will not be cheap.


How can I protect myself from KRACK when I can't afford a VPN? I'm always using Wi-Fi networks, since I move a lot. But I don't think I can afford a VPN for the moment (I know they're cheap) to protect myself against KRACK when connecting to those Wi-Fi networks.

So is there a way that can help me that doesn't make usage of a VPN?

Using a secure connection such as HTTPS helps against the attack. HTTPS Everywhere can help you ensure that HTTPS is used as much as possible:

Install the browser addon HTTPS Everywhere from the Electronic Frontier Foundation's official website: https://EFF.org/https-everywhere
Once done, click on the blue "S" icon of HTTPS Everywhere and tick on the box corresponding to "Block all unencrypted requests"

And that's it. However note that many websites may not work since they do not support HTTPS and/or don't have corresponding rulesets in HTTPS Everywhere*, so this is a better solution if you connect most of the time to HTTPS websites.

I also don't recommend free VPNs since they're more often than not malicious, and there's no way for you to be sure that they don't sniff on your traffic.

* : If you want to contribute more of those rulesets you may do so at their Github repository: https://github.com/EFForg/https-everywhere


Are hashing functions designed to be injective where the domain is limited to the codomain? Using the example of md5, I would like to know if

md5(h₀) == md5(h₁)

for some distinct md5 hashes h₀, h₁.

Are hashing algorithms generally designed to avoid this sort of collision? Do MD5, SHA1, SHA2, etc. behave differently in this regard?

Update:

I believe that I may not have been clear enough.

Given that md5 has only 16 bytes of output, Let's say I restrict my input only to binary strings of exactly 16 bytes in length, so that every h₀, h₁ is a potential output of md5 itself.

In the context of other hashing algorithms, let their corresponding hash lengths be used instead.

The question still remains.

As to your update, your standard cryptographic hash functions (MD5, SHA-1, SHA-2 family, SHA-3) try to approximate random oracles (and do not attempt to be injective).  That is they attempt to map any input to an output chosen uniformly at random in your output space (and do this mapping consistently).  With overwhelming probability, random oracles will not be injective when the number of possible inputs is significantly larger than the square root of the number of possible outputs, due to the birthday paradox.

For example, if you have a 128-bit hash output (a 16-byte hash with 2128 possible outputs) and use a random oracle to hash significantly more than sqrt(2128) = 264 inputs, it begins to become overwhelmingly probable that there will be collisions.  On the other hand, if you hash significantly fewer than 264 inputs, it will be very unlikely to have a collision if you started with an ideal random oracle.  (If you hash around 264 inputs than the chance of being injective is approximately 1/2; there may be a collision or not).

As a specific example, if you hash all 272 possible 9-byte inputs the probability of a random oracle being injective onto a 16-byte space is about exp(-n2/2m) ≈ 10-14231, where n = 272 ≈ 4.7 x 1021 and m = 2128 ≈ 3.4 x 1038.  This is incredibly unlikely; roughly equivalent to playing powerball (odds of winning 1 in 292 million) twice a week for 16 years and winning the jackpot each and every time with no losing tickets.  And again, this is only for a 9-byte input; with a 15-byte input the probability of being injective is about 10-1127492937032632506267955467381579!

Meanwhile, if you hash all possible 7-byte inputs, there's only 256 of them so with large probability there will be no collisions (that is it will be injective).  As this is significantly less than sqrt(2128), a random oracle would not be injective with probability with odds of 0.0000076 (about 1 in 130 000 times it would not be injective and the rest of the time it would be injective).

See the probability table on wikipedia for more information.

Granted this is not a proof for any specific hash function; to prove it we would have to generate a specific collision within the input space which would in general is difficult to show.

Now if you need an injective function that acts similar to a hash, this is quite simple to achieve by using a block cipher (formally known as a pseudorandom permutation) like AES and choose a random key to encrypt it with.  Block ciphers are necessarily both injective and surjective.  If a block cipher was not injective, then a person with the key and the decryption function and a block of ciphertext to decrypt with couldn't possibly recover the original block.

The downside of using a block cipher instead of a hash function is that the block cipher requires input of just one fixed length and transforms it into output of the same fixed length.  For example, AES can only take a input that is 128-bit and transform it into a 128-bit output.  (Yes you could use block cipher modes to transform larger inputs, but still for it to be one-to-one the output size would be the same length as the input).  The fact that a hash function can take variable sized inputs and output a fixed size hash makes it ideal for many purposes.  The fact that this requirement of hashes to map variable sized inputs taken from a very large input space into a smaller output space means that it will not be a injective by the pigeonhole principle is usually not a problem in practice.


How does Authenticator gets the PMK which is used to calculate PTK? I am trying to setup a Supplicant- authenticator and AAA server to perform EAPOL mechanism.

I am able to successfully completed the EAP authentication procedure but 4-way handshake was not initiated by Authenticator. I have 2 questions here.

How does authenticator know that it needs to perform 4-way handshake after successful EAP authentication.
How will Autheticator gets the PMK from RADIUS server. As the PMK/MSK is generated by both supplicant and RADIUS server separately.

This Master Key is passed in the Access-Accept message itself. RADIUS decoder for wireshark says it as Vendor specific attribute so I was not able to identify it initially.
Below RFC links explains in more detail about the Vendor specific attributes key passed during Access-Accept message.

https://tools.ietf.org/html/rfc2548#section-2.4.2

=====================================================
Wireshark traces of Access Accept showing Key transfer to Authenticator.


Double encryption with home brew algorithm Everyone says that home brew encryption is not a good idea because one day the algorithm will be known to attacker which sounds reasonable. So that seems it's main problem, on the other hand known algorithms are known to everyone and are most-likely safe to use. Would it make sense to some paranoid developer to create a scheme like that AES(HomeBrew(openText)) where HomeBrew will either provide an encryption or some other kind of transformation to make it harder for the attacker as they will have to guess those things even if they manage to break AES somehow (provided they do not have the algorithm). So won't we get best of both approaches in this case?

Standard encryption that is proven to be good
Unknown algorithm "just in case" that even in case of leaking will not provide much to attacker unless they know how to break AES

Kerckhoffs's principle states:

  A cryptosystem should be secure even if everything about the system,
  except the key, is public knowledge.

Therefore if AES is broken, your homebrew algorithm is likely to be much easier and would have been broken already.

I realise part of your original question stated:

provided they do not have the algorithm

However, as this violates Kerckhoffs's principle your home brew approach is in itself flawed and insecure.

The main reason this is a problem is that it is unquantifiable how much more security it adds to your system. I refer you to Thomas Pornin's answer to a similar question here:

  An additional twist is that algorithm obscurity can harm security.
  What I explain above is that obscurity cannot be trusted for security:
  it might increase security, but not by much (and you cannot really
  know "how much"). It turns out that it can also decrease security. The
  problem is the following: it is very hard to make a secure
  cryptographic algorithm. The only known method is to publish the
  algorithm and wait for the collective wisdom of cryptographers around
  the world to gnaw at it and reach a conclusion which can be expressed
  as either "can be broken that way" or "apparently robust". An
  algorithm is declared "good" only if it resisted the onslaught of
  dozens or hundreds of competent cryptographers for at least three or
  four years.

So therefore you should use another algorithm if you are worried that AES may soon be broken (that or don't use AES at all). I'm assuming the rest of your system isn't 100% secure - so instead of wasting time, effort, energy and resource on creating a home brew algorithm this effort should be spent elsewhere, where it can be  quantifiable that it is actually increasing security. All code has a cost, and it is not just the salary of the junior developer that is creating it. It needs to be maintained and understood by everybody - and each extra person that learns how it works is an extra avenue for the algorithm to be leaked. Don't waste your time.


How to Protect SQL Server 2005? My project's backend is SQL Server 2005 and I need to install this to customers' systems.

The problem is when someone logs onto the computer, they can easily access the SQL Server with Windows authentication. How can I protect the SQL server from local logins?

It's not possible to stop Windows local admins from accessing SQL server - see https://dba.stackexchange.com/questions/34684/restrict-access-for-windows-administrator.

By default, users who are not local admins will not be able access SQL Server with Windows Authentication. So the solution for you is to ensure your users are not local admins.


how to generate a pem certificate with Openssl using 'TLS1_ECDHE_RSA' ciphers for fips platform I am testing some ECDHE_RSA ciphers on FIPS platform But the handshake is failing because of the cert and key I am using on Server in OpenSSL.

Same cert and Key are working fine if the platform is non-fips.

I am using a Load Balancer between the client and server. Here is the Configuration:

Using Curl on the client:

curl -v -o ssl_ecdhe.txt -tls1.2 http://30.1.1.101/ssl_ecdhe.txt

Using Openssl on Server:

/usr/local/ssl/bin/openssl s_server -accept 443 -cert /root/2k.pem -key /root/2k.key -tls1_2 -named_curve secp384r1 -WWW -msg

Configuration on Load Balancer:

slb template server-ssl srvssl
  cipher TLS1_ECDHE_RSA_AES_128_SHA
  ec-name secp384r1
  version 33 33
!
slb server main-server 20.1.1.1
  port 443 tcp
    health-check-disable
!
slb service-group main-service-gp-ssl tcp
  member main-server 443
!
slb virtual-server main-vip 30.1.1.101
  port 80 http
    service-group main-service-gp-ssl
    template server-ssl srvssl

Certificate

Srv31(~)#openssl x509 -in 2k.pem -text -noout

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            d8:43:e6:a9:22:23:ea:49
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=California, L=SanJose, O=A1, OU=Regression, CN=Regression/emailAddress=regression@networks.com
        Validity
            Not Before: Sep 29 21:56:06 2008 GMT
            Not After : Sep 27 21:56:06 2018 GMT
        Subject: C=US, ST=California, L=SanJose, O=A1, OU=Regression, CN=Regression/emailAddress=regression@networks.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b9:b7:bd:68:39:16:7d:77:29:51:db:51:73:2f:
                    6b:83:36:df:0b:8c:d2:03:75:4c:02:2b:66:ea:8d:
                    95:70:eb:5d:c6:45:f8:58:e4:ae:8b:b4:05:29:11:
                    bd:93:f9:ef:97:33:ec:1a:c7:d2:d5:03:4a:a1:08:
                    3b:0b:a9:9c:f5:ad:14:e6:02:60:1a:67:e3:c4:c0:
                    ff:00:18:c4:78:5c:a1:16:d0:84:c7:ab:86:7c:42:
                    05:d8:2d:43:d3:f4:2b:d7:29:0f:7e:da:7f:88:1f:
                    92:81:65:0b:01:67:ac:5c:35:06:6d:77:9c:b2:b7:
                    a1:84:69:54:ca:df:5b:02:62:41:f1:7d:73:fe:c0:
                    52:ce:9f:58:c7:0b:18:87:78:eb:b1:9a:c6:af:c0:
                    86:ab:ab:e5:02:28:5a:44:aa:66:d2:e2:7b:60:a2:
                    93:63:6f:6a:15:7b:97:7a:57:8a:c3:41:ec:d2:38:
                    cd:ba:62:20:03:0c:ea:16:f1:45:3a:66:5e:1d:a1:
                    16:23:8e:09:72:76:d6:d6:2d:d5:2c:26:de:b3:56:
                    16:22:a7:15:49:7c:0a:07:74:4c:5a:e3:6e:fd:e4:
                    51:c9:58:f3:92:88:e2:89:af:a9:3c:36:39:d2:23:
                    cc:c0:32:f4:8d:63:bb:de:a4:cc:91:c3:75:77:8d:
                    aa:9b
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
        44:05:cb:91:d5:1d:f8:c7:21:7b:de:8e:be:bf:ed:c6:a8:f7:
        86:be:a8:a8:96:42:d6:b6:a3:d6:79:42:e4:37:0d:88:d8:e2:
        91:05:d1:45:14:0b:93:45:c2:97:f6:dc:0d:82:ae:97:9e:67:
        e1:70:44:0d:fa:ed:a1:e0:d6:7a:8f:27:97:4b:de:81:75:7b:
        5f:8d:86:28:e3:4d:19:24:a2:27:5f:76:cb:f2:ca:8b:3f:ff:
        d5:eb:b9:73:5c:a4:21:e9:30:15:50:bc:68:a2:55:50:67:b4:
        bb:2b:5e:a1:b1:9d:6d:1a:ca:29:ba:b1:74:62:a2:80:85:9e:
        85:48:96:66:d6:40:9b:fe:da:ee:fd:4a:32:ab:e0:b6:34:88:
        93:dd:92:60:0b:12:09:ae:b7:57:8a:c8:2b:0c:03:4c:75:fc:
        ed:0b:6c:a6:d3:9b:b7:d4:88:9e:35:f6:66:23:3b:2a:64:e6:
        a4:fa:d2:5a:68:81:02:4d:a8:0b:fd:a4:f2:a3:14:5e:26:fe:
        f5:cc:54:01:2e:bc:1e:ee:37:5d:3b:d7:0e:2e:5c:a5:e0:ce:
        79:ac:95:56:39:3b:b7:91:46:2f:30:c6:37:60:d0:07:11:58:
        d8:8d:40:a6:a1:00:51:7f:90:aa:67:23:12:e5:d6:25:11:8c:
        c4:45:32:7f

Please help me with this.

You don't describe exactly why the handshake is failing (error message) but claim that this is because of the certificate. An obvious problem with this certificate is the totally insecure signature algorithm MD5 which is usually not supported with TLS 1.2 clients anymore:

Signature Algorithm: md5WithRSAEncryption

Apart from that the certificate is self-signed, i.e. there is no trust path to a locally trusted certificate at the client.

Issuer: C=US, ST=California, L=SanJose, O=A1, OU=Regression, CN=Regression/emailAddress=regression@networks.com
Subject: C=US, ST=California, L=SanJose, O=A1, OU=Regression, CN=Regression/emailAddress=regression@networks.com

Also, the subject of the certificate does not match the URL which would also result in validation problems.

And finally this is a x509v1 certificate which compared to a x509v3 certificate has no information about usage restrictions, CRL and OCSP URL's, Subject Alternative Names etc.


How to get client to client login's log on domain server I have 100 clients that are joined to a domain. One of them is trying to do brute-force attack to the other clients. How can I get login failure logs on domain server about attacker logins?

I already enabled all audit policy settings that are related to the logins and I can see all the logs about login success/failure to the domain server but in this scenario I can not see any logs for client to client login failure.

I have a script that can help if you are on Windows Server:

function get-logonhistory{
Param (
 #get ip(127.0.0.1) and number of days you want get
 [string]$Computer = (Read-Host IP remoto do PC),
 [int]$Days = (Read-Host number of days)
 )
 cls
 $Result = @()
 Write-Host "wait..."
 $ELogs = Get-EventLog System -Source Microsoft-Windows-WinLogon -After (Get-Date).AddDays(-$Days) -ComputerName $Computer
 If ($ELogs)
 { Write-Host "processing..."
 ForEach ($Log in $ELogs)
 { If ($Log.InstanceId -eq 7001)
   { $ET = "Logon"
   }
   ElseIf ($Log.InstanceId -eq 7002)
   { $ET = "Logoff"
   }
   Else
   { Continue
   }
   $Result += New-Object PSObject -Property @{
    Time = $Log.TimeWritten
    'Event Type' = $ET
    User = (New-Object System.Security.Principal.SecurityIdentifier $Log.ReplacementStrings[1]).Translate([System.Security.Principal.NTAccount])
   }
 }
 $Result | Select Time,"Event Type",User | Sort Time -Descending | Out-GridView
 Write-Host "Done."
 }
 Else
 { Write-Host "Problem with ip $Computer."
 }
 }
#function call
get-logonhistory

Write-Host "Press any key ..."
#stop script to window dont close
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")


Using last characters of hash as salt In a recent discussion somebody mentioned the following hashing scheme:

passHash = sha256(password)
saltedHash = sha256(passHash+passHash.substr(-10)
finalHash = sha256(secret+saltedHash)

The password is hashed, then hashed again with the last 10 characters of the previous hash as 'salt'. Finally a secret is appended and everything is hashed again before it's saved to the database.

How secure is this? I know that equal passwords will have the same finalHash. But apart from that, how bad is it to use part of the hashed password as salt? Does having a secret salt later help? How bad is it to have only 3 iterations of sha256 instead of a few thousands? Is there an easy attack that proves this hashing scheme is bullshit?

Don't do it. Salts have to be unique, that's their only requirement. But your approach doesn't generate unique salts, but password-dependent ones.

A per-db-unique salt helps when its long enough (256 bits), and you also hash in the username, but that still leaves issues.

Having only 3 iterations of SHA256 is rather not the way password hashes should be, although its not just a 'higher is better'. If an attacker is busy doing lots of iterations of sha, they can't try new passwords. Make sure you use PBKDF2 or similar to prevent further attacks. You can take the logarithm by 2 from the iteration count, and then you get the added 'bits of security' for breaking a password. Iterations give you a tradeoff between computation power and security, but to a very (1:1 instead of 1:exp with password length) unefficient conversion rate.

What you are doing is not salting, its baking a new hashing function from another one. For every user, create a random string with 256 bits of entropy from a PRNG, and use that as salt.


Can MITM change the protocol? According to my experience surfing the web, many websites foo.com don't support https. When I go to https://foo.com, it just changes to foo.com

Can attackers forge the fact that foo.com doesn't support https and use http instead?

Contrary to the intuition, fact that https://foo.com changes to http://foo.com in modern browser means  foo.com does support https, and whoever is issuing the redirect has certificate for foo.com (and not any certificate, one that your browser trusts). Otherwise server at foo.com wouldn't be able to instruct your browser to redirect, because redirect command (Location: http://foo.com in combination with proper status code) is part of http protocol, which browser does not start to speak to the server in until the SSL handshake completed successfully.


Can a Windows program compromise the desktop hardware without giving administrator rights? If I run a program on a Windows 10 machine, can the program install a virus on an attached USB drive, and can it install a virus into the firmware of the computer to be loaded before the OS/bootloader?

Windows has a function of elevating user priviledges to administrator or something, right? Like a sudo equivalent popup dialog. Or can it do those things with just login in to a user that has administrator rights?

If I run a program on a Windows 10 machine, can the program install a virus on an attached USB drive

Yes. You don't need admin access to write to a USB drive.

  can it install a virus into the firmware of the computer to be loaded before the OS/bootloader?

It shouldn't be able to. Of course privilege escalation vulnerabilities are found all the time - so if you do not have the latest security updates installed or if the exploit used is previously unknown / microsoft are still working on a fix then should the program use one of these techniques it can do it.


How to filter https traffic in mod-security WAF? I'm developing a WAF with good GUI and better log. And my base firewall is mod-security. It works well for http but I also want to work my WAF with https. Any suggestions?

Terminate your SSL sessions as the very first thing you do at your reverse proxy / load balancer. Then feed the terminated sessions through your WAF, then to your regular daemon. Basically, you need to add another reverse proxy to the chain.


Portability of SED suppporting TCG Opal 2.0 I've ordered a Samsung SSD (850 PRO SATA) that supports TCG Opal 2.0.

At first I was planning on setting an HDD password (aka ATA password) via BIOS. But motherboard manufacturers don't seem to specify whether this functionality is supported by the mobos. My understanding, is that with TCG Opal we can skip the BIOS entirely and set the disk password using a tool such as sedutil. The disk itself then has a shadow operating system that asks for the password during boot, independently of the whatever operating system is in use (in my case linux) and of the BIOS.

I have two questions about drive portability and hibernation support.

Can I take an encrypted disk, with the password set (TCG Opal), and move it to a different computer? Since the password is stored inside the disk and handled by this shadow OS I'm assuming this will work, but I couldn't find confirmation anywhere.
Will hibernation work as usual, and is the password for the disk asked after booting the computer from hibernation?

Let me provide some extended details. I marked answer to your two questions with bold:

Most BIOS implementations support ATA Security feature set (also referred as ATA password or ATA Security Class 0) for SATA devices. If all that you need from SED is data encryption and locking with a single password then consider this option first.
MBR Shadowing feature allows host to unlock TCG Opal devices without any BIOS support. After power up device shows to host a special shadow PBA partition (Pre-Boot Authentication) instead of the original disk content. This partition contains code to unlock device and remove shadowing. BIOS loads this code and executes it (thinking that this is the actual OS). Only then the original disk content becomes visible and original boot loader is executed. Portability of such solution is lower because PBA code can't support all architectures (the sedutil you mentioned provides PBA image only for x86-compatible PCs and Macs) and can't unlock device after Sleep (S3 mode).
Shadow PBA works for Hibernation but it doesn't work for Sleep. Device is powered off in both cases, but BIOS loads system from scratch only for the first case. Device remains locked after waking up from Sleep and required TCG support from the OS or security application.
Code from shadow PBA partition does not manage the unlock password, it just provides a GUI to input it and to use it for authentication. The password (or usually its derivation) is managed by device firmware in a vendor-specific way.


PCI-SAQ A-EP compliance for website developer? I was part of a team that developed an e-commerce website (built with Wordpress & WooCommerce) for a client. They use StripeJS and PayPal Standard to process payments, and the site is hosted on a dedicated server with TLS from a trusted certificate authority. The client's digital security manager determined they needed PCI-DSS SAQ A-EP (which tallies with what Stripe themselves say). So far, so good.

However, now the client's bank have requested copies of their PCI SAQ, and asked us (as the website developers) to fill out a copy of the same SAQ in addition to the client's/merchant's copy. The bank have also separately asked for the hosting company to do the same.

As far as I'm aware, SAQ A-EP is only applicable to the merchant. We can certainly help them to fill it out, but I don't think we're supposed to be doing a separate one. Someone in the office suggested we should fill out SAQ-D and submit that instead, but as far as I can determine, SAQ D is supposed to be for merchants who don't fulfil any other SAQ category. I've suggested we push back on this, as it all seems a bit unclear.

Should we, as web developers (who are not at all involved with either hosting or payment processing), be completing a separate SAQ document when the merchant themselves are compliant with SAQ A-EP?

Note: at present we don't have a contractual liability clause with them, as the site quickly evolved from a static brochure to full online store in a very short period of time. We will be remedying this shortly.)

tl;dr you should probably contact a QSA and get them to help you navigate this. It sounds like the merchant is big enough to have the attention of their acquiring bank, which means you need to be on your game.
I am not a QSA, nor am I your QSA, but I do deal with PCI quite a bit. Depending on how you've implemented Stripe the merchant may actually qualify for the SAQ A, which is much preferred to the A-EP from your perspective.
However, if you go forward with the A-EP, here is why they're asking for stuff from you and the hosting provider:

Requirement 6: Develop and maintain secure systems and applications

The merchant didn't develop any of the software, they relied on you. Therefore the bank is going to expect you to pick up your end of requirement 6 as well as probably some others (12 comes to mind).

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 8: Identify and authenticate access to system components
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 12: Maintain a policy that addresses information security for all personnel

These are all likely applicable in some fashion to the hosting provider, as well as some I am sure I missed. This doesn't mention the additional requirements for shared hosting providers. Now, many reputable hosting companies are already PCI assessed and can provide an AOC on request (like AWS, for example).
Now, since neither you nor the hosting provider are actually merchants in the banks eyes, you would be filling out the SAQ D for Service Providers. Most of the requirements you can mark as N/A unless they would apply (like requirement 6). Then an authorized officer of your company would sign the attestation of compliance. This lets the merchant mark those requirements as N/A on their SAQ A-EP because they rely on a service provider (you).
Disclosure: I work at Braintree, which competes with Stripe and is part of PayPal, but this same advice would apply there too, unless you do the SAQ A as I mentioned first.


What does it mean when airodump-ng shows 0 beacons? I have one particular  AP that shows 0 Beacons in airodump. I can see the beacons in all the other AP without a problem. So is it even possible for AP to not send beacon frames?

It means the access point is a hidden station which means it does not send any beacons. Airodump knows of the network existence and it's SSID because the clients did revealed it. This is why a hidden station isn't a secure one. As soon as a client is connected at least the BISSD is visible to everyone with a card in monitor mode.


SSL question TLS response in TCP After some careful looking at one .pcap of my network i would like to undestand why a request appears on the communication like

IP [TLS Application Data] Application Data Protocol: http
   Version TLS: 1.0
   Encrypted Application Data: a44a55a5aa6aablabla

and then the reply from the destination IP is just a simple TCP packet(Protocol TCP no longer wireshark informs that the connection is ... TLS) with the ACK flag nothing more, what could cause such a strange end of the connection?

That's not the end of the connection, it's just an ACK. TLS operates over TCP (and IP), and the TLS records sent as TCP data are acknowledged just like the data on other TCP connections; in some cases this acknowledgement piggybacks on TCP data in the other direction and in some cases it is a packet carrying only ACK and no data. In the ACK-only case wireshark labels it TCP and not the app-level protocol (here TLS) because there is no app-level data (here TLS).

The way a TLS connection is closed normally is by sending an alert record of type close_notify in at least one direction, followed by a normal TCP close which sends and ACKs FIN in both directions using a variable number and sequence of packets depending on the dynamic state and timing; see any reference on TCP. A TLS connection can also be closed seminormally by just doing TCP close without the alert, or abnormally by doing TCP abort with (at least one) RST.

All alerts after the handshake completes are encrypted, so wireshark only decodes as Encrypted Alert (unless you enable wireshark to decrypt by giving it the server private key for a non-PFS RSA key-exchange connection, or the session key for the specific session). In principle several alerts are possible, but in practice if you see an alert after normal data exchange it's extremely likely to be close_notify.


is HttpOnly and Secure cookie enough to prevent CSRF in rest api? I created one RESTful API using spring. I am transmitting a secret key as HttpOnly & Secure cookie with login response.  After login every rest request will check with that cookie and update it every time.

Is it possible that my website is vulnerable to CSRF?
I am using spring MVC & Apache 2.4

First of all, CSRF and XSRF reffer both to Cross Site Request Forgery.

Second of all, unless you put an anti-CSRF token in a cookie, atleast the HttpOnly attribute should be set if possible.

There are situations where you can't set the HttpOnly attribute, an example is when you use javascript code which require to be able to read the value of the cookie (AngularJS).

If you serve your REST API over HTTPS, then the Secure attribute on the anti-CSRF cookie should be set as well.

This URL explains how to use and configure anti-CSRF tokens in the Spring MVC framework.

This URL explains how to use anti-CSRF tokens in PHP without using a PHP framework.

There are situation where an attacker is able to steal HttpOnly cookies:

The HTTP TRACE method is enabled
Outdated Apache (CVE-2012-0053) (< v2.2.22)

If these two conditions are not met, based on your description, I would say your code is sufficiently protected against CSRF attacks, especially since you use request based anti-CSRF tokens (I know banks that don't even do this). Good job! :)

However, do not try to re-invent the wheel. Personally I would try to implement a proper anti CSRF protection using the Spring MVE framework.