Email and Black Hole List Submission? I'm having trouble with a spammer and would like to begin submitting their messages to a few black hole lists.

Unfortunately, I'm having trouble finding a list. For example mail-abuse.org now redirects to Trend Micros and there's nothing of substance available (just a dashboard showing SPAM densities per country).

Are there any black hole lists remaining that accept submissions? What is state of the art in protection from targeted email?

Not used any of these myself but there are a few:

https://blackholemx.abusix.com/
http://www.sorbs.net/listing/submission.shtml
http://www.barracudacentral.org/rbl/how-to-use
http://www.spamhaus.org/faq/section/DNSBL%20Usage

State of the art protection is about blocking transmission as far upstream as you can. Ensure that you can blacklist as close to the edge of your network as possible. Better still get a specialist to handle you incoming mail before it gets to your network & only pass you cleansed email.

Our own stats from a 12k user system shows many millions of spam messages per month though we are probably a larger target than most.


How can I create a unique identifier that can not easily be reversed? I've been working on the design of a longitudinal study and one requirement is:

all participants will have a unique identifier that

is not reversible from the data storage/analyst side of the study
is defined by something easily remembered by a participant that is relatively static over several years, ex. a participant's proper name and birth date in a given format.
Creation of the unique identifier will occur on the participant's computer and no portion of the defining string will be sent with other collected data

How do I go about meeting this goal?

Initial thoughts are to use bcrypt or something similar but that runs into the problem that if there is a list of possible participant names and birthdays it becomes trivial to determine who participated and their answers. This hypothetical situation is not very likely but concerning.

I've looked into ID based cryptography as a possible answer but the increase in complexity and high likelihood of user error are prohibitive.

Am I missing a simple answer?

What you can do is to provide the participants any userID that is easy for them (like their email address, etc.) This userID is stored in a protected database that the analysts have no access to. When an analyst performs queries, the application creates random userIDs that are mapped to the real userIDs temporarily (even just for that session), thereby providing a unique "key" that might be required for typical SQL-like query tasks, but that "key" is decentralized from the real userID mapping. Once the random key is used, it is dumped and never associated with the user again. This creates a "double-blind" reference that will provide some protection.

There is still risk that a determined analyst might be able to pinpoint users due to aggregation issues, but that risk needs to be evaluated based on the type of data the analysts have access to.

The trick will be the application design that prevents analysts from accessing the userID data. That is a db-application level design issue that an architect can help with.


Does it make sense to keep encrypted versions of emails addresses? My boss came up with a strange idea in my opinion. He doesn't want to keep email addresses in the database. However, we use them to log people in, and we keep newsletters to those who actively gave consent. Also, every now and then, we have to contact the whole bulk of people. Even with those 3 cases, he doesn't want them clear in the database.

So he came up with this: after normalizing them (trimming space, lower casing them and a couple more conversions), I should strong hash them. This would give us access to the "login" part.

After that, he understood we still need email addresses for those that signed up in the newsletter. So he suggested to keep another field with an encrypted email address, but nil to those that don't want a newsletter. Enough to say, the key to decrypt the email address needs to be in the server, so that the process can be done automatically.

The third case. Those cases where we really need to contact them. It turns out keeping the whole encrypted list is okay, as long as the password is stored in paper. This means that every time we needed to get all the email addresses, human intervention is needed. Worth noting that email addresses are clear in the database until we also run a process where we introduce the "paper password", moment where clear email addresses are deleted. This process is done weekly, so there are 6 days with a good sum of clear email addresses.

Honestly, I could buy the hash part, but the other two could seem more of a problem for the everyday employee (partial email address searches was also a thing to look for specific clients that could have badly entered the email address in the process and needed a little bit of help) than for any hacker, that could anyway gain access to the code, or brute force the paper-password ones.

Does it make sense to try to obfuscate email addresses at that level?

Welcome to stackexchange.

The hashing of the email for the purposes of login seems reasonable. There is no real reason not to do it, most sites just don't care enough, which is rather sad.

Encrypting the emails for newsletter may seem rather useless, but it can actually help if done right. The trick is to isolate the web server, so either run it under a limited user, or use firebird or other virtualization method. Then make sure the key is somewhere the web server does not have access and make a cron job for sending the emails. Preferably don't use a web server at all or use another one for the email sending.

In both cases, for the newsletter and for contacting clients, you should use asymmetric cryptography instead, so that you can encrypt the mails without the key. Alternatively use a ratchet setup.

However, I must say this seems a bit excessive just to protect some e-mail addresses. Unless you work for some company the clients would not want to be associated with, such as Ashley Madison, it seems completely unnecessary.


What are the functional similarities and differences between TPM and SGX in trusted computing? I know about the TPM (Trusted Platform Module). In recent years, more researchers start to develop on Intel SGX, which I do not have any experience with.

They are both crypto chips, but what are their functional similarities and difference?
What can SGX achieve that typical TPM can't?

(If you want, explain it in "textbook" version or "practical" version.)

