Google Chrome Browser - Privacy Concerns After i saw many people using Chrome i wanted to inform myself on this browser and everything concerning it as i am a Firefox user since it existed. However i am always afraid of Google being a "data kraken" collecting as much information as possible and i want to know how this privacy issues influence the browser and its usability. What data is actually sent to Google (usage statistics, system information, ...) and what of these issues can be disabled via "normal" options and via hacks? Am i too focused on this bad image Google has in my eyes or are my worries "allowed"?

The Google Chrome Wikipedia page details the different components that do usage tracking.

Features that can be entirely turned off:

clientID (unique identifier that logs usage metrics (stats and speeds, etc) and crashes)
Suggest (could share text typed into address bar to suggest the website you might be trying to find)
Page not found (could share text typed into address bar when the page isn't found)
Bug tracker (could share details about crashes or failures)
Google Updater (could share info about Chrome version)

Features that can be partially turned off:

RLZ identifier ("encoded string, according to Google, contains non-identifying information how Chrome was downloaded and its install week, and is used to measure promotional campaigns. Google provides the source code to decode this string.")

Features that cannot be turned off:

Random installation token (used to measure success rate of Google Chrome installation)

If you go to your Google Chrome preferences and turn off every feature that might "suggest" something to you or "help make Chrome better", then Chrome presents no outstanding privacy risk. Also, you have the option to log in using your Google account to sync your Chrome preferences. If privacy is an issue, choose not to do that.

If you browse using the Chrome Incognito mode, then your cookies and history will not remain on the computer you're using - even better for the privacy conscience.


In addition to using strong hash algorithms, what is a good "password requirement"? Assuming the use of bcrypt/scrypt:

Would it be a good idea to "require" a password of at least 12 characters, also mentioning the possibility of using long passphrases, instead of your typical 8-character-minimum uppercase/lowercase/special char pass requirement?

It seems like there is a tradeoff between ease of memory and how difficult something is to brute force, and not everyone uses (or wants to use) password managers.

What's the best solution in practice? I don't know what password requirements to set for my users. Having requirements that are too complex give users an incentive to make easy-to-remember passwords, whereas requirements that are too lenient give users an incentive to be lazy and make passwords that are weak to brute force.

Stanford University a month or so ago came out with a sort of sliding scale. It allowed complexity to decrease as length increases. This is basically just a probability function. An 8-character password needs high complexity, while a 20 character password needs little.

Mathematically (character set) ^ (Length)
95^8 < 52^12 < 20^26

This works great until you consider things like antidisestablishmentarianism which passes that above strength challenge swimmingly, but is in most good pentesters' password dictionaries. If you want protection from brute-forcing, come up with a target number (7 x 10^16) and an algorithm for calculating the number of possibilities and use that. Dictionary and rule-based attacks will still grab the low-hanging fruit.


.htaccess rewrite rule to hide files Let's say we have a password.txt in a webdirectory that must not be leaked. Is it secure to use a RewriteRule like this?

RewriteRule "^password.txt?*" "404.html"

I tried to do something fishy like domain.com/somefile/../password.txt, or using "password%2Etxt", and it still redirected to 404. Is there anything else I have to worry about? If it's hackable, what's the hack? My understanding of the URL specification is that this is not possible. But, I'm handwaving a bit.

Will the input to a rewriterule always be something guaranteed by the URL specification, or will they relax the requirements a bit the way css can be relaxed. If not, is the URL specification itself safe against this redirection?

I can use .htaccess to simply ban the file, but then RewriteRule "sldmfklwmefwk.txt" "password.txt" doesn't work either. I want "sldmfklwmefwk.txt" to be allowed, but "password.txt" is banned, and any other attempts to access "password.txt" being blocked without accessing it via "sldmfklwmefwk.txt".

Please try to avoid RewriteRule. It is a best practice to implement security rule from the top. In this context it is httpd.conf. I am assuming that password.txtlocated in the apache root directory.

<DirectoryMatch ./password.txt>
   Deny from all
</DirectoryMatch>

If any users access that file then s/he will get HTTP 403 - Forbidden error
You can also redirect the user to another page like 404.html. Use below to redirect user.

AliasMatch ./password.txt /404.html

Moreover, if password.txt file is not being used by HTTPD process then revoke permission HTTPD process owner's all permission from the file.


I have a custom domain for email. Do I need to configure DNS to prevent outgoing text messages with an address from my domain? I own a custom domain that I use for e-mail. The mail server is configured with a catch-all that redirects messages to any user to my inbox. For the first time this afternoon, I received a benign "auto-reply" to a message ("I'm driving and will get back to you later") that was "sent by" accnt966.wellsfargobanking.online02921@mydomain.com and sent to some phone number @vtext.com (which seems to be Verizon).
My domain is configured with SPF, which previously seemed effective at preventing spammers from spoofing the use of my domain (based on no longer receiving bounced messages). However, it seems pretty clear that someone managed to send a text message that looked like it came from my domain. Do I need to configure anything else to prevent this? Is this Verizon's fault for not checking? Or should I conclude that someone was able to send spam from my email provider?

Only using SPF, DKIM and DMARC does not protect you from spoofing addresses.
SPF supports "fail" and "soft fail". Some mail providers are using "soft fail" because it is like a debugging flag, which means "the sender is not valid, but i will accept it"
If you want to stop spoofing, you should use "fail" in your spf record. If you import the rules from your provider, you can override the qualifier. Only the last qualifier is important.
With SPF, the attacker should not able to use a different server. If you are in a hosted environment, another user can spoof your address, if the server does not check, if the user is allowed to use the mail address.
In 2020, Google was affected by such a vulnerability: https://ezh.es/blog/2020/08/the-confused-mailman-sending-spf-and-dmarc-passing-mail-as-any-gmail-or-g-suite-customer/
Using DKIM and DMARC, the server signs your email and the recipient can be sure, that the email was sent from a valid server and the user was allowed to send emails with this address.
RFC-7489 (https://tools.ietf.org/html/rfc7489) in chapter 3.1 is the behavior of DMARC and the "From:" field defiend.

Thus, this field is the one used by end users to identify the source
of the message and therefore is a prime target for abuse. Many
high-profile email sources, such as email service providers, require
that the sending agent have authenticated before email can be
generated. Thus, for these mailboxes, the mechanism described in this
document provides recipient end users with strong evidence that the
message was indeed originated by the agent they associate with that
mailbox, if the end user knows that these various protections have
been provided.

This means, if you are using SPF, DMARC and DKIM, the sender field "From:" is trusted.
The DKIM signature is not like S/MIME or PGP, it is a server signature, which only protects the headers and not the body of the mail..


How secure is a Windows password protected zip file? I need to send some sensitive information to a client. I thought I would email a password protected zip file I created using Windows XP and then call them with the password. Presuming I pick a good password, how secure is this approach? Specifically, how difficult is it to decrypt a password protected zip file?

When creating a password-protected Zip file (with the "compressed folder" utility integrated in the OS), Windows XP uses the "standard" encryption algorithm for Zip files. This is a homemade stream cipher, and it is weak. With 13 bytes of known plaintext, the complexity of the attack is about 238 operations, which is doable in a few hours on a PC. 13 bytes are relatively easy to obtain (e.g. if one of the files in the archive is an image, it will probably be uncompressed and begin with a known header). The result has even been improved, notably because the files in an archive are encrypted separately but without proper key diversification. Some years ago (quite a few now, tempus fugit), I have seen a password cracking software by Ivan Golubev which put this science to good use, and could crack Zip encryption in an hour.

The attack on Zip encryption is actually:

a nice introduction to cryptanalysis;
a good exercise in programming;
a reminder that you should not roll your own crypto. Phil Katz was very good in his domain, but the best cryptographers in the world will tell you that it takes much more than one extremely good cryptographer to make a secure algorithm -- it takes many cryptographers who feverishly propose designs and try to break the designs of the others, for a few years, until a seemingly robust design emerges (where "robust" means "none could find the slightest argument to support the idea that they may, possibly, make a dent in it at some unspecified date").

Now, if you use a tool which supports the newer, AES-based encryption, things will look better, provided that the format and implementation were not botched, and the password has sufficient entropy. However, such Zip files will not be opened by the stock WinXP explorer.

If an external tool is required, you might as well rely on a tool which has been thoroughly analyzed for security, both in the format specification and the implementation; in other words, as @D.W. suggests: GnuPG.

As for self-decrypting archives, they are all wrong, since they rely on the user doing exactly what should never be done, i.e. launching an executable which he received by email. If he does open a self-decrypting archive you send him, then he will just, by this action, demonstrate that he is vulnerable to the myriad of virus/worms/whatevers which roam the wild Internet, and he is probably already infected with various malware, including keyloggers.

Nevertheless, there is a way, in your specific situation, to make a self-decrypting archive reasonable. It still needs your client to install a new piece of software, but at least it is straight from Microsoft: the File Checksum Integrity Verifier -- a pompous name for a tool which computes file hashes. Send the self-decrypting archive to your client, and have him save it as a file (without executing it, of course). Then, have him run FCIV on it, to get the SHA-1 hash of the file. Do the same on your side. Finally, compare the two hashes by phone (it is not hard to dictate 40 hexadecimal characters). If the two hashes match, then your client will know that the file was not modified during the transfer, and he will be able to execute it with confidence.

(That is, if your client trusts you, and trusts that your machine is not clock full with virus which could have infected the archive on its way out.)


How can we retire SHA1 in prefernce to SHA256 or SHA-3? According to http://www.pcworld.com/article/3174676/security/sha-1-collision-can-break-svn-code-repositories.html and https://www.theregister.co.uk/2017/02/23/google_first_sha1_collision/ you could have two objects generating the same SHA-1 checksum. I am guessing this also effects in key generation as well.

Is there a way a project which is starting and using git could do to make sure that it uses SHA-256 from the start instead of relying on SHA-1 . If yes, how ?

Comments, observations all welcome.

The issue with SHA-1 is not an issue unless you are trying to generate two pieces of data who's SHA-1 collide.  This is a lot different than generating one SHA-1 that collides with an existing SHA-1 which is what you would have to do to compromise sourceforge or github.  This is a statistical difference that is best described with the birthday attack (https://en.wikipedia.org/wiki/Birthday_attack).


Are there any feasible solutions/workarounds for WPA2 hole196 vulnerability as of today? I just read about a post linked to from archived Michał Zalewski's archived post on wireless security and heard of an insider-only WPA2 flaw that lets anyone who knows the wireless password snoop on other people's traffic and inject their own in the middle of the communication.

I noticed that there are only 9 posts about hole196 on security.stackexchange.com and the only informative ones date back to 2012. I would expect a lot to change for the last over three years, thus the question - are there any feasible server-side solutions/workaround to the hole196 problem as of today, apart from using a VPN? If no, is there any stronger wireless encryption standard?

There are solutions already on the market provided by several vendors. These include client isolation (clients are not allowed to talk to eachother using the wireless access point as medium).

Other mitigating techniques include wireless IPS which detect MAC spoofing. MAC spoofing is nescesary when the attacker wants to trick the client in thinking he/she is the gateway.

Of course these mitigations are not part of the protocol but rather additional controls you can opt to implement.


Definition of security incident What's a security incident in information security?
Can an unsuccessful attack (blocked by an IPS for instance) or an attack without real impact (a port scan for instance) be considered a security incident?

To be clear, to you as a member of an organization, a security incident is defined by your organization's security policy; it's not just "your personal opinion on what's risky" or "any event that puts the organization at risk".  Check with your organization, read their security policy, and follow its guidance.

If they don't have such a policy, and you're asking this question, that's a sign they may need one.

In the absence of a policy, you should consider it from your own point of view.  If you found a vulnerability, or possible evidence of an attack, you should document it and report it to your supervisor as quickly as possible.  It's the job of management to decide what's risky and what isn't, not you.  If you don't report it, and the problem turns out to be serious enough to involve the courts, there will be a lawsuit.  The first two things the lawyers are going to want to know is "who knew about this, and when did they know about it?"  If they find you learned about the incident but didn't report it, the legal mess could ruin you.

And once you've reported it upwards, you've discharged your duty.  If they decide not to act on it, that's their decision; even if it seems foolish or risky to you for them to ignore it.  Just make sure you've documented the incident so that people can understand you did what was reasonable given the circumstances you were in, and informed the correct person or people.

The same goes if you're a supervisor or manager, and an employee informs you of a risky or dangerous situation.  You need to report it as per your organization's security policy, or report it upwards if you don't have one.


Why are root certificate authorites allowed to issue certificates for any domain? Why are certificate authorites allowed to issue certificates trusted by browsers for any domain name?

Doesn't that imply that one highjacked root certificate authority can issue trusted fake certificates that any browser trust. This is not very secure from an end user perspective.

Would it not be more secure that you designate which root certificate authorities are allowed & trusted to sign certificates for your domain name records for example via DNS SEC? Similar DNS examples are also mail SPF records where you say which mail servers are allowed to send mail from your domain.

Why is it designed to trust all root CA to issue certs for any domain name?

Why is it designed to trust all root CA to issue certs for any domain name?

This has historical reasons and maybe for reasons to promote competition. At the beginning you had only a few root CA with very high prices. Now the prices are down because all CA can issue a certificate for anybody. If each CA would only be able to sign certificates for a specific part of the internet this competition would not be possible.

Such insecure initial design you have in various parts of the internet protocols and it is usually worked around by adding optional security, i.e. pinning for certificates, content security policy against cross site scripting etc. Of course, all of this is is just added optional security and thus rarely used. The general thinking is that it works without so why care.

  Would it not be more secure that you designate which root certificate authorities are allowed & trusted to sign certificates for your domain name records for example via DNS SEC?

There are ideas to use it and in the area of mail security DANE is slowly gaining followers and there are also proposals to store SSH or other keys and certificates (or fingerprints) in DNS. The main problem is that one would need to first have DNSSec available everywhere before one could rely on DNSSec to deliver all these certificates. But for now only a small part of the internet is protected by DNSSec. Also lots of DNS resolvers don't deal with DNSSec at all or not properly and at the application level you usually have no access to the protection status of a DNS response too.

  Similar DNS examples are also mail SPF records where you say which mail servers are allowed to send mail from your domain.

SPF or DKIM records are considered not that much security relevant and thus delivery of these records with unprotected plain DNS is considered acceptable. This would not be the case with certificates where you would need a response you can fully trust.


Tools for analyzing Perl 5 code? I'm looking for good tools for analyzing and/or detecting security issues in a large software project written in Perl 5. It could be static or dynamic analysis. I know that Perl is undecidable, but I'm decided to try any tool that allow me to reduce the work need to review such a large amount of code.

I tested RATS, but it only looks for a very small and limited number of vulnerabilities.

CERT has create a CERT Perl Secure Coding Standard and there's been discussion of having Perl::Critic have a set of policies that match their standard.  As far as I know, nothing's been done yet.  Here's the start of the discussion on the Perl::Critic dev mailing list.


Protecting a PGP private keyring on host? I'm trying to use crypt to encrypt some configuration files. Under the hood, crypt uses PGP to do the encryption. The readme states:

  In order to decrypt a value, your application will need access to the
  private key. We recommend putting the private key on the server and
  protecting it with standard host level security.

What does it mean by protecting it with "standard host level security"? Does this just mean ensuring that file access permissions are restricted?

Security is often applied in layers, so that if one layer is compromised the other layers will still provide protection.  Host level security refers to the layer of security applicable to hosts - primarily related to the operating system, but also to the BIOS and other systems.  Other layers include Network and Application security.

Some examples of the vulnerability categories for hosts are provided here:

https://cs.uwlax.edu/~riley/CS555Sum10/readings/3.1.pdf

where they list:

  The computer must be secured physically.
  The O.S. most likely needs to support multiple users and manage their authorizations.
  The O.S. most likely must manage process authorization in a multi-tasking environment.
  Some O.S. provide users remote log-in, which introduces unique vulnerabilities.
  The O.S. must manage memory as an asset to be used by processes.
  The O.S. must provide a secure file system.
  The O.S. often provides for certain forms of security related to traffic to its network interfaces.
  The O.S. must manage permissions that are granted to application software.

So host level security is more than just file access permissions, and considers the security of the host overall.


Is it possible to maintain security and data integrity through a network decrypting HTTPS? A network I often use has started to decrypt HTTPS traffic (and reencrypt, using a different key) using a local proxy. This proxy is operated by people I mostly trust. However, I would like to know if there is a way to maintain encryption and MAC through said proxy, with something like Tor or a VPN. Bonus points for ease of use.

I would also like to ensure that there is not a second MITM, between the local proxy and internet server, if I am not using the above methods, for example, if they are blocked somehow. If there is another MITM present, I'd like some form of warning, similar to the one a browser gives when using an untrusted certificate.

SSL in the context of web browsing allows you to create a secured (encrypted) tunnel between your browser and a SSL-enabled endpoint.

The SSL-enabled endpoint is typically the server you want to reach, but as you mention in your question, you may have a HTTPS decrypting proxy on the way. This proxy terminates your SSL connection (it is therefore in clear from that point, analyses it, and then creates an SSL tunnel with the target server.

What this mean is that during the time your connection is decrypted everything you send can be read.

This "everything" can be plaintext data (like a password for instance) or whatever you push though this connection (an encrypted file for instance). You could also build a "tunnel in tunnel" of sorts: an ssh connection which can act as a proxy forwarding a local port on your machine to a port on a target server. The HTTPS connection is decrypted by your HTTPS proxy, but the ssh one remains.

I do not know whether you are asking the question from the perspective of someone who has to go though such a proxy, or someone who puts such a proxy in place. If the latter - be very much aware of the potential legal consequences. Your local law may not allow that, or you may be held liable for anything which goes wrong during the decryption phase.


Calculate Content-Length (HTTP Request Smuggling) I am trying to understand more about HTTP Request Smuggling and I have been reading this article (https://portswigger.net/web-security/request-smuggling). Content-Length represents the length of the entity-body in bytes (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) but where does the counting start?

Portswigger example (CL.TE)

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

How was 13 derived? If I count the newlines before 0 and between 0 and "SMUGGLED", the total is 12? Do I count the newline after "Transfer-Encoding: chunked" as well?

Portswigger example (TE.CL)

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

Similarly, where do I start the counting?

Any help is appreciated.

Content-Length represents the length of the entity-body in bytes but
  where does the counting start?  How was 13 derived?

0 is the first character counted in your first example, but newlines in HTTP are usually CRLF (\r\n) which is two characters.  Accordingly:

0\r\n            3 characters
\r\n            +2 characters
SMUGGLED        +8 characters equals 13 characters (no trailing CRLF)


What is an example of arithmetic and buffer overflows in a php application? I'm trying to find evidence whether it is possible to have overflows in a php application, whether buffer overflows or arithmetic overflows.

I believe it's possible to have these overflows in the core php software, but this question is about overflows in an application written in php.

Arithmetic Overflow

You cannot have arithmetic overflows in PHP, at least not in the sense that the number wraps around, leading to a smaller result than expected (which is the kind that may have security implications).

There are two reasons for this:

if an integer is increased above its limit, it is automatically converted to float.
if a float is increased above its limit, it is automatically set to INF, which is treated as the largest value.

You can try this yourself:

$max = PHP_INT_MAX;
var_dump($max);         // int 9223372036854775807
$max = PHP_INT_MAX + 1;
var_dump($max);         // float 9.2233720368548E+18

$max_float = 1.8e307;
var_dump($max_float);   // float 1.8E+307
$max_float = 1.8e307 * 10;
var_dump($max_float);   // float INF

It works the same way for negative numbers.

But even though you do not have an overflow of integers in the traditional sense, you still might run into problems. Consider for example these cases:

PHP_INT_MAX < (PHP_INT_MAX + 1) // -> false
PHP_INT_MAX == (PHP_INT_MAX + 1) // -> true

Arithmetic Underflow

You can have underflows in PHP:

$min_float = 9.8813129168249E-324;
var_dump($min_float);   // float 9.8813129168249E-324
$min_float = 9.8813129168249E-324 / 10;
var_dump($min_float);   // float 0

As 0 is equal to a number of things, among them NULL, false, "0", "foobar", this may cause problems in some situations. But these problems aren't really a result of the underflow.

Buffer Overflow

Buffer Overflows in PHP may exist because of vulnerabilities in PHP itself, but not because of application code.

Here is a list of some buffer overflow vulnerabilities in PHP.


x.509 CRLs: next update? An X.509 certificate revocation list contains a field specifying when the next such list is expected to be issued.  I'm trying to figure out the importance of this field...I know that sometimes certificates are placed on a "do not use" list, and this needs to be updated constantly. But I also feel like the CRL update on a regular basis, so what is the point of having this field anyways? Why not just use a fixed schedule?

There are two distinct semantics that the nextUpdate field is used to convey:

the date at which a newer CRL should be available, thus making it worth a new download (similarly, before the date given in the nextUpdate field, a cached CRL should be considered to be the newest);
the date after which a given CRL should be considered obsolete.

It is expected that CRL overlap, so that transitions are smooth and network traffic spread throughout the day. Typically, a CA would produce a new CRL every hour (so that fresh information is available) but would "allow" a given CRL to be valid for one day (24 hours). Since a CRL can be somewhat large, downloading it is expensive, thus implementations would prefer not to do it too often if it has no practical use. But since each CA has its own policy, a generic certificate validator cannot know a priori what kind of schedule a given CA uses; it must learn it through the data in the certificates and CRL.

The first meaning is what X.509 mandates. However, everybody uses it with the second meaning. In effect, implementations of X.509 (e.g. in Web browsers, when they validate the certificate of a Web server) handle nextUpdate as if it was an endOfValidity date. Lately, Microsoft has defined a new extension called nextPublish which assumes the first meaning (the extension can be seen in annex A.1 of this draft, in an OCSP context). This extension (which seems to be, so far, private to Microsoft, not standard) somehow acknowledges that the common practice deviates from theory with regards to the meaning of nextUpdate.


Why is Zone Alarm Blocking VMWare Virtual Network Editor? I have version 15 of VMWare running on my Windows 10 computer.

When I open the Virtual Network Editor and try to add a bridged connection, I get an error saying:
Cannot change network to bridged: There are no un-bridged host network adapters

I know Zone Alarm is preventing this as I have to uninstall it in order to be able to add a bridged network.

Unfortunately it is not a case of disable it, but I have to uninstall it, and then I can do what I need to in the network editor.

Does anyone have any experience with this?

If ZoneAlarm is preventing your application from connecting to the network you can find the Related logs and when you read the log you can find why it has been blocked and therefore you can find the right solution to solve the issue, here is ZoneAlarm Alert and Logs documentation.
ZoneAlarm has an application control mechanism that should be configured properly to allow your application from execution and data transmission and prevent the malicious program from running, here is also a helpful line to ZoneAlarm application control.
There should be many reason why it blocking your application from connecting to the network but a common issue is that maybe the pattern of transmitted traffic looks suspicious, like too many connections ((Behavioral Detection).


When generating user session tokens, should i bother checking for a duplicate? In a program i am writing, i use session authentication tokens that we give back to a user to have them hand in with their requests.
This is working very well but this question is about the generated token and chance of collision.
Here is the PHP code used to generate a token: bin2hex(random_bytes(32)).
I have been considering for a while on generation of this token, should we do a quick database check that it does exist already.
I fully understand the low chances of this happening, but because it's a possibility should i check anyway? or are the chances so low that the lines of code checking are comedic from the point of view of others that read the commit?
Put another way from an info sec perspective: Is the risk assessment of one user getting into another users session a high enough danger that we should always check for session token collisions?

I fully understand the low chances of this happening

With all due respect, I don't think you do :P I would say the chances are indeed comedically low!
The first thing to check is the quality of the random numbers. The PHP docs claim that these are cryptographically secure pseudo-random bytes. Good good.
Next, 32 bytes = 256 bits. IE 2256 possible values, which because it's a cryptographic RNG, we assume will chosen uniformly at random. To understand the probability of naturally-rolling a collision, watch this excellent 5 min video.

How secure is 256 bit security?

Paraphrased:
Say you generate a random number with PHP's random_bytes(32). How long until you expect to see that number come up again naturally?

Imagine that you have a machine packed full of 8 GPUs generating numbers with PHP's CSPRNG as fast as they can. Now imagine that half the people on Earth had their own personal kilo-google's worth of those machines (1000x the number of CPUs that Google is estimated to own). Now imagine a galaxy with 4 billion copies of that Earth. Now imagine 4 billion copies of that galaxy. Let them run for 37x the age of the universe. And you're still missing another factor of 4 billion before you would expect to see a natural collision on a 32-byte random number.

32 bytes seem short, but people tend to have very bad intiutions about what it means for that number to have 2256 possible values.
So put in the uniqueness check if you want, but know that your CPU will rust out and return to the earth long before you expect that line of code to trigger. Seems like a waste of a DB search to me.


Client-Side Anti-XSS Measures What are the reliable and stable client-side JavaScript libraries for XSS prevention and why? It would be very beneficial if you could provide details like:

browser support
conformity to any standards (like OWASP guidelines)
their approach (e.g. minimal escaping, blaclisting/whitelisting)
any tests they passed (are there such industry standard XSS tests?)
is it actively maintained for recently discovered threats

You can add more items to the list.

First and foremost,  XSS is an output problem - one which almost always affects the server's output, and is therefore patched on the server. XSS allows for an attacker to inject JavaScript, which is used to hijack the browser and perform any action as the victim.

The only viable client-side XSS mitigation is having a strict content-security policy (CSP) which disallows inline injections. The CSP is a set of server-defined rules that are enforced by the browser and is used to limit the execution of JavaScript. The CSP is a new and very powerful tool for shutting down XSS.

Another common approach to client-side XSS mitigation is to use AngularJS templates. A secure template language like AngularJS will mitigate XSS by neutralizing executable code which was intended to be displayed as text.  This is a great approach to developing secure applications. However an application that uses AngularJS cannot protect against API calls that are vulnerable to XSS, only the CSP can do that.

AngularJS + CSP will make an application very difficult to exploit with XSS, but nothing is 100%. There is still the possibility of DOM based XSS and Cross-site attacks in Flash, which are both very similar to each-other.  There is no blanket mitigation here, not even a Web Application Firewall (WAF) can stop these attacks - they are perfect and widespread.


Fake email sent through newsletter service: how to know who sent them? Suppose a guy sends emails through a service that sends newsletters, but he copies an invitation sent to him, and uses this service to send more invitations to uninvited people, and puts the email of the host as the sender.  Can we know who did that? Is there something in the email that could let us know the service he used, or any other way to know from where came this fake invitation?

Bottom line - forget about it and move on

Email is inherently insecure. It is a trivial task to fake mail headers, there are far too many insecure and misconfigured mail servers which will accept/dispatch/relay messages from anywhere and there are numerous services available to send 'anonymous' messages. While mail headers may provide some information, you have to treat the information as suspect and only use it as a possible indicator.

The situation is further complicated by the fact that this is a global issue. While many countries have legislation which prohibits sending of unsolicited email and/or prohibits using false information, such as sender details, the ability of law enforcement to do anything about it is limited. We have about 50,000 users where I work and over 70-80% of the email traffic delivered to our sight is identified as spam (that is a conservative estimate). Even if law enforcement was able to do something about this, just the huge volume is enough that they will only be able to investigate a very small percentage. I suspect if you did report your case, the authority concerned would possibly take down your details and then file it in the round filing cabinet under their desk.

There is also the added complication of viruses and malware. There have been numerous examples of these using local adress books to send emails under the credentials of the system owner without them even being aware it is going on. This makes it even more difficult to prove a message has been sent deliberately and with intent. Even if it wasn't done by a virus or malware, the user could easily say, "yes, sorry about that, I accidentally hit the wrong button". Unless you can show repeated and deliberate malicious behaviour, there is little that can be done.

There are ways to make email more secure. Unfortunately, few if any, are transparent to the recipient. For example, you could use certificates and/or PGP signatures etc, but unless the recipients client is able to handle such techniques, there is little point. This also won't stop someone with malicious intent who is a legitimate recipient of your message from doing something like re-distributing your invite to others.

Tim


Is "mini-httpd" a secure web server? I'm using http://acme.com/software/mini_httpd/ for my embedded system. Is it as "secure" as more known web servers like Apache or lighttpd?

Being a lesser known web server means that it's less likely to be targeted by attacks, but maybe also less tested.

Update: As pointed out by Moti Korets here, my answer relates to "Vector Ultra Mini Httpd", not "ACME mini_httpd" that I now realise was being asked for by the OP.

Vector Ultra Mini Httpd

No it is not secure.

Even the latest version, v1.21 suffers from a serious stack based buffer overflow meaning that a remote attacker can gain control of your system. CVE here.

ACME mini_httpd

See jimis excellent answer here.


Apparmor system-wide security -- white-listing I want to only white-list applications that can run on my system using Apparmor, I know it is used to confine applications/programs based on their path names, but what I need is to contain those applications to run in confinement, and everything else is black-listed .. Can I do that in Apparmor, or I'm talking about the wrong tools.

By default AppArmor whitelists all applications/programs. To setup apparmor so all applications/programs by default are blacklisted then you need to setup AppArmor Full System Policy. This is not a simple task but can definitely be done. Refer to the link for the details: https://gitlab.com/apparmor/apparmor/wikis/FullSystemPolicy


Found a bug in a software product used by the pentesting customer; Who to report it to? Let's say I'm doing a pentest on BlueCorp and find a bug in the software UnrealSec made and distributed by SecCorp which is used by BlueCorp and found during said pentest. Should I report this bug to both BlueCorp and SecCorp or only one?

For an ethical disclosure, I would create two different reports:

Report it as a general finding to BlueCorp, which would help them to decide whether to stop or interrupt using the product or mitigate the threat otherwise, depending on how severe it is.

Send a more detailed report on the bug, possibly with a proof of concept (POC), to the developers of the software i.e. to SecCorp.

This prevents BlueCorp from using or selling this information before the SecCorp has had time to fix it. After all, it is unlikely BlueCorp would need more detailed information, as they would not fix it by themselves anyway.
Unfortunately, you are only contracted and paid for the first report, but that is a responsible thing to do. Who knows, you might even get another gig from it.


Can Snort or Suricata *edit* packet on the fly? I know that they can detect traffic by rules, but can they modify packets on the go?

For example, not only detecting HTTP GET but also adding headers to the GET packet.

If they can't, is there an open source program that can do this at a network scale?

Snort and Suricata work on the packet level. While they can reassemble a TCP stream for analysis spanning multiple packets they have not the ability for making changes to the data stream which involve changing the length of the data, i.e. adding some HTTP headers or removing content.

While it is possible in inline mode to replace some content with another content the length of the content cannot change. Otherwise all following outgoing and incoming packets in the TCP stream would need to be changed as well in order to match the shift in TCP sequence numbers caused by the modification. It might even be necessary to include new packets into the stream, properly deal with the TCP window etc. At the end this would mean to implement a complete TCP stack and all these changes would also significantly impact the performance.

  If they can't, is there an open source program that can do this at a network scale?

Modifying the traffic in a significant way is the domain of application layer gateways (proxies) which can also be added transparently into the network path. For  HTTP one could use for example the squid proxy. It comes with some the built-in functionality for checking and modifying the traffic (ACLs, adding header...). For more advanced modification one can provide own ideas using the ICAP or eCAP API.


What would the potential abuses be for an HTTP API that accepted raw SQL? I was wondering what some of the potential abuses could be for an HTTP API that accepted SQL queries and output results sets.  The fact that this is the canonical definition of SQL injection is not lost on me :)

In my case, I have a specific PHP/MySQL application in mind which is Magento - an eCommerce platform.

Here are a few security measures I've considered:

Non-standard URL route - to prevent mass scanning, each installation would have it's own URL route (this is similar to how Magento's admin backend is handled)
A decent length API key
HTTPS-only access
Read-only access via a read-only MySQL user.
Read-only access via SQL parsing.  It would require a little less configuration if read-only access could be implemented this way.  I was considering simply parsing the queries for "INSERT ", "UPDATE ", "DROP ", etc.
Blacklisted tables and fields.  For the most part, configuration data is stored in a table called core_config_data, so that could be blacklisted.  Also things like credit card tokens can be stored in a specific field of a specific table.  In very poor implementations, credit cards can be stored in the clear as well, which would need to be blacklisted of course.
White list table and field access - Perhaps only allowing access to whitelisted tables and fields would be a better approach than a blacklist.
There are a lot of community extensions that could potentially store sensitive information as well.  It would be hard to generically block them by default, so I think a whitelist might be the only option to solve for this.
Some mechanism for a maximum number / frequency of retries
Other standard things that are used to secure SSH connections for example, such as an IP whitelist, public key auth, VPN, etc.

Assuming that these measures were in place, would this be as secure or more secure than, let's say, SSH access locked down by an IP whitelist.

UPDATE: Few more specifics of the application, to follow up on some of the questions in the answers.

The thing that I'm looking to build is a Magento module that will get deployed to the store and accept SQL queries to return back data to my SaaS app.  I own both the module and the SaaS app.
The application in question would be a SaaS app that tapped into Magento to pull data in.  So it's not a situation where only trusted employees have access.
The ideal minimal level of security (from an amount-of-configuration perspective) would be to not use a read-only user.
Let's assume that the false positives that would be blocked are not an issue (Sorry, "Bobby Insert Tables").

UPDATE 2: Just wanted to flesh out a little bit more the reason why I chose to frame this question in terms of comparing it to an SSH connection with an IP address whitelist.

An SSH connection for all intents and purposes is already functionally the same as a raw SQL API (plus a whole lot more) in the sense that you can SSH in and connect to MySQl and then do whatever.  So my thinking is that if a SQL API is as secure or more secure than an SSH connection, it may present an acceptable level of risk.

Also, I know this type of question can be overly subjective, so I wanted to frame it in a way that could have a relatively objective answer, which is why I wanted to compare it to a specific SSH scenario.

The potential for abuse obviously depends on the application.   Does this only face trusted employees on an intranet/VPN with privileged access?  Would these employees otherwise have read-only access to the DB, because there's a multitude of diverse queries they'll need to run on the data?  In that case, I can imagine allowing arbitrary raw SQL queries to be generated by the trusted user.

Or is this application out there facing any random attacker who may see your online store and is trying to do havoc?   In that case -- I strongly recommend you do not do this.  Take the time and go through the workflows and create the allowed parameterized queries that have permission to be run -- the user of the HTTP API only has permission to alter the parameters to these queries.

Parsing the SQL command for bad terms like UPDATE/DROP is a very bad idea.  People can get really clever bypassing these preventions (e.g., you bypass filters that remove <script> tags by using <scr<script>ipt> which then becomes <script>).  Similarly there may be valid reasons for some field to have the value "Update" in it.  There's possibilities of encoding issues/unicode normalization issues to bypass your filter.  E.g., an attacker sends DRO%C0%50 in the URL encoded string which gets past the filter that flags "DROP", but then when the bytes DRO\xc0P gets sent to the database its processed identical to being DROP allowing an attacker to drop the database.   (For more see this trick used in directory traversal attacks).

Having a read-only account is a better solution, but again you may not want an attacker to be able to access some private fields (e.g., CC #s, hashes of passwords, etc.).  Furthermore, it isn't hard to just create malicious SQL commands that are very CPU intensive and can be used to do a denial of service attacks on your database.

Letting an untrusted end-user write code (and an SQL command is code) is always an anti-pattern and should be avoided.  Yes, this will require more work initially coming up with the allowed parameterized queries, but its well worth it.

EDIT:

If your queries that are generated by your application are always fully trusted this is a different issue.  That is your application is generating pairs of parameterized queries like "SELECT name FROM users WHERE id = ?" sent to the database along with an array of untrusted user input -- ["1"] or in case of a failed SQL injection attack ["1 OR 1 = 1; DROP TABLE user; --"]).  Or potentially more problematically, but possibly safe you use some existing well known SQL injection sanitizing functions to sanitize your input to send something.  I personally wouldn't risk the second route, but a mature sanitizing functions may be able to do this.

Then all you need to do is use authenticated encryption (e.g., the messages are encrypted and MAC'd) between your application and the HTTPS API.  An IP address white list would be one reasonable way to accomplish this (in addition to say sending a password) all over TLS (and verifying identity of the other server hosting the API to prevent Man in the Middle attacks).


Are there techniques or methods to develop security protocols without side channel attacks? In general timing attacks are a manifestation of the implementation. So if I am processing data on the server or the client then I can leak information depending on how the code is written.

To prevent such vulnerabilities, as much as possible, I need to make sure I always process the same amount of data whether I accept the request or return an error.

Then I can also pick crypto algorithms that are designed to be resistant against such attacks like the EdDSA or Chacha.

However, is there something I need to/can I do when I am creating the protocol itself? Something in bytes sent back and forth that can either help in my implementation when processing it or in general that attackers can use in a side channel? Are there papers/studies about that? I couldn't find any.

Avoiding side-channel attacks in protocols (or in general) requires just a few things. Unfortunately, it's often easy to slip up, as it is not always intuitive. The general way to avoid side-channel attacks is to ensure that any behavior that can be monitored by the attacker is not in any way dependent on any secrets which the attacker must not be able to access. A simple example is string comparison. How long a task executes is behavior available to the attacker. With a simple, "unsafe" string comparison function, the time it takes to compare the string is dependent on the number of matching characters.
In order for this question to be answerable, you have to define where your attacker is. Are they on the client, running an untrusted process next to one handling sensitive data? Are they on the server? Are they simply monitoring the traffic going back and forth between the client and server? Knowing this will allow for a more precise answer. Since there are a large number of papers detailing side-channel attacks, knowing your precise threat model is even more important for suggesting papers to read.
On the computer itself
If the attacker is listening on one of the computers handling sensitive data, avoiding side-channel attacks is harder. You must ensure that memory accesses and computations on secret material occur without regards to the value of the secret. This means avoiding certain common optimization techniques that take "shortcuts", skipping unnecessary operations. Unfortunately, doing this correctly often requires an understanding of the underlying CPU architecture. Sometimes, under specific and obscure circumstances, the same instruction may take longer based on the contents of the secrets. An example is any instruction accessing memory. The speed at which it accesses memory depends on whether or not the data being accessed is in the cache, opening up the possibility of cache-timing attacks (such as Flush+Reload).
Avoiding side-channel attacks that exploit the behavior of the cache requires both an understanding of the algorithm being processed itself, as well as the architecture the algorithm is running as. One of the most-studied examples is AES, where a common optimization stores S-boxes and round keys in the cache. This is very fast, but vulnerable. The solution is to implement it using bit-slicing.
Over the network
If your attacker is simply monitoring the network, the solution is much easier. Generally, unless the network is exceptionally low latency (a very, very fast local LAN), the timing required to perform side-channel attacks is often lost in the noise on any regular network. An attacker very close to the server (its own router, a router very near it) may be able to obtain more precise timing information. This means that, in general, timing attacks over the network are not a problem, but it doesn't hurt to avoid the risk anyway. This can be done in the same way as if the attacker is local. Simply ensure any sensitive computations are constant-time. String comparisons should take the same amount of time regardless of whether or not all the characters match, some of the characters match, or none of the characters match.
A common example
As mentioned a few times before, one of the most common mistakes people make is to use optimized string comparison functions on secret strings.
An unsafe string comparison function. It will immediately return an error as soon as the first non-matching character is found. Timing how long the function takes to return false will allow an attacker to brute-force the password one character at a time. It is suitable only in situations where the attacker cannot determine how long it takes for the function to return.
bool password_check(char *s1, char *s2, int len)
{
    while (len--)
        if (s1[len] != s2[len]) return false;

    return true;
}

A fairly safe string comparison function, suitable for use in high-latency networks where nanosecond-level timing information is not available to the attacker. It checks the whole string and keeps going even if it knows the strings do not match. It will take a constant amount of time to check if the passwords match.
bool password_check(char *s1, char *s2, int len)
{
    bool mismatch = false;

    while (len--)
        if (s1[len] != s2[len]) mismatch = true;

    return !mismatch;
}

Note that this is constant-time in theory, but an attacker able to do extremely precise monitoring may still be able to gain some information from it. For example, setting mismatch to true involves, at the least, writing 0x1 to a register. Setting it to false on the other hand is often optimized by XORing a register with itself, which sets it to 0x0. Whether or not this is done depends on the compiler, so a highly sensitive string checking implementation should be done in assembly, with a good knowledge of CPU optimizations. If it must be done in a higher level language like C, you must understand how it will be compiled into assembly and design it so that optimizations will not result in a side-channel attack.
A very safe string comparison function. It uses bitmasks to determine whether the strings match. It is suitable for use when an attacker can precisely time how long it takes the function to return.
bool password_check(char *s1, char *s2, int len)
{
    char mismatch = NULL;

    while (len--)
        mismatch |= s1[len] ^ s2[len];

    return !mismatch;
}

Another common way to avoid side-channel attacks when comparing strings is to hash them, and compare the resulting digests. A hash function should take the same amount of time for input of a given size regardless of the contents of the input. The output will be of fixed size, and can be safely compared with an "unsafe" comparison function.


RECon 2012 and before Anyone knows where can I get materials/presentations/trainings from RECon 2012 and before? Is there any place where I could buy it or download it, if it's free - I doubt it, but who knows?

You can find the slides of 2012 here in the schedule... the other material can be found here

Have a nice day ;-)


Is it safe to use TLS_RSA_WITH_NULL_SHA cipher? I'm seeing TLS_RSA_WITH_NULL_SHA cipher is being listed when I do a TLS_1.2 connection test using TestSSLServer tool. I remember a while back some security test tool reported NULL cipher should be deprecated and it is not a good practice to implement for a secure application.

My question here is how risky would it be to have RSA_WITH_NULL_SHA in my application where security is a major concern.

Any suggestions/comments/thoughts are most welcome.

This largely depends on your security goals. NULL ciphers provide authenticity and integrity checks, but do not offer confidentiality. That is, when such cipher is used an adversary with a passive traffic capture ability will be able to know what you are sending over TLS channel. Additionally, an adversary in MitM position can cause downgrade into this cipher. So if confidentiality is at all important even in some circumstances, this cipher should not be on the list.

Again, to make sure you understand, NULL ciphersuites offer no encryption at all .


What exploits are possible in languages like C/C++ other than overflow errors? I know that C/C++ programs are highly susceptible to overflow errors that lead to program compromise. But I was wondering, are there any other vulnerabilites that can exist other than overflow errors? I am aware of dangling pointer references, off by one and integer errors, but is there any way other than leveraging overflow errors to exploit programs?
If yes, then please suggest some readings and references.
Thanks

Since C (and C++ which can be technically be considered an addition to C) is close to Assembly, Much of the details of the processor have to be modeled and controlled from within its constructions. The easiest example that shows this is the array index overflow bug.
 This bug entails the improper use of an array index in such a way you retrieve a piece of memory that was not allocated to said array.

int[2] arrayX;
printf(arrayX[3]);

A proper compiler will complain in the code block above about index out of scope since a static analysis of the code already shows it. You can also use dynamically created arrays that are of unknown since at compile time and there no warning will be given.

Now, when you enter a function you effectively assign a code return address into the stack. as well as locations for the return "object" in same said stack. This stack is called the call stack and should not be manipulated by the program under normal operations.

With both of these mechanics we can 'trick' a program into running our own code. we do this by adding processor instructions on a known memory location, and manipulate the call stack to change the return pointer to my injected code block. (this is called code injection).

This behavior can be triggered by an overflow error or some other mechanic to adjust the call stack, this is dependent on the OS in operation and the Hardware in use, and is the main way exploits work.

There are however exploits that exploit lower level calls than C offers (basically injecting machine code / assembly into the program code).

In C++ there are additional methods of adding code to an application, through utilization (or abusing) of the Class loading mechanics.

If you want to learn about these concepts I would suggest learning about metasploit. Reading up on how C works in detail (the c bible is a good start)
and try and read the GCC compiler documents.


Chance of guessing any valid credit card data What's the chance of guessing valid credit card data that could be used to make a payment online? To me, it looks like it's not extremely hard to guess, but I'm not able to calculate the probability. I mean, it's not like it was designed to be as strong as 128-bit keys, which you know you can't really crack. So I wonder if any attacks are possible because of this lower entropy, and if not, why.
Ok, there are 16 digits. That alone would provide a bit more than 50 bits of entropy, if all the digits were random. But they are not: some are fixed and define the card issuer, and there should also be some redundancy for a checksum. Also, there are a lot of valid numbers, because a lot of people have credit/debit/prepaid cards today, I guess millions of people. You just need to guess one valid code. Ok, sometimes you have to provide other data for payment as well, for example the expiration date or the CVV. Yet those don't provide a lot of entropy. There might also be additional checks (like the owner's name or address), but I'm not sure those are always enforced.
I'm not saying it's easy to buy something with a specific person's credit card in a specific online store. I'm just wondering if it's not that hard, given a large botnet, to try to guess any valid credit card data by testing it (or even actually making a purchase) on random e-commerce websites.

Guessing a valid credit card number is feasible.  Choose a known BIN (first six), generate 9 random digits, and then append the appropriate checkdigit.  That's only 1,000,000,000 combinations - high, but listing every single one is certainly doable even on a personal computer.
Checking whether your guess is actually valid is harder.  Almost every single website will ask for your expiration date and most will also ask for your CVV.  Assuming that the card in question will expire within the next four years (standard lifetime of a card), that's still 12*4 possible valid expiration dates.  And the CVV is another three digits you would need to guess.  All told, that's 10^9*(12*4)*10^3=48,000,000,000,000 combinations - much less feasible.
Additionally, you would need to spread your guesses around - throwing them all at a single merchant's website will likely get them shut down by their payment processor for permitting exactly this kind of attack.


Browser and SSL support According to http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers most browsers support SSL 3.0. And with my understanding (please correct me if I am wrong), when a browser just establishes a connection with a HTTPS server, the browser sends a list of ciphers to the server in a preferred order, servers returns the list which it supports.

I used the tool https://www.ssllabs.com/ssltest/viewMyClient.html to check different browsers, in cipher suites section I can see the list. I checked IE11, newest Chrome, newest Firefox but I don't see any ciphers begin with "SSL_" (I referenced to https://www.openssl.org/docs/apps/ciphers.html to get the TLS/SSL supported ciphers). So how can I tell that the browser supports SSL 3.0?

In the ClientHello message, the client announces its maximum supported version. Previous versions are assumed to be supported as well (in the SSL 3.0 to TLS 1.2 lineage at least; SSL 2.0 used a very different format).

Cipher suites are "backward compatible": for instance, SSL_RSA_WITH_RC4_128_SHA has value 0x0005 in SSL 3.0, and the corresponding cipher suite in TLS 1.0 (TLS_RSA_WITH_RC4_128_SHA) also has symbolic value 0x0005. Therefore, when a client says "I support up to TLS 1.1 and I know TLS_RSA_WITH_RC4_128_SHA", it also implicitly says "I can do SSL 3.0 with SSL_RSA_WITH_RC4_128_SHA". There is no method in SSL/TLS for the client to advertise version-dependent support of some cipher suites. If the client wants to enforce some specific choices, then it may do several connections, each advertising only one cipher suite, until it gets what it wants.

If you want to know if your browser would accept to use SSL 3.0, then you must try to connect to a server that knows only SSL 3.0. You can run one with the OpenSSL command-line tool. In general, one would expect that SSL 3.0 will be supported.


Security of using a single cert/key in an OpenVPN Setup Im curious about how secure a OpenVPN setup that uses a single cert/key to authenticate against the server, compared to a OpenVPN setup that uses a separate cert/key combination for each OpenVPN client.

The OpenVPN server configuration has a section that says I shouldn't be doing this, but is OpenVPN warning about potential security issues, or is the warning something OpenVPN specific?

The setup currently uses a client/server key setup along with ta.key.

There is no way of knowing who is connecting to your server.  There's no attribution associated.  If someone logs in and does something bad you'll have no way of knowing who it was, or narrow down where the security breach started.

Worse, you won't know if someone else steals the certificate, and accesses your server without your knowledge.  With attribution you can at least notice, "Well user2 rarely logs in at 0200".  Then you can follow up with the user, and narrow down the breach.

I guess the bottom line is: if you only have one client authentication certificate why have one at all?


How to investigate possible illegal access by a staff member to emails? At work we use Outlook 2010 (I think) and an exchange server.

The situation is simple: Our IT Manager (Steve) was fixing a problem one of the guys out in the field (Dave) was having with email on his phone.

The Steve did not put his own email on the phone but worked with Dave's email.

A few hours later we find out that Dave got ahold of some of Steve's emails and forwarded them to other members of the staff (both their work and personal emails).

Now my question is simply is it possible for there to have a been a glitch that accidentally sent Steve's emails to Dave's phone or would Dave have to purpose hack/put it on himself?

Anything we can say at this point is purely speculation, but based upon the information provided, I suspect the most likely explanation is inadvertent error, not malicious hacking.  Hacking is certainly possible, but it's not the first explanation I'd leap to.

For instance, maybe Steve inadvertently hooked up his email address to Dave's phone, or maybe Steve inadvertently typed his email password into Dave's phone while testing and the phone helpfully remembered it, or maybe there was some configuration error in setting up Dave's email on the Outlook server.

I definitely would not accuse Dave of hacking Steve's email based just upon the information provided here.  I would accuse Dave of poor judgement and poor ethics in forwarding Steve's emails to others and continuing to access Steve's email once Dave saw that he had access to Steve's email.

Update: Here are some additional suggestions on steps you could take to try to assess fault.

First, contact HR (and Security, if you have a Security department) immediately.  They should run the show.

Then, I would suggest you secure any logs from the Outlook Exchange you have, and analyzing them.

Third, I recommend that someone interview Dave and Steve to get their story.  For instance, I'd try to nail down the exact timing.  If Exchange keeps logs of when the email was accessed, you could then compare the timing and their stories against the timestamps in the Exchange logs.  I'd also ask Dave what he did to his phone and how he accessed Steve's emails.   I would ask Steve whether there is any chance that he might have entered his password into Dave's phone, even temporarily.  I'd also interview Steve to see if he made any configuration changes to Exchange that might have given Dave access to his email. And, I'd try to assess whether Steve has any motive to try to spin things or not (mutual dislike? bad blood?).  You probably want to have someone else (HR?) doing the interviewing.

Fourth, I recommend that you confiscate Dave's phone for examination without further delay. If it was a mistake, either Dave's phone may still have access to Steve's email, or Dave may be able to give some story about what happened that might explain why his phone no longer has access to Steve's email.

After you have assessed all the information available to you, if you're still not sure what happened, you could always consider trying an old interviewer's trick.  Have HR sit Dave down and say "Look, Dave, this is a very serious situation.  We confiscated your phone, we analyzed the logs on your phone and on the Exchange server, and we know just about everything about what happened.  The only thing we don't know is whether your actions were premeditated, or whether they were a spur-of-the-moment instance of poor judgement.  If your actions were premeditated, this a severe offense, and I may be forced to fire you.  On the other hand, if it was not pre-meditated, then that's still not good, but at least it would give me a basis for arguing on your behalf with the CEO.  So, if it was not premeditated, and if you are prepared to write out a full and complete confession right now and express remorse, I am prepared to argue for leniency in your case.  But don't try and snow me: if your confession differs in even one iota from the log information we already have, deal's off, and I'm going to be pissed.  So, what do you say, Dave?"  No guarantees that it'll work, though.


Best practices for physically securing a notebook If the user knows that other people will repeatedly have physical access to her notebook - running Linux - while she is absent, and that there is no way around this, what are best practices for protection?

The obvious one is to lock the login screen - ok. Still not sure how to protect from live CDs, live USBs and most of all, hardware modifications, such as inserting physical keyloggers in the machine.

As to this last case one can verify after it potentially happened but any creative idea on how to prevent it in first place? Maybe some special locker, tape or what-not?

This should be sufficient at least for the moderately to quite paranoid:

Change BIOS settings to boot only from the harddisk, so you can't boot from other devices. Make sure to disable network boot, which is usually in the same menu.
Set up a password for changing BIOS settings and for startup, so nobody can get past the BIOS loading screen without resetting the BIOS.
Set up automatic shut down when closing the lid (you should be able to do this in the power saving options). That way, intruders will have to go through the BIOS password prompt to get anywhere.
Encrypt the whole disk. That way, you'll have to get to the PC while unlocked or to add keyboard sniffing to access anything.

Some more outlandish suggestions:

Install a James Bond-type trigger which will be broken if someone opens up the case. Ideally, this should be detectable only by the owner, and should be easy to see.
Glue up the ports which are not used.
Fill up the insides of the computer with resin or glue, so nobody can install hardware devices there without seriously messing with it. Of course, you might run quite a risk of hardware failure if the machine contains any moving parts.


How can I validate data on RFID chip that has RSA signatures and SHA1 hash values? I have a RFID chip that has a digital signature using RSA and has data hashed using SHA1.

I would like to compare data from the chip and user input in a program but I believe in order to do that I need the public key from the RFID (which I can get) and also the signature.

Firstly is that correct, secondly, how do I get the signature? Is it a command sent to the chip?

Whether you need the signature depends on the signature type.

The main standard for RSA signatures is PKCS#1. With that standard, a RSA signature is "just a signature": it can be verified with the public key and the signed data, but it embeds no data by itself. The signature is an additional element. If you just want to compare the signed data with some user input, you can completely disregard both the signature and the public key, they are irrelevant (unless you want to make sure that the data you get from the RFID is "genuine", in which case you also want to verify the signature).

However, a RSA signature is as big as the RSA modulus, so, for a 1024-bit RSA key (a rather common key size), the signature is an additional 128 bytes. In the smartcard & RFID world, where storage space and network bandwidth are extremely scarce resources, they are quite fond of another RSA signature standard called ISO 9796-2 (the standard is not free, but you can have a reasonable description in section 2 of this article). That kind of signature uses a trick which allows for the embedding of some of the message data within the signature. You get the data back when you verify the signature. With a 1024-bit RSA key and SHA-1 as hash function, the signature can embed 106 bytes worth of data, so the size overhead implied by the signature is only 22 bytes.

So, if the signature is of type ISO 9796-2, you need both the public key and the signature to recover the complete data; otherwise, you would get only part of it (the data bytes beyond the 106 which can be embedded in the signature).

(Note: ISO 9796-2 has some weaknesses; with SHA-1 and its 160-bit output, you do not get 280 security, but something lower, closer to 261 bit operations. The article I link to above shows that this is workable with some massive but not-that-expensive hardware. If you want to use ISO 9796-2 in your own designs, I suggest that you select SHA-256, not SHA-1.)

I have no idea how you can get the signature, but it can certainly be obtained as easily as the signed data itself, because it would make very little sense otherwise.


Is it dangerous to post my MAC address publicly? When posting questions, it is often quite useful to include debug output. However, it sometimes include the MAC address of my laptop, router, or both.

What are the possible dangers of releasing these mac addresses publicly?

Disclosing the MAC address in itself shouldn't be a problem. MAC addresses are already quite predictable, easily sniffable, and any form of authentication dependent on them is inherently weak and shouldn't be relied upon.

MAC addresses are almost always only used "internally" (between you and your immediate gateway). They really don't make it to the outside world and thus cannot be used to connect back to you, locate you, or otherwise cause you any direct harm.

The disclosure can be linked to your real identity since it might be possible to track you using data collected from WiFi networks, or it can be used to falsify a device's MAC address to gain access to some service (mostly some networks) on which your MAC address is white-listed.

Personally, I wouldn't really worry about it. However, when it's not inconvenient, I usually try to redact any irrelevant information when asking for help or sharing anything.


HTTP Basic Auth is enough? I have WebSVN, Gitlab and phpMyAdmin hosted on my dev server. Now, all of it, I password protect the pages (not their individual login) using HTTP Basic Auth, is this the best practice that I can do?

If you aren't using HTTPS then this information could easily be picked up by anyone sitting between you and your server and reused.  If you are using SSL/HTTPS to encrypt the link, then you should be fine.


Does splitting RNG into "private" and "public" entropy sources reduce risks of compromise? I'm reading s2n's docs (https://github.com/awslabs/s2n) where it is claimed that:

https://github.com/awslabs/s2n#compartmentalized-random-number-generation

  The security of TLS and its associated encryption algorithms depends upon secure random number generation. s2n provides every thread with two separate random number generators. One for "public" randomly generated data that may appear in the clear, and one for "private" data that should remain secret. This approach lessens the risk of potential predictability weaknesses in random number generation algorithms from leaking information across contexts.

How does this help against common mode failures, or malicious folks subverting algorithms? Does it (having two RNGs) introduce any extra attack surfaces (especially given that actual crypto is outsourced by the s2n library to external libraries like OpenSSL)?

Let's look at how such a thing might play out:

A classic example is the Dual-EC DRBG which employees a back-doored RNG to create a general attack against TLS. The other half of this attack beyond the vulnerable RNG is a mechanism for revealing to the attacker the state of the RNG at the time of use to allow the attacker to predict the remaining "random" content as produced by the victim's RNG.

So there's a non-standard feature implemented in TLS called Extended Random, through which a TLS server just dumps a bunch of output of its RNG into the TLS negotiation, which is revealed to anyone eavesdropping on the conversation. In fact, it's been calculated that this feature improves the Dual EC attack by a factor of 64000X.

So a system which uses a different RNG for the "Extended Random" component than for key derivation would be significantly (64000x) better protected against this attack.

But not completely immune. The RNG is vulnerable in itself, even if you keep your "high-value" randomness separate. A second RNG instance is useful, but not foolproof.

The goal of such a system is to protect against the unknown, so measuring its usefulness is difficult at best. And other protections may work better.

For example, random values XORed with anything is still random. So if your application runs multiple RNGs and XORs their output, then the quality of the randomness you get is equal to highest quality of all the input RNGs. So if an application XORs a whole list of RNGs of varying quality, then if any one of the RNGs is safe, then the output will be safe as well.

So how good would this technique be in protecting against unknown threats? We don't know. But what we can say is that it would protect against known threats such as the Dual EC backdoor mentioned above.


Enforcing HTTPS Only With REST API I'm developing a REST API that may take in private information. To make it secure, I want to have the API only accessible using HTTPS. Basically, what is the best way to enforce HTTPS only?

Here are some things I was thinking for when an insecure HTTP request is made:

Set the HTTP status code to 403 Forbidden
Send the Strict-Transport-Security header
Redirect to the HTTPS URL using the Location header

I'm developing a REST API that may take in private information. To
  make it secure, I want to have the API only accessible using HTTPS.
  Basically, what is the best way to enforce HTTPS only?

If you're doing an API, the best way is to turn off HTTP and only publish an HTTPS interface.

Down-level HTTP is a crutch for puny humans.  If you're running a UI site, then you have to expect humans will try to go to the unencrypted HTTP version, because they're like that - that's why we have so many fancy ways of redirecting them.  With an API, you can demand people code to HTTPS, and simply not provide HTTP, because it isn't users with browsers specifying your address.
Puny humans at least have browsers working for them, which try to take into account all the neat things you've mentioned (status codes, headers).  When an API programmer slaps together an API client, they'll often ignore or be creative with things like that.  The 8 lines of RESTful Python they pulled off of StackExchange doesn't emphasize error handling or RFC-compliant header hewing.  You simply can't trust that they'll respond to HTTP protocol and header hints and redirections.
APIs are less likely to shove unencrypted input over your TCP if you're running HTTPS...  but it's not impossible.  (Their first packet after the 3WHS could be a data-laden JSON request instead of a TLS CLIENT_HELLO... but if they never get a response back (and they won't if they do that) they'll learn to stop sticking their finger that socket soon enough.)  The lesson here is, again, please don't trust API client programmers to do the right thing.  And never reward them ignoring encryption with a legitimate response, even a 403 Forbidden (as they might get if you support HTTP).

  Set the HTTP status code to 403 Forbidden
  Send the Strict-Transport-Security header
  Redirect to the HTTPS URL using the Location header

These are all excellent things if you have a HTTP site and want to push humans bearing browsers over.  But when dealing with an API, instead of a browser, it's a set of assumptions that are less likely to be true and less necessary in the first place.


Confused about kiosk security: am I being overly cautious? At the company I work at, they have a physical kiosk open to the public where customers can use it to upload their files to and have them processed. Customers can connect their phones, tablets, and USB drives to it and take their files off of it to put into the kiosk software. They also enter in their name, phone number, address, and other personal information into the kiosk. The kiosk software belongs to another company, and so their IT staff "remotted in" (screen shared) to the computer to install the kiosk software on a brand new installation of Windows 7.

However, I'm worried about the kiosk security. Firstly, it is connected to our internal network, even though it only just needs internet access. The kiosk runs in administrator mode, and has no password. However, the kiosk also has three anti-virus software applications installed on it, and sometimes a small message from one of the anti-virus programs appears over top the kiosk application.

I'm the "IT Guy" so I'm responsible for keeping things secure. We store financial data and customer data on company computers so I would probably be responsible for any leakage. I don't want to spend extraneous time on things that already meet a standard of security. However, I think it's extremely insecure, but I don't want to make unnecessary changes to the system.

For example, I tried to install anti-virus on an extremely ancient but very important Windows XP system on SP2 (I found out the firewall was disabled, windows defender disabled, running as administrator with no password, no updates since before 2013!) attached directly to the internet and internal network for years and years previously but got a blue screen (manager was not too happy about that.) I was able to get a ton of Windows updates installed however. In this case, I may have gone overboard with the security, and I don't want to break my already shaky trust with my manager as they appear to be very sceptical about my security suggestions as they just see blue screens and possible loss of software stability. All of the software on the Windows XP computers is 100% irreplaceable as it's 15+ years old and we don't have any way of reinstalling the software, which makes me very worried.

Is this set up common for kiosks? How secure should it be, and what steps can I take to make it more secure?

How secure should it be

Given customer input their personal data into the kiosk owned by your company, it is critical that the kiosk be hardened to be as secure as possible.

  What steps can I take to make it more secure?

Do not run the kiosk in Administrator mode unless such elevated privileges are critical to its functionality

The kiosk software currently runs in Administrator mode, which is ill-advised. Normally, systems should be run with the minimum set of privileges needed to perform its function, a concept known in IT security as Least Privilege. In this way, if an attacker were to compromise the machine, it would mitigate somewhat what he / she can do.

Implement a means to segregate the kiosk machine from your internal company network

You mention that the kiosk only needs Internet access. It is advised that you segregate this kiosk through a demilitarized zone (DMZ) and implement ACL rules through a firewall to prevent direct connections to your internal network. Any connections from the public facing Internet is by nature untrusted

Implement means to securely transmit customer data from when it is inputted into the kiosk to the destination where it will be processed.

Given the kiosk is Internet facing, if a secure method of data transmission is not used such as TLS 1.2+, sensitive customer information can be easily sniffed off the wire by attakers on the Internet.

Implement means to authenticate the user who remote logins to the kiosk.

You mention that the kiosk software is owned by a third party. Without a reliable means of authentication, you cannot trust that the individual connecting to is who he / she says they are. There should be means such as RADIUS or TACACS+ that centrally authenticates remote users. Only when their identity has being verified by the system should they be granted access.

Implement means to securely store customers information and mask information entered by the customer on screen.

Given customers enter their personal data into the kiosk, it is important that sensitive data such as SSN be masked when displayed on the screen. You did not describe the physical environment where the kiosk is located, but there could be a significant risk of leakage of customer data through  shoulder - surfing. You would also want to verify that sensitive data is securely stored by the kiosk, ideally in encrypted and or hashed format, depending on whether access to the input data is important. Use a strong encryption or hashing algorithm such as AES with a long key length to maximize protection.


Checking potentially infected photos for stegonography A friend of mine has an old family PC with a bunch of important photos on it. Unfortunately, from what he told me, it seems like they have fallen victim to a tech support scam some five years ago, during which the scammer had remote access to their machine. They haven't used this PC ever since that incident, because they were afraid that the scammer might have put some sort of malware onto their system. Since they aren't super tech-savvy, my friend asked if I could help him safely recover their photos.
My idea would be to connect his HDD to my laptop using a SATA-to-USB adapter, boot into a Linux live environment, mount the HDD there, and copy the photos to either an external HDD or to my NAS. I see one problem with this, however. I'm by no means a security professional, but form what I've learned, it's rather easy to embed a malicious payload into an image file (or at least a file that looks like an image; "steganography", "stegosploit"). So, it seems entirely possible that someone with remote access could have either copied an infected image to their hard drive, or run some sort of malware that infected their own photos. I think it's unlikely that a tech support scammer would do this sort of thing, but the last thing I want to do is recover their photos and at the same time infect their current devices with malware.
Is there a reliable way for me to check their image files for such embedded malicious payloads (ideally from a Linux system)? My best guess would be to scan these files using an AV program such as ClamAV - do you think that would be good enough? Other than that, all I found were research papers looking into methods for detecting steganography, which leads me to believe that this is still a rather difficult problem to solve...
Edit: I have played around with OpenCV a while ago, which lets you read an image file into a Numpy array. So, theoretically, I could write a Python script that reads each of their photos into a Numpy array and exports it as a completely new image file, for a more of a "sanitizing" approach, rather than a "scanning" one. Do you think this is a good idea (especially of done by someone who's not a security expert)?

Start by copying every image file on their infected device to a media card. Then on your recovery machine launch a VM running an OS that is immune to Windows malware (Linux), install ImageMagick, mount the media card, then use a script that calls ImageMacick to transform each image to PNG format. This will neutralize malware that leverages flaws in JPEG handling, while preserving the pictures. Consider stripping away all existing thumbnails contained in the original files and regenerating them from the source image.


Why do GUI terminals allow the pasting of control characters? Given that control characters are usually not rendered, but they are given a special meaning in most terminals, what reasons are there for terminal apps to continue to support copy-pasting of control characters?

One can mask a harmful code as described here for example, so that it causes issues when pasted into a terminal.

The issue that causes this is twofold:

Chrome doesn't render the ^H character, making one expect that the copied text is something different.
gnome-terminal (or xterm) dutifully accepts it from the user as if it was direct keyboard input, executing the control characters

Why does the terminal do this? Are there any use cases for being able to paste control characters (other than \t,\r,\n) into a terminal?

Terminals pre-date copy and paste. So within the terminal protocol, there is no distinction between pasting versus typing. The idea of pasting content into a terminal emulator window was retrofit into the system by simulating the rapid typing of characters when the terminal when the "paste" function is activated. This just dumps the content in exactly as it appears in the clipboard.

As for pasting control characters: the response of the terminal emulator's programmer would be something along the lines of, "Why would you even do that?"  You make a compelling argument that this could actually be an injection vulnerability in the terminal program itself.

As such, it's not out-of-the-question to suggest that programs like PuTTY and GNOME Terminal should have a setting somewhere which allows you to specify whether or not pasting of control characters is something you want to enable. Perhaps disabled by default.


How many digits of a Visa card number can vendors disclose on receipts? I visited a local McDonald's, and I noticed part of my Visa number repeated on the receipt like this: NNNN NN__ ____ NNNN. (So out of a total of 16 digits it breaks down like this: First six digits revealed, middle six digits hidden, final four digits revealed again.)

So only 6 digits were hidden. Finding the correct number would take 1.000.000 guesses, but there is also a checksum that further decreases the number of guesses needed to 100.000 (by my, possibly wrong, calculation).

Is there a policy on how many digits can be revealed? Could cards be in danger if companies hide only the six middle digits?

As per PCI, the first 6 (BIN) and the last 4 can be shown, others should be masked:

From an official 2008 PDF: PCI Data Storage Do’s and Don’ts:

  Never store the personal identification number (PIN) or PIN Block. Be
  sure to mask PAN whenever it is displayed. The first six and last four
  digits are the maximum number of digits that may be displayed.

PAN is Primary Account Number

So as far as compliance goes, the data terminal used to print the receipt is compliant.


Confused about (password) entropy There seem to be many different 'kinds' of entropy. I've come across two different concepts:

A) The XKCD example of correcthorsebatterystaple. It has 44 bits of entropy because four words randomly chosen from a list of 2048 words is 4 * log2(2048) = 44 bits of entropy. This I understand.

B) The Shannon entropy of the actual string i.e. the entropy is calculated based on frequencies of the letters/symbols. Applying the Shannon formula on correcthorsebatterystaple the result is 3.36 bits of entropy per character.

# from http://stackoverflow.com/a/2979208
import math
def entropy(string):
        "Calculates the Shannon entropy of a string"

        # get probability of chars in string
        prob = [ float(string.count(c)) / len(string) for c in dict.fromkeys(list(string)) ]

        # calculate the entropy
        entropy = - sum([ p * math.log(p) / math.log(2.0) for p in prob ])

        return entropy

print entropy('correcthorsebatterystaple')
# => 3.36385618977

Wikipedia only adds to my confusion:

  It is important to realize the difference between the entropy of a set of possible outcomes, and the entropy of a particular outcome. A single toss of a fair coin has an entropy of one bit, but a particular result (e.g. "heads") has zero entropy, since it is entirely "predictable".
  -- Wikipedia: Entropy (information theory)

I don't quite understand the distinction between the entropy of the toss (generation) and the entropy of the result (the string).

When is B used and for what purpose?
Which concept accurately reflects the entropy of the password?
Is there terminology to differentiate between the two?
True randomness could give us correctcorrectcorrectcorrect. Using
A we still have 44 bits. Using B the entropy would be the same as
that of correct. When is the difference between the two important?
If a requirement specifies that a string needs to have 20 bits of
entropy—do I use A or B to determine the entropy?

The Wikipedia article explains mathematical entropy, which isn't identical to what people mean when they talk about password entropy. Password entropy is more about how hard it is to guess a password under certain assumptions which is different from the mathematical concept of entropy.

A and B are not different concepts of password entropy, they're just using different assumptions as how a password is built.

A treats correcthorsebatterystaple as a string of English words and assumes that words are randomly selected from a collection of 2048 words. Based on these assumptions each word gives exactly 11 bits of entropy and 44 bits of entropy for correcthorsebatterystaple.

B treats correcthorsebatterystaple as a string of characters and assumes that the probability of any character to appear is the same as it is in the English language. Based on these assumptions correcthorsebatterystaple has 84 bits of entropy.

So which definition you use really depends on what assumptions you make about the password. If you assume the password is an XKCD-style password (and that each word indeed has a chance of one in 2048 to appear in the password) then A is the correct way to calculate entropy. If you don't assume the password is built as a collection of words but do assume that the probability of any character to appear to be equal to the probability of it's appearance in the English language then B is the correct way to calculate entropy.

In the real world none of these assumptions are correct. So if you have a "requirement that specifies that a string needs to have 20 bits of entropy" and this is for user generated passwords it's very difficult to give a precise definition of entropy. For more on this see Calculating password entropy?.

If, on the other hand, you can use computer generated strings (and are using a good PRNG) then each alphanumeric character (a-z, A-Z, 0-9) will give almost 6 bits of entropy.


How to know what type of encryption type is that? the hash is a lot of numbers separated by hyphens, something like that
02-35-161-51-43-227-161-06-151-43-22-71-43-46-21....
More than 700 numbers.

The numbers you have displayed so far do fall within the confines of an ASCII table, you could start there.


If I use an AWS machine to connect to "Website ABC" through VPN, will "Website ABC" know I'm connecting from an AWS machine? By my understanding of how VPN's work the answer is no because the VPN doesn't reveal the source IP is from AWS. But, I asked this question on Quora and everyone is saying they can still see the AWS source IP address. https://www.quora.com/If-an-AWS-machine-accesses-something-with-a-VPN-can-the-other-side-find-out-if-its-an-AWS-machine

For TCP/IP to work (the connection protocol the internet is built on), it MUST known a destination and source.

A VPN (it the consumer sense) alters the routing of information in such a way that there is no direct path to the requesting party (yourself) from a destination (a website).

If you access a website from a AWS machine, the destination party will know your AWS machine's IP address.

If you access a website from a AWS machine, which then tunnels its connections through a VPN, then the destination party will see the VPN's IP address.

Web Links:

What are the advantages of paying for a VPN service as opposed to hosting your own?


Is it possible to backdate the timestamp found in a .gpg file? If I sign a file right now a check the .gpg file that's generated it will output a timestamp, is it possible to change the time when signing the file?

➜  Downloads gpg --verify cache.html.gpg
gpg: Signature made Thu  9 Mar 14:27:07 2017 ACDT using RSA key ID A4DB4615
gpg: Good signature from "Tyler Bridger <xo@wvvw.me>" [ultimate]
gpg:                 aka "keybase.io/omgimalexis <omgimalexis@keybase.io>" [ultimate]

Yes, there's multiple ways you can do it:

Change the system time, sign the file, then put the time back
Run gpg inside datefudge or faketime
Use gpg's --faked-system-time option

Because of these possibilities, you can only trust the timestamp on a signature if you trust the signer to not have faked it.


Asking questions randomly from a set of questions instead of a password? I was thinking about this for a while. Say we have an app for which there is an admin console, and we need to provide access to the admin console over the browser (yes, HTTPS).

For authentication, instead of asking for a password, would the following be more secure?

Prepare a set of very uncommon questions of very very wide scope the answers to which hardly friends or family would know. And at-least it is safe to assume that no one person would know the answer to all those questions altogether. These questions can be stuff like minor stuff that happens in your life, and don't matter enough that you will tell anyone.
Store answers to these questions in a normalized form. So trim whitespace, remove punctuation etc. And hash-salt them just like you do with passwords.
On login, ask these questions in random order, (and ask only a part of the questions, so that the set is different the next time the hacker attempts to login). At the end, verify all the answers together, and if they are valid, log the user in.

I am wondering if this will be any more secure than the present methods around. If not, is there something I am missing?

Some issues with this:

Signup would take a long time. That would be a major deterrent for many websites.
Privacy, you get a lot of information about someone and if it's not something that everyone knows then obviously it's personal. It's one thing if your password table ends up on the streets, it's another when I can find out all kinds of tidbits about someone's personal life. Which brings me to the next point.
Re-use. For passwords at least you have the option to use a different one, but the answers to the questions won't change for the next site. If more websites would do this and just one gets hacked, what's preventing anyone from logging in left and right? Or even malicious administrators looking at the answers, either before hashing or after some form of bruteforce attack.


sql injection: use WHERE statement in address bar How can i use "Where" statement during an sql-injection attack in address bar ?
for example:

... from+information_schema.TABLES+where+TABLE_SCHEMA+=+XXXX--

The code above does not work.

You can retrieve the columns for a specific table with this request :

UNION SELECT GROUP_CONCAT(column_name) FROM information_schema.columns WHERE table_name = 'tablename'

Source : http://www.websec.ca/kb/sql_injection#MySQL_Tables_And_Columns