Well first off, SGX is not a crypto chip. It is a feature built into Intel chipsets themselves, whereas the TPM is often a discrete chip positioned on the LPC bus, though sometimes it can be emulated in the chipset (in which case it's called fTPM, for firmware TPM, or iTPM, for integrated TPM). On Intel processors, an integrated TPM will be present for any system that supports TXT.
Trusted Platform Module (TPM)
The TPM is designed to allow for measured boot, a boot process where each stage verifies the next stage in a chain of trust, reducing the Trusted Computing Base (TCB) to a much smaller amount of code. The way it works is by getting a hash of various firmware-related data and storing it in PCRs (registers in the TPM) and unsealing a secret value if this matches a known configuration. This all starts with the trusted CRTM (Core Root-of-Trust for Measurement), which is a, usually, read-only component of the BIOS that sends a hash of the BIOS itself to the TPM. If the CRTM and TPM are trusted, then the rest of the system need not be trusted.
A TPM cannot act on any detected integrity violations. It is entirely passive, existing only on the LPC bus. All it can do in response to a violation is refuse to unseal itself. This secret value can be something like an encryption key necessary to boot the system, or a secret string not known to attackers, allowing you to verify that the TPM has really unsealed even if it is communicating this to you over an untrusted medium. The TPM also contains an Endorsement Key, or EK, which verifies it as a genuine TPM. Only genuine and approved TPMs will be given this key. This is similar to the PKI infrastructure for HTTPS where a CA allows a browser to verify the legitimacy of the connection to a server.
TPM provides the following guarantees to a sysadmin:

The TPM will resist attempts at tampering (e.g. decapping and glitching attacks).
The sysadmin will be able to verify that the TPM is genuine.
The TPM will only unseal itself when hash values from the boot process are correct.
A key can be set so the TPM will not unseal unless the PCRs are valid and the key is provided.

The TPM is not limited to being unsealed at boot. It can be unsealed at any time. As a verified boot can also verify userspace applications, a TPM can even be used, indirectly, to attest to the fact that a system is running a given piece of software or is configured in a specific way. Once the BIOS, bootloader, and kernel are verified, it can verify that the system is in an arbitrary state, for example, has up to date software. Only when all of this is in a valid state will the TPM unseal itself, allowing it to prove to clients that it is running up to date and secure software. This is called remote attestation, which itself can be used as a building block for network access controls.
Note that this is a bit of a simplification of a TPM's functionality, and it does not go into the differences between SRTM and DRTM (Static and Dynamic Root-of-Trust for Measurement, respectively), but it should be sufficient for the purpose of describing the general functionality of the system.
Software Guard Extensions (SGX)
SGX has a different design goal and is a good bit more complex. SGX can provide confidentiality and integrity to processes, and can verify the executable code before executing it. It is an active feature, and encrypts processes running in a secure enclave while protecting them. The processes know that the enclave is genuine, preventing it from being spoofed via emulation, and the enclave knows that the process is genuine, preventing the untrusted host from giving it a compromised process.
The secure enclave cannot even be read by the kernel or any other privileged task once it is set up. Because of this, a process running in a secure enclave can, at worst, be killed or made to crash. It cannot be tampered with (even with JTAG, as probe mode is disabled in SGX context, or so I'm told). This can be used for things like running a virtual machine guest which does not need to trust the host.
SGX provides the following guarantees to a process running in a secure enclave:

The process will be able to verify that it is running on genuine SGX.
The host cannot tamper with the process once it is running in the enclave.
The process gets to define an I/O API for communicating with processes on the host.
The process' state will never exist in plaintext in memory.
The process will be verified before being run, ensuring that it is legitimate.

Typically, an application making use of SGX would have to be designed specifically for this purpose. The application would be written to have two components. The first component would run unconfined on the host, whereas the second would be run in a secure enclave. An I/O API is defined for allowing the two components to communicate with each other. Any sensitive computation can be offloaded to the process in the secure enclave.
While SGX protects the enclave from the host, it does not do much to protect the host from the enclave. A malicious or compromised enclave process could exit the enclave and execute arbitrary code on the host. This is due to the fact that the EEXIT instruction (see page 67), which exits the enclave, only restores a limited number of registers. In particular, it allows the enclave process to set RIP, the instruction pointer, and jump to an arbitrary address.
Similarities
The TPM merely tells you if your firmware or boot process has changed, and nothing more, whereas SGX is instead used to protect sensitive or confidential processes from the host. One similarity TPM and SGX have is that they both cannot be spoofed, allowing a system to know that it is talking to the real deal. Another is that they are both involved in the concept of trusted computing, reducing a system's TCB in various ways. Both systems have their own set of flaws. TPM version 1.1 and prior is vulnerable to the platform reset attack, for example. SGX is vulnerable to side-channel attacks, as two papers have recently shown.
Other than that, they are quite different, and they solve entirely different problems.


What are proper security precautions when enabling multiple connected social accounts or login/authorization methods? It is popular today for frameworks and social sites to enable multiple authorization options when creating websites. For example, allowing a user to login with GitHub, Twitter, Facebook, etc. In addition, identity verification using mobile verification codes is also becoming more common.

Enabling these features seems to bring an added security risk, if not handled appropriately. For example, when changing a password - users are asked to either provide their past password or reset the password via email - even if the user is currently logged in or authenticated. However, there are cases where a similar manner of identity verification is not enforced prior to adding connected accounts/logins.

What are recommended strategies or best practices for adding or modifying additional authorization/login options while following proper precautions?

Bear in mind that when you enable third-party account authentication in your application it is because you're delegating Identification AND Authentication to that third-party, that you choose to trust.
For instance, if the user chooses to login to your application using a third party account, your application doesn't have to be aware when the user changes his password. Rather it's up to your application to keep the user loged in permanently or ask him for login again (using the third party account) each time he get access.


How can Facial Recognition surveilance be misused by police? There has been a lot of news lately about facial recognition use by police forces being banned or that it should be banned.

The obvious example is that a police officer who is motivated by personal reasons to misuse the capability could do so. While I agree there is potential for misuse like this... I would assume measures could be put in place to prevent this from becoming a regular occurrence.

So assuming that we can prevent that type of misuse what other reason could there be for banning facial recognition system from being used by police?

There are several comments on here regarding false positives (which are a valid concern) and the question rules out a rouge officer mis-using the technology for personal reasons, but even if the technology is perfect there are other avenues of abuse.

Perfect facial recognition for example could be used to identify participants of political rallies and used as means to target them later when they are isolated in order to suppress views people in power don't like.

It may be that you trust the authorities in your country not to abuse the system like this, but what about when the next government or the one that's in power in 10 years time orders the police to behave in this way? Once the genie is out the bottle it's difficult to put it back in.


Read all git cached password in a 10+ people team we access the same ubuntu VM and we 'su' to the same user. On that user we make use of git-credential-cache feature to not type our personal password again and again.

As all password are stored using the socket owned by the same user, can a simple program retrieve all plaint text passwords? If yes, any pointers on how to demonstrate it?

If yes, we should definately change the way we cache passwords (a session token would be fine for us).

Yes, git-credential-cache has the built-in functionality to read the cache contents, you just need to run this command to obtain the stored credentials, including password in plain-text:

$ echo -ne 'username=<repo_user>\nprotocol=<repo_protocol>\nhost=<repo_host>\n' | git credential-cache get

For instance, if you are using https://git@github.com as your repository, you could extract stored credentials by doing this:

$ echo -ne 'username=git\nprotocol=https\nhost=github.com\n' | git credential-cache get
  username=your_github_user
  password=your_github_password_in_plaintext

The "username" part in the query is only required if you have more than one user working on the same repository (which I guess is your situation).


Why are full port scans more susceptible to being logged than half-open port scans? Many resources I come across state that one major advantage of full-port scans (e.g. SYN scans) is the fact that there is a lower risk of being logged. But why?

In my opinion, the sequence of segments exchanged in a SYN-scan (SYN >> SYN/ACK >> RST) seems way more suspicious/ abnormal than that of a full TCP-connect scan (SYN >> SYN/ACK >> ACK). Since the first SYN-segment already reveals information about the sender (ie. IP address, assuming no spoofing or proxy), I don't understand why a full connect scan is riskier than a half open scan.

Half-open scans are purely dealt with by the operating system, which is not likely to log anything unless a firewall like iptables is in place.  Once a full TCP handshake has taken place, however, the operating system hands the connection off to the application that's listening on that port, and the resulting hangup is likely to cause the application to log an error.

In short, half-open connections are quieter because they stay behind the scenes with the OS.


How can I prove to users of the software that the binaries I post match source code that's been inspected and verified by a third party? If I have software that's like TrueCrypt where security is very important, but unlike TrueCrypt because mine won't mysteriously go offline for seemingly no reason at all, how can I prove that my binaries that I post on the site match the source code that has been independently verified?

In this question, it seems independently building from the source code doesn't generate the same executable every time.

I want to be able to prove there are no backdoors, because this, unlike TrueCrypt, will involve remote data storage, and I don't want anyone to think keys could be leaked in any possible way at all.

You cannot prove that the binary you provide really matches a given source code. It is not theoretically impossible but it would require substantial cooperation on the part of the compiler. Some researchers are working on that subject for some languages which are better suited to that task than C (mostly ML or Lisp derivative). In any case, there is no readily available product yet, and won't be for some time, so in practice, that's not an option.

Your best options are then:

Provide the source code (with proof that it is the same archive as the one used by the independent reviewer) so that the users may do the compilation themselves.
Ask the people who ran the "independent review" to actually do the compilation and provide the resulting binary.

In any case, users will have to trust someone: you, the independent reviewers... in as much the same way as they have to trust Microsoft, Intel, AMD and all other parties involved in the building of the computer. So maybe the question is not the right one. The compiler itself may push a backdoor on clean source code (there is a very classic example of that kind of trick). Instead of asking how you could prove that the compilation step did not include a backdoor, you should ask: how may I build enough of a good reputation so that people will trust me ?


Confidentiality and integrity Users permissions and privilege should be considered as a part of confidentiality (specifically access control) or integrity?
And I'm also wondering if we can categorize Accountability, Authenticity and Non-repudiation as a sub-characteristics of integrity

Confidentiality and integrity are aspects of information security.
User permissions and privileges are security mechanisms that can be used to achieve them. So the answer to your first question, "should user permissions and privileges be considered as a part of confidentiality or integrity," is
No.

You can categorize accountability, authenticity and non-repudiation as sub-characteristics of integrity if you like to but that is largely a linguistic question. It does not have any practical consequences.


Is it possible to secure a web page from a Chrome extension? Detecting and outsmarting an AdBlocker is trivial, but this got me thinking about the issue in terms of a security battle between a page's native script and an extension. In terms of Chrome Extensions, is it possible to protect a user from himself? Lets say the user installs an ad blocker, and its actually stealing his credit card info. Does the web developer have the means to fight the actions of the extension via native page scripts?

Is this fundamentally possible? Why or why not?

No, because the user script/chrome extension could simply block the script element before it even loaded. A decently designed piece of malware would do this automatically.


Aren't endpoint devices inherently MFA? I was recently asked if MFA was leveraged for authentication on endpoint devices. My gut reaction is that given MFA is something you have, know, are, and you need to have the laptop to log into it and you need to know the password that laptops are inherently MFA. Is this incorrect?

EDIT: I'm realizing that my wording for this question was poor. The question specifically was "Is MFA enabled to login to endpoint devices?" To that point, they're specifically talking about accessing the endpoint device, not things which that device can access.

In the MFA model, it is understood that the multiple factors come from outside the authenticating process itself. Else all authenticating processes are inherently MFA (itself plus the user's credentials).

So, to the laptop, it does not count itself as a factor. There would need to be more external factors, like biometrics, tokens, one time codes, etc.


Wireless Access Point CONF? Edit Is it possible that for instance I have one access point that it requires a password for authorization to access to modem and internet.

I want to edit this step like a user when he/she click to the wireless adress as usual it will ask password of wifi and whatever when they typed correct or wrong password it will automatilly connect to the modem and i can see the password what they write?

If you're hacker, you can create "evil twin access point" or called "Rogue access point" by aircrack-ng suite or Reaver, and Pixiewps or
wifiphiser. After do follow instruction and wait maybe you can capture password what user login


SQL Injection How to inject Clean/Rest URLS I have a question I'm hoping you could help me with?

Unclean url's:

http://example.com/index.php?page=foo
http://example.com/products?category=2&pid=25
http://example.com/index.php?mod=profiles&id=193
http://example.com/kb/index.php?cat=8&id=41

Clean url's (the equivalent urls once they have been 'cleaned'):

http://example.com/foo
http://example.com/products/2/25
http://example.com/profiles/193
http://example.com/kb/8/41

Explanation of clean/unclean url's here

My question:

As you can see in the examples of unclean and clean url's above they obviously differ slightly.

With the unclean url's it would be possible to test for a possible sql injection vulnerabilities by appending an apostrophe (') to the end of the url and so on...

for example http://example.com/products?category=2&pid=25' and then looking at the response lengths it returns.

I am aware that using clean/rest url's does not make it any less vulnerable to sql injection and is mainly used for SEO, usability and so on (although also making it more difficult for automated sql injection tools) , but how would you go about injecting these types of url and is there a particular, preferred/best method to use?

for example would the following work for injecting clean url's (using an apostrophe)?

http://example.com/kb/8'/41

or

http://example.com/products/2'/25

or

http://example.com/services/legal/patents'

and so on...  or is there a preferred/better method.

Your help with this question would be much appreciated, many thanks

There is no magic test for testing for sql injection. Some applications may be vulnerable when using a certain approach and others when using another.

There is a chance that http://example.com/kb/8'/41 would not work because apostrophes are blocked by an IPS, but http://example.com/kb/7%2B/41 would display the same result as http://example.com/kb/8/41 and this would give you the information that there is a problem there.

Just testing with quotes is a little better than not testing at all, but cannot be labeled as a security evaluation. Such a process involves a complex assesment of all the posible entry points in your application(parameters, cookies, headers, etc) and several other more complex tests.

If you have the possibility, the best solution is to use a white box approach and also review the code. This way you could clearly see if a certain parameter is properly sanitized or not.


Does a flatbed scanner remember any of its previous scans? I'm about to get rid of an older scanner and I want to make sure that no one is able to acquire any sensitive information that was scanned previously with the machine. I assume it does have some kind of internal memory. How long does it store scans? Until I turn the scanner off or unplug it? Can I check/erase it? Is there a hard-reset button on the machine that resets to factory defaults?

My scanner is an HP Scanjet 3970 (manual, USB connected) but the answer need not be specific for this particular type, any general explanation on policies of similar flatbed scenners is welcome.

Basically, no, flatbed scanners don't remember old scans.

A flatbed scanner sees a lot of incoming data (the pixels) and outputs them all on whatever communication medium it has (say, USB). RAM is used as a buffer between the two. Cheap scanners don't have a lot of RAM, much less than enough to contain one scan, and rely on the host computer to be able to read the data fast enough (or to stall the scanning in case of overflow, although this would be likely to induce picture distortion).

Network scanner usually have more RAM, because they may need to contend with network congestion, so they must be able to buffer one full picture. Some may buffer several pictures, in particular automatic scanners coupled with a printer (so that you may efficiently copy a bunch of sheets). None of them, though, has any business storing files permanently so it would make little sense for them to use anything else than RAM. Correspondingly, after a few minutes without power, the data is gone for good.

Some advanced scanners who act as file servers (so that network machine may obtain scan results afterwards) could store data permanently, and require special procedures. I really doubt your scanner would be of that kind, though. It would not be reasonable in terms of economics.


Visiting HTTPS pages over VPN = double encryption? Are packets "double encrypted" when I visit a HTTPS page while connected via a VPN?

Yes, from your computer to the VPN exit node the communication will be "double encrypted". Then, from the VPN exit node to the destination it will only be encrypted by HTTPS.

So why is this important - isn't one layer of encryption in HTTPS enough on its own? It is impotant to remember that HTTPS does not encrypt everything - the domains you visit are still in plain text by necessity, and so is your DNS traffic. A good VPN takes care of that by encrypting everything. As a result the already encrypted part of the HTTPS traffic gets encrypted again.

(And if you would send an encrypted file over HTTPS through a VPN it would be tripple encrypted.)


How can I verifiably demonstrate that steganography or hidden partitions do not exist? I want to verifiably demonstrate that there are no hidden partitions, or hidden messages in a given message.

In this scenario, assume the subject is being monitored (consensually) and agrees to align with whatever audits or restrictions need to be in place.  OR the receiver agrees to have messages filtered as to reduce the chance such a message is being received.

Edit: I want to highlight the fact that I'm looking for ways to reduce the statistical probability that a subversive message exists... since the premise of steganography uses statistics to identify these covert messages.  Basically, I'm just trying to help them along but implementing anti-stenographic techniques.

Question

How can I normalize media in such a way as to reduce the chance a hidden message is contained therein?

Examples

In the case of a TrueCrypt hidden partition, I am thinking that I can show that all unallocated (or unused space) is set to either 1 or 0, however that verification process would be time consuming.
In the case of steganography, I can normalize images, to a simple format of my choosing which would add noise or eliminate any message if present.
Finally in the case of written text, I can perform substitutions (Thesaurus) or grammar replacements as needed (Yoda-fi the text for lack of a direct example)
Delay the time that a message is sent, or only release messages at a fixed time

Your question here is basically the question every steganalysts are asking. Reading from wikipedia page:

  The goal of steganalysis is to identify suspected packages, determine whether or not they have a payload encoded into them, and, if possible, recover that payload.

The usual way to go is to have a set of known not-steganographed data to extrapolate statistical data. Then you try to devise the characteristics of what is empty containers and run the statistical analysis on the set of all files. If the file does not match the statistical class, you are likely to have found a media with steganographed data in there.

The statistical elements will be different for each media types and there is no definite answer as "this file contains hidden data", it's always a probability unless you have the tool to decode it.

Your next question, normalising, is just a new rule. If you code all images in JPEG, the steganographer just need to find a algorithm that is resistant to JPEG (re)compression.


How one can find I am using virtual box Virtual Machine linux through Anydesk remote application? I recently created a virtualbox virtual machine of Ubuntu 18.04 and installed Anydesk remote desktop app in it. An IT guy accessed my computers desktop via Anydesk app, but he is actually inside the Ubuntu Virtual Machine on Virtualbox. I don't even mentioned anything about Virtualbox, but after asking me my laptop model and brand, in less than one minute he asked me "Are you using Virtualbox VM?". I startled, he even mentioned which virtualization software I am using( virtual box) even there is VMWARE, Parallel, Nutanix and manymore. My host machine is Linux Mint. Can anyone explain how our IT guy managed to know that I am running Ubuntu 18.04 inside virtualbox as a Virtual Machine.

One way to determine that is

  ifconfig

The default Mac addresses map to the VM vendors.


Ftp constantly asked for a .exe file, what can i do? I rent a web server ("service") at a web hosting site which recently i assume got hacked but i am unsure how... I know it got hacked because recently out of the blue certain files and folder appeared on the FTP-server. I deleted all the files and changed the password on everything in relation with this server... a couple of days later files appeared again so i deleted them and they haven't appeared yet, now there is still one more thing that is anoying me if i look at the ".com" file (which stores request's to the website) it grows to like 50 000 request's a day :( ! Whats more all the request are from a ip-address traced to like Argentina, and they are asking for one of the removed .exe files... as far as i understand they are getting back the 404 file.

A example row from the .com file:
"Requestor IP" - - [02/Aug/2012:19:24:32 +0200] "GET /onlySMT.exe HTTP/1.1" 404 3612 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB7.3; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; BRI/2)"

Now there are 50 009 rows like this in the log file... What can i do to stop this?

btw the passwords i use are random 12 character length with English alphabet, small and large letters and numbers.

Thank you in advance for any answers which are all very appreciated

WBR

That's the kind of behavior a botnet displays. What you can assume from the re-appearance of deleted files is that your server has been 'back-doored'.

Changing passwords will not help. A total wipe and rebuild of the server is in order. Because you are 'renting' the service, you will need to shut it down and get a new IP and a new environment on the server.


AWS S3 and 2-factor (multifactor) I have a client looking to use AWS S3 buckets for file transfer to other clients.  That data may have some sort of protected data in it.

I'd like to set up S3 to use 2-factor or MFA for the login/connection.

I've looked at a bunch of AWS docs, and have found how to use MFA to keep S3 data from being deleted... I've found how to protect the AWS account itself with MFA, but that is not for clients accessing S3.

I see that S3 uses an access ID which is a long and complex random string, and a private key, which is longer.

Questions
1.  Can I set up S3 to use some kind of 2 factor authentication?
2.  Does the Access ID count for 2 factor since it is random and not tied to a person's name or anything else?

Any other thoughts?

MFA is not designed to prevent any file deletion or change. It's only goal is to make stealing user's credentials much more difficult.

Also, you don't setup MFA for S3 bucket (or object), you setup it for a user. Permissions to that user are specified by ACL's and policies.

So in a way you can "enable MFA for S3". Create users, enable MFA, assign policies. But signed URLs are more suitable for your client's needs.


Msfvenom encode with no payload is it possible to just encode an elf executable using the encoders and still end up with a working 'packed' executable? or am i misunderstanding what an encoder is supposed to do.

No, because the msfvenom encoder can only encode shellcode. Encoding an PE would be different because it requires a stub (decrypter) and loader. A crypter or packer is what you're looking for.

For a more detailed description of how crypters work: https://www.exploit-db.com/docs/18849.pdf


Is this strategy end 2 end encryption and secure? I'm passing sensitive financial data to a payment processor online via cloud functions and would like your expert opinions, please.

The workflow is as follows:

A customer indicates they want to transact by tapping a checkout button.
The checkout button hits an API on the server which generates public and private keys. Both keys are sent to a secured database, keyed by the public key. Only the server has permissions to read and write to the database. The server responds to the client with the public key so the customer can asymmetrically encrypt their data.
The customer enters their sensitive bits into the client on ssl/tls, which encrypts the data with the public key and then sends the data and public key back to the server.
The server fetches the private key from the database using the public key, decrypts the customers sensitive data, deletes both keys from the database, tokenizes the decrypted data, and finally submits the tokenized data to the transactional processor. The client is updated with a callback for the transaction state or error.

Is this a secure procedure? What weak points can I address? What is the technical term for this strategy?

On first inspection, I don't see anything egregiously wrong with your scheme, however I question why it's necessary and whether it's actually adding any value.

To summarize @schroeder and @Nat's comments: you are spending a lot of effort to essentially re-invent TLS session encryption from the ground up, and then wrap it inside an existing TLS (HTTPS) session. This seems a little pointless. From the way I read your question, your goal is to have secure data transmission from the user to your server. That's exactly what TLS (HTTPS) was invented for!

If your reason for inventing this scheme is that you don't trust user data to be flowing unencrypted between your TLS endpoint (front-end load-balancer?) and your database, then perhaps your effort would be better spent segregating and hardening your production network.

The usual "Don't Roll Your Own" warnings apply.


What is the worse that could happen if a government wanted to interfere with a CA? In our time of SOPA, PIPA and ACTA, I was wondering what could happen if a government wanted to remove the certificate of a website ?

CA are companies, so they would have to obey to instructions from their government. What could happen if they wanted to remove a certificate issued by a CA ? What would be the impact on HTTPS and S/MIME ?

Could they ask to create a bogus certificate that would not properly secure the communication ?

Could they impersonate someone else with a bogus S/MIME certificate ?

For the government to gain effective control over SSL certificates used within its borders, it would first have to establish much stricter control over Internet traffic than most governments currently have.  The Great Firewall of China comes to mind here.  It's not impossible, but relatively few governments are currently doing it.  The reason I say this is necessary, is because no single government can have control over all the CAs in the world.  So, they would have to first implement measures that would allow them to restrict SSL access to only websites that use CAs that are under their control.

That being said, what might a government do if they could gain coercive control over a CA?  The primary risk would be traffic sniffing.  If the government could get the CA to issue them valid certificates for high-profile websites, then they could (via border proxy or other means) set up a man-in-the-middle attack to read whatever data private citizens are exchanging with that site.

Could they get the CA to revoke site certificates?  Perhaps they could, but the key here is that certificate trust is at the user's option.  Even in the case of expired or revoked certificates, users generally still have the option to let their browser or other programs trust the certificate and conduct business as usual.  Then, we eventually work our way back to Problem 1 - controlling what sites the users can access outright.


JSON through <script src=, how do you get the JS object in the rogue page? I was explaining the attack on a JSON REST API the other day (in real life, at work, not here), and I figured out that I do not understand part of the attack vector.

Sorry if this is quite a basic question, I'm not great with JavaScript.

A common way that this attack happens is that you have an API at, say http://myfavouritebank.com/api/account/ that returns the following on a GET request:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{ "customer name": "Bob",
  "account number": 123,
  "balance" : 123.56
}

This will be returned when the user is logged in (say, using a cookie based auth).  When the user is not logged in it simply returns 403.

Then, a rouge page, contains:

<script src="http://myfavouritebank.com/api/account/" />

And the rogue page will load the JSON object (given that the user is currently logged in the bank's website).

But the question is

How does the rogue page actually makes use of that object?  It is just an orphan object inside the script environment, how can it be assigned to a variable for example?

In other words, I figured out that I never understood how this attack unfolds from here.

There are several great answers on how to prevent CSRF on a REAST API that explain sending the data as JSON.  I am trying to understand how the rogue page is constructed to retrieve the data from such a JSON, with this information I can better explain the attack.

See this question for more detail, but in short, tampering with the prototypes of Object and Array can let you read out the contents of any object as it's created. So an attacker doctors the prototypes, document.write's the script tag, and even though the JSON object is not saved, the attacker's instrumentation gets notified as each property is set and can make a copy.


GnuPG + Yubikey: Can a trojan extract any secret key or sensitive information? When using GnuPG with a Yubikey 4 on a Laptop for e-mail communication: Can a trojan extract any secret key or sensitive information?

If so, what information would that be?

You could wrap up the rest of the answer with "The YubiKeys implements the cryptographic smart card protocol using a programmable microcontroller". So what does this imply?
Cryptographic Smart Cards
The idea behind cryptographic smart cards is that they're equipped with their own crypto processor, and are able to perform several operations:

create keys for public/private key cryptography
alternatively load such keys
sign documents (hashes) using these keys
encryption session keys for symmetric encryption

An operation not supported is extracting keys, the idea of OpenPGP smart cards is limiting impact on breaches to the time the card/key is connected to the machine. This also means that if you want a backup copy, you'd have to create the key on a computer and then load it to the smart card/YubiKey.
All this is explained in Yubico's blog entry YubiKey NEO and OpenPGP:

WARNING: You cannot backup the secret keys – so if you lose the YubiKey NEO, re-generate another key pair or other lose the key pair there is no way to retrieve it! When you encrypt a file, make sure you have a plain text backup.

Sensible Information Beyond Private Keys
You can (but do not have to) store some personal information on OpenPGP smart cards, also the vendor could do so (for example, the FSFE signs the key's original contents with their own key, including some personal information they pre-programmed). I'm not sure whether the YubiKey implements the whole OpenPGP smart card standard and I don't have my YubiKey with me right now, but I'd guess it does. Information that is always stored are the serial number and as soon as keys are created their fingerprints and creation dates. There is a signature counter that might indicate key/card usage. Furthermore, you can (but do not have to) set the card holder's name, language, sex, public key's URI and some login data.
Programmable Microcontrollers
The YubiKey actually is a full computer, and all the smart card operations are implemented in software. There might be bugs and other issues, and you cannot really verify the software, on non-development products you cannot even install your own software (which of course also applies to hardware tokens, which also could include bugs and backdoors, where you also need to trust the vendor, but software is usually more complex, less well understood and more likely to have issues).
The YubiKey (Neo) was already affected by an issue, allowing to perform crypto operations without knowledge of the user's PIN. Extracting keys was not possible because of this issue.
A very sophisticated attacker might even be able to crack open the device and read the stored information (which also applies to "dedicated" smart cards for OpenPGP and other protocols, of course).
An alternative claiming to be open source hardware and software (which would in theory enable verification, while producing your own device is probably out of scope) is the Nitrokey. I'm not sure though how to verify the software running on the device and whether you could exchange the whole software with the self-compiled (and assessed?) source code, at least you should be able to do so for the individual applications (like OpenPGP).


How are sites like PersonalCapital safe/trustworthy? Sites like PersonalCapital require you submit your account login details for every one of your banking account providers.

Could personal capital potentially log into your financial accounts and make changes? What if personal capital is hacked?

These sites don't really seem safe to me, since they ask for financial account passwords, and could do whatever they wanted with this data.

Who, besides the owner of the sites, says they are secure?

One big problem is that they must store your password in a recoverable manner. This is contrary to best practice. No matter what the site does, there must be some way to get the clear-text password. This is definitely a risk.

While IANAL, I know that banks' user agreements typically require you to keep your password secure and hold you liable for damages if, for example, you give your username and password to a third party. This is different from, say bank account numbers. Those are not intended to be secret and you are not liable if they are misused, provided you didn't actually partake in their misuse.

The sites are, of course, likely to be targets of attackers due to their high value.


User password as key instead of hashing it I was reading here on Hashes and Salts and I thought about another method to do user authentication. I need your thoughts on this as I might be overlooking something.

Scenario:

For web application authentication, the general trend is to hash the password appending a random salt, with a strong hash function. The random salt and generated hash gets stored in database. Later, when the user wants to authenticate, the user entered password is hashed again with the stored salt and the generated hash is compared with previously stored hash.

Now about my method:

We store one master secret text (as long as it needs to be) in our database and we use unique salt per user.
Instead of storing password hash, we symmetrically encrypt (hash(master secret + salt)) using user password as key and store this encrypted value in our database.
When user wants to authenticate, this previously stored encrypted value will be decrypted  using user password as a key and we will get a hash(master secret + salt).
This decrypted hash will be compared with newly calculated hash(master secret + salt)
If user enters a wrong password, the decryption will fail and we will get a wrong hash which will fail to compare against hash(master secret + salt)

In this way we are not storing user password in database in any form (plain text, hash, encrypted).
I want to know how this  method compares against our usual method of password hashing.

You do store the "hashed" password. To be precise, you store some data on the server:

A value S (the "salt").
The "master secret" M (which cannot be really secret, since the server stores it "as is" somewhere in its entrails).
E(h(M||S),K): encryption of the hash of the concatenation of M and S, using key K which is derived more or less directly from the user password.

Given these data elements and a potential password P, it is possible to do some computations which result in a boolean result: P is the correct password, or not. That's normal: the server must be able to verify an incoming password, using what the server "knows" only. But if the server can do it, an attacker who got a copy of the server data can do it too. That's unescapable. The stored data elements cannot be directly used to recompute the password, only to verify a given password, so that's one-way.

This is called password hashing. That there is a so-called "master secret" and that an encryption function is internally used are just red herrings; you are simply making a custom password hashing function.

There can be some value in the "master secret" if you actually manage to keep it "secret". The server must know it in order to operate, so it is not really hidden, but you can arrange for it not to be stored in the database, keeping it out of reach of usual SQL injection attacks. It won't do anything against an attacker who obtained a root shell on your server, though.

Using such a "secret" in a password hashing function is called "peppering" and the normal, cryptographer-approved way of doing it is to make the password hashing function a MAC with the "secret" as key.

See this long answer for a primer on password hashing, its concepts, tools and terminology.


EICAR alternative for IDS/IPS Is there a way to trigger alarms in an Intrusion Detection System with something similar to the EICAR test virus? Maybe some special packet that is harmless to the environement, but will trigger IDS?

I am asking this in the context of a SE rogue device dropping senario, where the device trys different tunneling protocols to get out of the network. If a tunnel is established it would send this test packet to give the security infrastructre another chance to block the connection.

The world is your oyster with this one. If you simply need to create one alert use a packet crafting tool like scapy. Testing a rule like this in snort is easy, however, this can work for all types of rules.

alert tcp any any -> any 80 (content:"GET";)

From here, just fire up scapy and at the console type:

send(IP(src="X.X.X.X",dst="X.X.X.X")/TCP(dport=80)/"GET")

Remember you would need to add the appropriate IP addresses to ensure the packet passes by your sensor. The complexity of the rule you want to test(trigger) is only limited by your skill in scapy which is super easy to learn.


SSH: benefits of using hashed known_hosts What are the benefits of storing known_hosts in a hashed form? From what I read, it is supposed to protect the list of servers I am connecting to, presumably in a scenario where my account has been compromised (and known_hosts file stolen)

If my account were indeed to be compromised, having known_hosts hashed would be very little consolation. An attacker could see from my bash history to which servers I am connecting. And also from my .ssh/config where all my servers are listed.

Are there any benefits that I am missing in my description here?

I don't think you are missing much.  The only change is that if a machine is compromised, the idea is to minimize how much usable information is given to an attacker.  In the known_hosts file, more information is not necessary to include (computing a few hundred HMACs is not onerous work), unlike in ~/.ssh/config where it needs to be included on the Address line if you wish to connect via your alias (hashing wouldn't work) and in your command line history - if you choose to keep one.

Presumably you could have a very large known_hosts (e.g., if you sync it with another computer when you setup the account), but say not use .ssh/config and not keep a command line history or have never connected to most machines in the commandline history.

In those situations, hashing the IP addresses used in your known_hosts could lessen exposure in the event of a compromise.

Furthermore, HashKnownHosts is a configurable option, and the default is to not hash (probably for reasons you specified -- it doesn't help much).  See man ssh_config:

  HashKnownHosts

  Indicates that ssh(1) should hash host names and addresses when they are added to ~/.ssh/known_hosts.
  These hashed names may be used normally by ssh(1) and sshd(8), but they do not reveal identifying information should the file's contents be disclosed.  The default is “no”.  Note that existing names and addresses in known hosts files will not be converted automatically, but may be manually hashed using ssh-keygen(1).  Use of this option may break facilities such as tab-completion that rely on being able to read unhashed host names from ~/.ssh/known_hosts.

Note the format of a hashed known_hosts line (example taken from here - my current configuration is not to hash) for an entry for 192.168.1.61:

|1|F1E1KeoE/eEWhi10WpGv4OdiO6Y=|3988QV0VE8wmZL7suNrYQLITLCg= ssh-rsa ...

where the first part F1E1KeoE/eEWhi10WpGv4OdiO6Y= is a random salt - that acts as a key for the HMAC-SHA1 to hash 192.168.1.61.

You can verify in the command line with (BSD / Mac OS X):

#### key=`echo F1E1KeoE/eEWhi10WpGv4OdiO6Y= | base64 -D | xxd -p`
#### echo -n "192.168.1.61" | openssl sha1 -mac HMAC -macopt hexkey:$key|awk '{print $2}' | xxd -r -p|base64
3988QV0VE8wmZL7suNrYQLITLCg=

or on GNU/linux with:

#### key=`echo F1E1KeoE/eEWhi10WpGv4OdiO6Y= | base64 -d | xxd -p`
#### echo -n "192.168.1.61" | openssl sha1 -mac HMAC -macopt hexkey:$key|awk '{print $2}' | xxd -r -p|base64
3988QV0VE8wmZL7suNrYQLITLCg=

where we just decoded the salt and used it as a key in a sha1 HMAC, and then re-encode the hash in base64.  Just specifying as another answer originally presumed that the HMAC may have used the user's private ssh key to compute hash-based message authentication code, but this is not the case.


Privacy within the new U.K. laws for ISP's The new UK law means that Internet service providers have to keep emails, web history, and your searches for one year.

I am not very comfortable with this. I have nothing really to hide, except for normal personal details, but with all the data breaches recently I would like to protect my identity from being used or stolen.

If I use a VPN, like OpenVPN, and have my exit point as Switzerland, will this stop my ISP from logging my activities like banking? I don't use my ISP's mail. I use a Swiss mail server.

If this doesn't do the job and needs to be tweaked, could someone please let me know what I should be doing?

If I use a VPN, like OpenVPN, and have my exit point as Switzerland, will this stop my ISP from logging my activities like banking?

The answer to your question is a qualified yes.

Here are a few gotchas:

You must make sure that the VPN is actually a VPN and not just a HTTP proxy. E.g you must make sure that a) your connection to the VPN provider is encrypted and b) all the requests your computer makes are tunneled to your VPN provider. If you just use an HTTP proxy, for example, all your DNS requests will most likely still be visible to your ISP, so while the ISP wouldn't know what exactly you send and receive, they'd know with whom you communicate.
You must trust the VPN provider. Your VPN provider is pretty much in a position to serve as a man in the middle for all the unencrypted connections you make to the internet (e.g. HTTP websurfing, and possibly checking and sending your E-Mail if you use IMAP and SMTP without TLS). Even with encrypted connections, your VPN provider can compile a complete list of all the internet servers you communicate with, when you do so, and how much data you exchange. In fact, the VPN provider can do everything the ISP could if you didn't have the VPN installed. So you're just moving your trust from your ISP to a third party.
Protecting your identity from being used or stolen has very little to do with using a VPN. VPNs only make the content of your internet communications illegible to anyone sitting between you and the VPN provider. They don't do anything to secure either your computer or the services you communicate with. Data breaches usually don't happen at your ISP but at the services you use, and VPNs don't add any additional privacy for you from the viewpoint of things like mail services that know you anyway (because you have an account with them). Once you sign in, it doesn't matter whether they know your real IP address or not - they know it's you. And thieves/hackers who breach a service usually aren't interested in stealing IP addresses of clients (the only thing a VPN can hide from your communication endpoints)

If you see point 2 as a problem, I'd suggest looking into other privacy tools such as Tor.


Is there an easy way to secure Apache on debian? I run an Apache webserver with lots of PHP-sites of several customers.

I tried install apache-mod_security2 after this (german) tutorial
that is using these rulesets: http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz

but if I enable that, nearly all pages have lots of warnings.

I know, it would be best, to adapt all sites, so no warnings are thrown anymore, but that is just too much work for one admin, so I would like to pull those rules down to only the obvious critical Attacks.

I know your pain; unfortunately, there really is not much you can do if you're using the core rule set.

You will need to whitelist rules using SecRuleRemoveById. This can obviously get cumbersome. So, what we do in our infrastructure is note what rules are whitelisted for what CMS and whitelist all those rules based on the CMS' that are being ran on the server.

I've been told that TrustWave has specific rules that apply to specific CMS'.


Setup a Proxy with a Cordova / Ionic Android App (aka Open Source version of PhoneGap ) We're doing a security assessment on a Cordova / Ionic Mobile Application (APK & IPA). Even though we've imported our proxies Certificate Authority to the device and we can intercept SSL in the default web browser without certificate errors, the application is erroring out whenever we have a proxy configured on the device and an HTTPS call is being made.

The development team is telling us they don't have any certificate pinning or other protections in place besides what is on by default in the framework.

Has anyone bypassed this before with an Ionic application and can give some tips? I'm focusing on the Android build first and the traditional overriding of the SSL error to cause it to continue by modifying the Dalvik byte code is not being successful for me.

Searching through the artifacts I'm not seeing a custom CA authority list in anything, nor a hash of a certificate etc; as a result I really don't understand why this isn't working.

Any information you can give me which helps to be able to proxy the application would greatly be appreciated.

I figured this out. It turned out that the issue was with Android Nugat and there actually was nothing wrong / built in to prevent the interception. Switching to JellyBean resolved the issue and allow the interception to happen.


How key management happens in both OpenSSL and aescrypt and how the key is stored after encryption? I am using OpenSSL and aescrypt for encryption and decryption so how key management happens in both OpenSSL,aescrypt and how to save key after encryption?
For example I giving a sample code

openssl aes-256-cbc -a -salt -in abc.txt -out abc.txt.enc

aescrypt -e -p apples abc.txt

If you try running the openssl command-line, you will see that it will ask for an "encryption password". That password is the key; there is no key stored anywhere else.

Looking at OpenSSL's source code (I am here looking at OpenSSL-1.0.2g, file is apps/enc.c), it appears that the password is used, along with a random salt, into the EVP_BytesToKey() function: that function generates the encryption key (and the IV) from the salt and the password, with a complicated hash-based function. The iteration count is hardcoded to 1 (which, as far as password hashing is concerned, is terrible). The output file (not counting the Base64 encoding added with the -a option) starts with a sequence of eight fixed bytes (53 61 6c 74 65 64 5f 5f) followed by the salt itself (8 bytes), then the encrypted data. Thus, the salt which was generated randomly is encoded in the file itself, but the password is not stored anywhere else than the brain of the user.

I am not aware of a standard tool called "aescrypt". Google searches show several tools with that name, so I cannot know which one you have on your machine. I bet, though, that the general principle is the same: the tool asks for a password, and derives the encryption key from that password.


Do blackbox penetration tests make sense if a whitebox audit would be possible as well? Lets assume I am responsible for an application in my company and I decide to hire security experts to perform a security audit. Lets assume further that my company owns the source code of the application and I am allowed to hand it over to the hired experts.

Are there any good reasons to prefer a blackbox penetration test over a security source code review? In my opinion a source code audit identifies critical vulnerabilities much faster and more efficient than a blackbox penetration test. Why should I let a security expert hammer at my application in the dark, when i can provide him with internal informations like system configuration and the source code to help him directing his efforts better.

To avoid confusion - when I talk about a security source code review, I assume that I will allow the security experts to perform tests on the application as well, to validate their findings and try different attacks. The goal of the audit is to identify weaknesses and improve the security of the application afterwards.

Source code review is generally more effective than black-box pentesting.  @Demento, you articulated the reasons why well.  And, apart from these first-principle justifications, empirically source code review finds more vulnerabilities than black-box pentesting.  This is especially true if source code review is combined with architectural risk analysis (what Microsoft calls threat modelling).

The big advantage of black-box pentesting is that it is considerably less expensive and requires less expertise.  This is one reason why you see so many people use black-box pentesting: it is a lot cheaper, and still catches a significant fraction of vulnerabilities.

Personally, I recommend that if you use source code review, you should also combine it with black-box pentesting.  Black-box pentesting will cost only a fraction of the cost of the source code review.  And empirical data suggests that black-box pentesting + source code review find more bugs than either alone finds.  Therefore, the marginal utility of black-box pentesting is probably worth it, even if you are already doing source code review.


Can a company see where you've taken their mobile hot spot? Can a company track where you've taken their company hot spot?

I would assume they would be able to as long as the hotspot is on, they could call their provider of the hotspot and get them to trace it.


How to check if your Android app was updated by MitM? As I was browsing on my phone yesterday, a gray popup appeared on my screen just as I was swiping up, and I accidentally hit the accept button. In the fraction of a second it was on I was able to read something like Are you sure you want to allow <large block of code filling my screen>.

Immediately, the Redphone and Signal apps (both apps are for secure communication) started updating.

As a precaution, I restarted, uninstalled them, then reinstalled them from the Play store. After a while, they automatically "updated" again. This could be a coincidence, but it smells fishy to me.

Is there any way to verify the hash an app on Android? Could I have approved some adversary’s certificate or something? I run Cyanogenmod, if that matters.

I'm an activist and regularly attend protests but I never do anything exciting, so as far as threat models go I have no reason to believe anyone would give a hoot about my conversations. So it's probably nothing, but I'd like to have the peace of mind.

I'm sorry if this is answered already. I searched unsuccessfully, but it may be that I don't know the correct keywords to use.

Since your apps were downloaded from Play Store, you can check their latest update date by simply visiting their store page:

From Play Store app: tap 'Read More' on app's description, scroll to the bottom and look for 'Updated on'
From browser: look for 'Additional Information' on the bottom, there's 'Updated' date.

For your case, both RedPhone and Signal are developed by same developer and updated on November 2 (as of current writing). I think it's really a coincidence, since I observe that Play Store's update timing is arbitrarily random.

If you're still unsure, you can check the APK file's hash by submitting the file on Virus Total. You need root access to locate the APK (the path will look like /data/app/<package name>/base.apk. The package name can be found on Play Store link). Also, you need to ask the correct hash from the developer for confirmation.

Additional note: Even if it was a case of MitM, Android app can only be updated if it uses the same certificate to sign the app. Failing that will result in failed update (with error message "Application not installed. An existing package by the same name with a conflicting signature is already installed.", or INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES on ADB). This won't happen, unless the attacker is the developer (possible, but unlikely for reputable developer), or the attacker has the certificate (unlikely, and a critical issue for developer).


Is taking social networking details legitimate for a credit card? Recently, I applied for a credit card(from a bank based in India), After I completed my online application, I received an SMS(from a number which usually sends me my transaction details), which had a link to verifi.me. I clicked on the link and then it asked me for access to my email account(Gmail or Outlook or Yahoo). When I checked the permissions, it was asking for almost every possible permission(except the password, of course).

After I provided the access, it went on to ask me to log in to my LinkedIn account, asking me for a full set of permissions. After this, it asked me for my Facebook account access with all sorts of read access(thankfully, it didn't ask for permissions to post).

I have never seen this before. So, my question is:

Is this a standard procedure(taking all social media details for checking the credibility), while applying for a credit card? If it helps, the website was verifi.me, and it was a secured site.

I Googled about this website, but couldn't find much apart from the official page of the website.

Normal? No, not right now. But, we are going to see far more of this level of personal verification in the near future.

One of the difficult things for any company (or government) to do is to verify the 'identity' of a person online. It is an exceedingly complex problem with no clear solution. National identity cards (or government-backed official online profiles for people) are being considered, but there are huge privacy concerns. The approach taken by verifi.me is a compromise.

The one thing that is very, very difficult to fake or counterfeit is one's online life. There is so much detail being generated in normal use, that a fake profile will be evident. So, companies like verifi.me request access to your email and social media life to run an analysis. They then sign off that 1) you are a real person, and 2) that the details you provided in your bank application are likely true.

Creepy? Oh, yes. Privacy invading? Absolutely! But it is also a very real, and very effective means of verifying a person. It solves a very real problem in the world today.

Would I let a service like that crawl all over my personal details and private communications? Absolutely not. In fact, knowing that this type of thing is coming, I'm considering a process where I have a shadow set of online profiles where I programmatically send less sensitive copies of my real communications so that it is a subset of my online life. That way, services like this (and governments) have real data to go over, just not all of it. But, that's another topic.


What happens if my public key on server is changed by someone else? Lets say an attacker gains sudo access to a server holding business critical information. He then changes the public key associated with user Bob to his own public key. He removes all evidence of this action using sudo access and then logs in as Bob with his private key. Now logged in as Bob he does some nasty stuff and this can get Bob in trouble.

Are there any safeguards against this kind of behavior?

Are there any safeguards against this kind of behavior?

Other than protecting the server as much as possible? No. And it's not even necessary to change keys or whatever. Root can do everything, even mimicking Bob without key change.

Fail2ban, Snort, SeLinux, etc.etc. ... use them appropriately.

...

For root logins, ie. not some bug which allows to do some specific thing, and not necessarily by someone outside of the company ... if you're very concerned about malicious IT staff etc., some sort of "peer review" system could help (and cameras, steel doors, no USB ports, no screws, self-destroying hardware (yes) ... well, you have to know how trustworthy your colleagues are).

Every machine reports root logins to another independent machine (before the person logging in can prevent it; and if the reporting fails the login fails). And every access has to be approved and overseen by a second employee. A logged access without two signatures on the form means there is a breach, everything since then is not reliable anymore.


How to use Aircrack-ng when knowing part of the password? Let's say I know the password starts with "1234" and after that there is a commonly used password. I would like to use the word list I have for the second part of the password, but to include somehow the "1234" before every password of the word list while cracking.
It would be extremely time consuming to write a program that makes a new word list out of the normal one with the "1234" in front of every pass and run it on some big word list.

I guess there should be a command that can help me with that, if not, I guess I should start coding.

PS: I need it for educational purposes.

This should do it! It will append 1234 beginning of each line in your wordlist.

sed 's/^/1234/' wordlist.txt > newWordList.txt


UDP flood from my machine, or false positive? The company that hosts my dedicated server has alerted me to what they think is malicious traffic coming from my machine. They supplied me with graphs showing a large amount of UDP traffic coming from the IP address of my machine and another machine on their network, both directed at an address that seems to be a Russian webhost. The traffic lasted about 15 minutes, was about 80 Mbps, and occurred on a day when I was out of town and not logged in to the server or doing anything special with it. My machine is running debian. My webhost says they "removed the null route and it seems to not start again." (I don't know what that means.) I ran a rootkit detector called rkhunter and it didn't turn up anything.

I don't have any advanced knowledge of security, so it's hard for me to evaluate whether this is strong evidence that my machine has been compromised. I noticed the following in this answer:

  Are you sure your server is the source of the packets? It's easy to forge the source address for UDP packets.

Is the information from my webhost strong evidence that my machine has been compromised and that I need to have them do a reinstall?

[EDIT] I later found out that this was probably because the portmapper service is vulnerable to something called a portmapper amplification attack, which uses UDP. Since I'm not using NFS, I can just turn this service off.

You got the report from your hosting provider. They would be able to tell whether the traffic originated from your server or if it was spoofed. So if your hosting provider is competent, then the report is most likely correct.

If I was in your shoes, there are two things I would do. I would ask the hosting provider if they can send a packet capture of some samples of the flood traffic. After inspecting the packet trace one will be in a much better position to judge the correctness of the report. Additionally I would log in on the server and run ifconfig to see how much traffic has been send by the machine since it was last rebooted. (Notice that if it is a 32 bit system, the counter wraps around at 4GB and thus is not guaranteed to be accurate.)

If your host did send a flood of UDP packets, there are different ways it could have happened. But the most likely explanation is some sort of compromise. Compromising the root account is not required to start a flood of UDP packets, compromising any single account would do. You can look if a socket is still bound to the source port of the flood traffic. If you are lucky you might find the program originating the traffic that way. I have on a few occasions seen a legitimate program accidentally produce a flood of packets without any compromise having happened. If you have any internally developed software communicating over UDP, this may be what happened to you.

Should it turn out that the provider doesn't have a packet trace to show you, and the byte count on the network interface doesn't indicate a lot of data has been send, and you can find no evidence of a compromise of the system, then it may be that the provider has simply forwarded a false report they received without performing their own investigation.


Why does SSLStrip work on some https sites and not others? I recently tested MITM on my LAN through SSLStrip, but I noticed that on Gmail and Fb doesn't work, while on other sites I can sniff connections easily. What is the difference?

Those sites (and some more) use public key pinning with HSTS, whereas the browser does not accept other certificates or a downgrade to http.


What's the security risk of using a protocol-relative URL in a CSS stylesheet? I used SonarQube to perform a static code analysis of my project and it detected a security vulnerability in one of my CSS files:

For security reasons, protocol-relative URLs should not be used.
Noncompliant Code Example
@font-face {
    src: url("//myfont");
}

Compliant Solution
@font-face {
   src: url("https://myfont");
}

See

Paul Irish blog post

stylelint Related Rules

function-url-no-scheme-relative

Neither link is related to security, and I haven't been able to find an exploit abusing protocol-relative URLs.
This rule was added on September 2016.
Is there any security risk to using protocol-relative URLs in CSS stylesheets?

Your question links to a blog post by Paul Irish, which mentions that this is now considered an anti-pattern. (Since 2017)

Why was // used at all?

The reasoning was that you could write //mysite.com/some/resource and it would resolve to either http://mysite.com/some/resource or https://mysite.com/some/resource, depending on whether or not the site was called with HTTP or HTTPS.

Loading HTTP resources when your site is served over HTTPS can be problematic, as browsers usually complain about websites loading mixed content. Notably IE6 would display a big error message, asking you if you were really sure if you want to continue.

So why not redirect everything to HTTPS?

Because back in 2010, when this blog post was made, HTTPS was considered expensive. Not just because Let's Encrypt didn't offer free certificates back then, but because there used to be quite a performance difference between HTTP and HTTPS. These days, this is not the case anymore, and the overhead HTTPS causes is negligible.

What happens if I use //? Is it dangerous?

Not really, but there is also not reason to use it. The recommendation today is to use HTTPS on everything. Really, there is no excuse anymore to offer plain HTTP aside from redirecting to HTTPS. When browsers finally see HTTPS as the default, then there will be no reason for HTTP existing at all.


Should the salt of a bcrypt hashed password be stored separately I'm replacing a password storage system. The current implementation uses TripleDES with the key stored in plaintext in both the binaries and the config (in-case one of them is not available for some reason (DSTM)), the application decrypts the value from the database, and checks it against the plain-text value sent from the client.

I'm proposing replacing this with BCrypt (in this case, BCrypt.Net). I use the following code as an example

int workFactor = ((DateTime.Now.Year - 2000) / 2) + 6;
string salt = BCrypt.Net.BCrypt.GenerateSalt(workFactor);
Console.WriteLine("Salt: " + salt);
string password = "some test password";
string passwordHash = BCrypt.Net.BCrypt.HashPassword(password, salt);
Console.WriteLine("PW: " + passwordHash);
Console.WriteLine("Verify: " + BCrypt.Net.BCrypt.Verify(password, passwordHash));

One output of this may be

Salt: $2a$14$zhJH43uFxZU3FJ9FaFQusO
PW: $2a$14$zhJH43uFxZU3FJ9FaFQusOn7bJTsXZQgXpEGYFBIygd.8lGXIcc22
Verify: True

I noticed that there was no separator between the salt value and the password value, when Verify returned true when I didn't specify a salt.

If the salt is included in the hashed password output, is there any value in storing $2a$14$zhJH43uFxZU3FJ9FaFQusO and $2a$14$zhJH43uFxZU3FJ9FaFQusOn7bJTsXZQgXpEGYFBIygd.8lGXIcc22 separely?

I figure I would probably want to generate a new salt for the user the next time they select a password anyways.

No, as you have seen, the salt is part of the resulting hash value (the 22 characters after the cost factor). The BCrypt.Verify() function will extract the salt from the stored hash, so it is pointless to store it separately.

You can call the function with only one parameter, the library will then generate a salt and the cost factor on its own:

string passwordHash = BCrypt.HashPassword(password);
// or if you want to specify the cost factor
passwordHash = BCrypt.HashPassword(password, 12);


Why would a public key have a passphrase? Last week I wrote to my bank with a general question. Today I received an email inviting me to join their "Secure Email (PGP) system". It made clear I'd have to join to read their response to my question.

  You have received an encrypted email:
  From: $CST1, Mailbox
  Subject: Your pension fund enmquiry Ref CF-123456
  This is the first time you have received encrypted email from Lloyds Banking Group so you will need to set up a password (also referred to as a passphrase) to access this email and any future encrypted emails that you receive from us.
  Lloyds Banking Group takes online security very seriously.

Reluctantly, I followed the link to sign up, inventing an account password. I duly received a passworded PDF by email, with the response to my question.

Out of curiousity, I explored the rest of the site, which appears to run "Symantec Web Email Protection". On the settings page, I saw it gave a choice how the bank would encrypt messages to me; either as passworded PDF documents or with public key cryptography.

  I have an OpenPGP Key or digital ID/certificate (X.509, S/MIME) that I want to use to secure messages I exchange with site [sic].

Following to the next page:

  If you already have a key or certificate, you may upload it and we will encrypt your messages to it.

  You may upload any of the following: a PGP key (.asc), X.509 Certificate (.pem, .crt, .cer), or PKCS#12 file (.p12, .pfx).

  Optional: If your key file has an associated passphrase, please enter it.

That last line surprised me. I've used public key cryptography in OpenSSH and GPG. As I understand, private keys can have passphrases, but not public keys. The purpose of a passphrase is to protect your key on your computer; like the private key, it should be kept secret.

Why would a public key have a passphrase? What's the point of a passphrase if you share it with your correspondents?

I think they're just trying to be user-friendly, in the worst possible way. PKCS#12 files (.p12 or .pfx) are used for key pairs - both the public and private parts - and the private part will be encrypted. The bank never needs, nor should ever see, the private key! Consequently, they shouldn't even accept such files - just the .der or .cer or .pem or .crt for the X.509 certificate (which only contains the public key) to use S/MIME, or the .asc or sometimes .pub PGP public key (of course, a .asc file can contain anything, but we'll hope the user wasn't stupid enough to export their private key) - and definitely shouldn't ask for a passphrase.

Anything that the bank needs a passphrase for, that means the user uploaded the wrong file. Public keys do not have, and do not need, passphrases. That's presumably why the field is optional - anybody using the form correctly will not have a passphrase on the file they upload, because they'll be uploading a public key (only) - but it's still absolutely abysmal design on the part of the bank.

With that said, good on them for supporting secure email at all. My bank still think that (trivially wire-tappable) fax machines and (easily-stolen) snail-mail post are the height of secure remote communications.


Is it safe to include an API key in a request's URL? Lately I've seen plenty of APIs designed like this:

curl "https://api.somewebsite.com/v1/something&key=YOUR-API-KEY"

Isn't it elementary that passing an API key in a query string as a part of the URL is not secure at least in HTTP.

Summary: capability URLs are more secure than many people give them credit for, but not suitable for all applications, and require extra care to use.

These type of URLs are commonly known as capability / secret URLs.

It's meaningless to talk about security without specifying a threat model. Here are a couple that come to mind:

1: A passive attacker on the network (eavesdroping)
2: An active attacker on the network (can change packets at will, mitm, etc)
3: A shoulder-surfer
4: An attacker with physical access to your computer / elevated privileges
5: another user of your computer (regular privileges / remote access)
6: the user itself (as in protecting a API key)

Regarding network attacks (1 and 2), secret URLs are perfectly secure, provided you're using HTTPS (it's 2016, you shouldn't be using HTTP anymore!).

While the hostname of a server is sent in plaintext over the network, the actual URL is encrypted before being sent to the server - as it's part of the GET request, which only occurs after the TLS handshake.

Regarding shoulder-surfing (3), a secret URL with enough entropy is reasonably secure against a casual attack· As an example, I'll give a google docs URL:

  https://docs.google.com/document/d/5BPuCpxGkVOxkjTG0QrS-JoaImEE-kNAi0Ma9DP1gy

Good luck remembering that while passing by a co-worker's screen!

Obviously, if your attacker has a camera and can take a picture without being noticed, it's an entirely different matter - you shouldn't use a secret URL in that situation. You can mitigate the attack by doing a HTTP redirect away from the secret URL, so it's only on screen for a few seconds

Regarding an attacker with elevated privileges on your computer (4), a secret URL is not less secure than a long password or even a client-side TLS certificate - as all of those are actually completely insecure, and there's not much you can do about that.

An attacker with regular privileges (5), on the other hand, should not be able to learn the secret URL as well, as long as you follow good security practices for your OS. Your files (particularly browser history) should not be readable by other users.

For protecting API keys (6, which was the point of this question), a secret URL is also no-less-secure than another mechanism (such as an AJAX POST). Anyone that has an use for an API key will know how to use the browser debug mode to get the key.

It's not reasonable to send someone a secret and expect them not to look at it!

Some people have asked about the risks on the server side.

It's not reasonable to treat server-side risks by threat modelling; from a user perspective, you really have to treat the server as a trusted third party, as if your adversary has internal network access on the server side, there's really nothing you can do (very much like a privileged attacker on the client's computer, i.e. threat model 4 above).

Instead of modelling attacks, I'll outline common risks of unintentional secret exposure.

The most common concern with using secret URLs on the server side is that both HTTP server and reverse proxies keep logs, and the URL is very often included.

Another possibility is that the secret URLs could be generated in a predictable way - either because of a flawed implementation, a insecure PRNG, or giving insufficient entropy when seeding it.

There are also many caveats that have to be taken into consideration when designing a site that uses secret URLs. This page by W3C TAG covers many of them.

In practice, for sites with dynamic content, it's quite hard to get everything done securely - both Google and Dropbox botched it in the past, as mentioned on this answer

Finally, secret URLs have a couple of advantages over other authentication methods:

They are extremely easy to use (just click the link, as opposed to entering your email and password)
They don't require the server / service to securely store sensitive user credentials
They are easily shareable without risks, unlike sharing you password (which you reuse for 50 other sites).


Do I still use HTTPS when I search from the URL bar in Firefox? If I go to the homepage of the search engine I use, I can see the green lock to the left of the URL bar which indicates that I use HTTPS. Then when I input a search query in the box on the homepage, I get results, still over HTTPS. But I also set it as my default search engine in Firefox, which means I can use the URL bar to search - the way it works is, of course, when the string doesn't look like a valid URL, Firefox uses the default search engine to search for the query.

My concern is that I'm not sure if I use HTTPS throughout the whole time when I search from the URL bar. The results page for the query is served with HTTPS, but when I send my query, is it also over HTTPS? In other words, I'm not already on the homepage of that search engine but I pressed enter after entering my string to search for. So is that query string send unencrypted to my search engine of choice which THEN establishes a HTTPS connection (and that would be bad because it was send over plain HTTP), or does Firefox waits with my search query, then establishes a HTTPS connection and only then sends my query over HTTPS (obviously I hope this one is true because then what I'm searching for is send encrypted the whole time)?

It depends of your Firefox's default search engine. As you can see here, Duck Duck Go has SSL addon. I guess nowadays almost all "serious" search engines like Google do searches over SSL. Not always been over SSL, in very old versions it was in plain. You can check here an article to force SSL search on Google search. The article is an old one (2012).

Anyway, you can do a Proof of Concept (PoC). Start sniffing with a Man in the Middle (MITM) to your computer which is going to do the search.... and you'll see if search is in plain or not on your Firefox's search engine addon (you didn't said which one you are using).


Security considerations in concurrent applications I have been building a network application with a Client/Server model, where a central server handles multiple client threads.

I did my best to ensure that no matter what context the program is run it won't deadlock as part of a security requirement.

My question is about deadlocks and concurrency in a networked application serving multiple threads. A deadlock is effectively a denial-of-service, but can you actually exploit a deadlock to do anything malicious? Are there security considerations, other than deadlocks, that I must make when building a concurrent application?

A deadlock, by itself, would not generally allow an attacker to affect program flow.  By definition, at a deadlock, the program stops making forward progress, so at that point, nothing is happening: desirable or undesirable.

There are many other security issues possible in multithreaded applications:

Ensure that threads are only reading/writing memory intended for them.  (This is very broad, of course, but depends so much on your application.)
If you depend on random data (such as for crypto keys) ensure that the RNGs for your threads are not at the same point.  Using the same RNGs for multiple threads may result in cryptographic weaknesses.
Race conditions are more likely to occur in multi-threaded programs.  These race conditions may result in various vulnerabilities, such as TOCTOU (time-of-check to time-of-use) issues or other types of security vulnerabilities.

There's plenty that can go wrong, and the specific issues you need to look for depends heavily on the type of application you're building.


Containerizing vs. Sandboxing vs. Layering vs. Virtualizing vs. whatever What is the right term to describe what solutions like Invincea/Bromium are offering?

Is there a difference?

Sandboxing, because you are "penning in" an application so that it doesn't trail dirt everywhere.

Virtualization often allows easier sandboxing, since the virtualized environment already offers the required behaviour for a sandbox; but in many virtualized environment it is possible for a process to recognize it's virtualized and interface with the virtualization host, and from there try to manipulate the outside environment. If a virtualization environment takes care not to let this happen, we might call it sandboxed virtualization to stress this fact.

Layering is a different concept altogether: it means that something is designed to offer (and ask) services at different abstraction levels, usually with some sort of black-boxing so that a layer doesn't know the details of what another layer does. A prime example would be TCP/IP.

And finally "containerizing" refers to the practice of bundling together several objects (for example a web server, a database server etc.) for ease of deployment. Again, one way of containerizing such would be to create a virtual environment (virtual appliance).

So all those terms are related, but their meaning is different (maybe ot always by very much).


Is it safer to store valuable information on a unsecure client or send the data through the internet? Background:

I'm creating a secure web app with the purpose to act as a no-knowledge storage for small data (we're talking a few bytes). Since all the encryption and decryption happens client-side, for the user to be able to manage their secrets, the data has to be decrypted to be searchable and so on.

The server knows an encrypted name and an encrypted value.

All of the data is once encrypted by the client, then encrypted once using a shared secret from SRP and then sent through SSL.

Solutions / concerns:

There's two ways this can be done from what I know.

A: Send both the name and value to the client and let them store it during the session. The names are decrypted and shown, whilst the values remain encrypted. Due to the unsecure nature of javascript and for UX-reasons, this would be just as secure as decrypting all the data and store it. Since the user receives all the values, there's a bigger risk of an offline attack to happen. This also makes it difficult to control that the values never exist longer then the session (for example how iOS Safari stores the webpages in an active state even when the app is off).

B: Send only the encrypted name and a token. The names are stored and shown to the user in a decrypted form. Whenever the user would like to see the decrypted value, a request is made to the server which sends it. The value is never stored on the client. This limits the risk with offline attacks - since the user will never have all the values stored at once. The worst scenario would be one value stored. The problem I see with this is that there will be a considerate increasing amount of data sent through the internet - which might be a greater risk than storing it offline.

Question clarification:

Is it safer to store the data on the user's device without being able to revoke their access to the data

or

Send valuable data many more times through the internet?

As long as the data travels inside a properly configured SSL/TLS connections, there is no security issue regarding the increase amount of data sent through the internet, the only downside would be an increased load on your server.

If you cannot trust local storage, then fetching the data from the server when it is required seems the best option from a security point of view.


Additional risks to home network in exposing (raspberry pi) honeypot to the internet While I would like to contribute piping of logs from a home-deployed honeypot to the DSHIELD project using a raspberry pi, I am concerned that the additional exposure of the port to the internet would provide:

A wider exposure surface
An additional endpoint for attackers to compromise potentially, which they could then use as a pivot point to do loop-back attack to other IOT or devices within the home network that may not have been exposed to the internet.

Would anyone be able to advise if the above additional risks are correct, and what would be a reasonable solution to place for a home network environment please?

A wider exposure surface

That is correct. In case you did not open any ports to the internet so far and you open one now the direct consequence is a wider surface.

In my point of view the indirect consequences are much worse than that. Consider, that you put a device on the internet that is meant to be attacked. And it will be. So the question is rather when than if it falls. An even though you are using e.g. the DHSIELD software wich is designed to be hacked, someone might be breaking your "sandbox" at one point.

If someone compromises a host in the internal network a pivoting will be possible if he gains enough rights on the machine. So a secure approach using honeypots is to put them in a "DMZ" that has no connection itself to the inner circle of your network.
In that way its a lot less dangerous if it gets compromised.


Is limiting/cutting password-length without notice insecure? I have encountered that our linux system cuts the length of every password to a certain length, after that length every additional character seems to be ignored.

Does this make our linux system more succeptible to a brute force dictionary attack? Also the length of a password at work isn't 100% a secret, as you will hear someone typing either shortly or quite long. Could someone with malicious intent use this to crack a long password with a dictionary attack of common words, by assuming all complicated characters are at the end?

Absolutely - and "without notice" is pretty bad here.

Your example (a construction that starts with a word and has more complicated bits at the end) is a good one.  XKCD's "correct horse battery staple" would also be reduced to just the first word, making the space trivial to brute-force.

If a security-savvy user is aware of this restriction, they could choose a different password construction, but that's a really terrible thing to ask users to do.  An security-savvy user who is unaware of this restriction could easily end up with equivalent security to your average hunter2 password.


How does checking CRLs make sites less safe? With the frantic certificate upheaval resulting from the Heartbleed fiasco [drink!], there has been lots of talk regarding certificate revocation, and in particular the policy of certificate verification through CRLs and OCSP.

One thing that's come up is the general consensus among the browser vendors that forcing verification of certificates (i.e. requiring CRL lookups to succeed) would decrease site safety rather than increasing it.

What sort of vulnerability does a hard-fail verification policy create? Why would enforcing additional security checks make us less safe?

The unique problem induced by hard-fail certificate is that it introduces an additional choke-point outside the control of the site owner but in the critical path for site function, one which typically is not particularly well-resourced.

Since all secure sites require TLS certificates, and since most certificates are issued by one of only a small number of CAs, these CAs would represent a highly attractive target for people interested in causing disruption. And furthermore, these CAs are in almost all cases particularly ill-equipped to fend off an advanced denial-of-service attack, especially as compared to the sites they protect.

As long as most people leave hard-fail CRL/OCSP verification disabled, the CAs will not be targeted because the damage of such an attack would be minimal. But if strict verification ever becomes the default in a browser, then an attack against Verisign or RapidSSL or Comodo could take out entire swaths of secure hosts, doing vast amounts of damage.

Denial-of-service attacks are often used to mask or enable a more advanced and targeted attack. But in the case examined here, the true target of such an attack may never be known. The collateral damage would be so vast that tracking down a single victim would be impossible. It would be like shutting down the power to an entire city in order to rob a single jewelry store. But if the power company is an easier target than the jewelry store, then such an attack would be plausible.

As another analogy, if verification was the default, then taking down DigiCert's or Verisign's online verification service would be a lot like taking down the entire .com DNS registry. Many companies depend on it, and protecting it is outside their realm of influence.

Right now, for example, DigiCert is the CA used by Facebook. And while Facebook has multiple datacenters scattered throughout the world, DigiCert does not. Facebook has the resources to withstand an attack larger than anything anyone has ever seen. But DigiCert does not. If hard-fail certificate verification were the default, then an attacker needn't attack Facebook to be successful, he would only need to take down DigiCert.