securely storing passwords that can be retrieved I'm trying to build a web application that can store passwords of other services like Facebook, Gmail ...etc.

These passwords can be later retrieved and shown to the user. This has to be a web application and has to work with modern browsers. The application cannot have the concept of a master password that can be inputted by the user. It HAS to work without any input from the user. So locally encrypting and decrypting on the device with the master password may not be a option like how the below services do it.

https://lastpass.com/how-it-works
http://dashlane.com/

Is there a secure way to do that with encryption like AES. If the server is compromised for example is there a way to protect the keys?

EDIT: In the app the user does have authentication. So the user can login and then input his credentials to other platforms. But that master password cannot be used to encrypt the keys because in the system the user can share the password with other users of this choice. In that case the other user can see the password without the master password. Hope it makes the requirement clear

In general, storing passwords in a reversible format is a bad idea.

That said, you could use AES, with the user's password as key (enforce a strong password policy). That way, users wouldn't be able to view each other's encrypted data, and a compromise of the server won't reveal the key to everyone's data without cracking the user password hashes first.

EDIT:
This only applies if your app has some sort of user authentication. If you just have an app that someone can upload data to, then it won't be secure. A SQLi attack won't get the key if you keep it outside of the DB schema, but a full compromise of the box will allow an attacker to find and use the key.


How to securely share files with other individuals? I have a collection of files I would like to securely share with a small number of other people. The collection is mostly static; no more than one or two new files will be added per month (after the initial set up). The files are mostly PDFs, videos (< 5 minutes long), and audio files. It is extremely important that these files remain private - they could be very damaging if released to a wider audience. Thus, I am willing to make it a pain to access these files if it makes leaks less likely.

I am hoping to find a solution that has some of the following attributes: (I understand I probably can't get all of them.)

Requires possession of a physical object, like a one-time-password generating dongle, as well as knowing a text password, to access the files
Possible for me to wipe the archive remotely
Archive will wipe itself after a number of incorrect attempts
Once someone has accessed the files, it's difficult for him to redistribute them
Each person I'm sharing with has their own password, so I can see who is accessing the files

Do you know of anything I could use that has the aforementioned properties? (I'm not even sure where to start looking.)

Clarifications:

I'm not worried about the police or anything; it's just that some people in my group are allowed to see these documents and some aren't. I'm worried that authorized people may inadvertently leak files, or that unauthorized people may try to break in by stealing machines or passwords to accounts like email.
Most people in the group are in one physical location
I know that it's basically impossible to truly prevent the redistribution of information, but if I could make it difficult for non-technical users, that would suffice. I'm not trying to defend against a security expert; I'm trying to defend against people who barely know what JavaScript is.

I have a collection of files I would like to securely share with a small number of other people.

Are the other people remote?  If they are in your office, the cheapest and most secure way is to go low tech.  Physically secure the machine; keep it off any network; and allow physical access only to the keyboard/mouse/screen.

That's the only way you are going to achieve all of those things.  If multiple people need access at the same time, you need multiple kiosks in the secure room.


Javascript asymmetric password-based encryption I want to code a web app that allows 2 users to send encrypted messages to each other, and I want to maximize security, so I want to minimize the amount of trust I put in my cloud provider (both the database and the server where the app code is).

So I figured I'd try to learn how to do all of the encrypting/decrypting client-side (in javascript).

But I've read various articles such as from 2013, 2011, and 2017  strongly recommending that nobody ever code anything cryptography-related in JS.

If I assume that cryptography experts' warnings about JS are correct, I have these questions:

From what I can tell, Libsodium seems to be a highly-respected cryptography library, so why would it offer a javascript version if JS is weak? (And so does Stanford, W3C, and Signal.)
Is it at all possible to develop an app like I envisioned (end-to-end encryption from client to client) without me needing to learn to code Android or iOS? (If not, then what approach gets me closest to my goal?)

I also want convenience: I want the users to be able to log into the website from any device as long as they also can provide a multi-factor auth code from their phone.

(I.e. Using the app can't require localStorage specific to one device or require uploading files of keys that are too long to memorize; users need to be able to log in just by providing credentials they've memorized.)

I'm hoping someone kind will point me in the right direction instead of just dismissing my questions with the typical "If you have to ask about security, you should leave it to the pros." I want to learn. Thanks.

The reason a javascript version is offered is because of nodejs, a server-side javascript interpreter.

It is not that javascript is not powerful enough to encrypt messages; it is that javascript (in the browser) is client-side. This means that XSS-injection or a web browser plugin could engineer your website to collect its data before the message is encrypted. The encryption itself would be useless, as the private-key would be displayed semi-publicly in the web-browser's source-code, meaning that if an individual stole this key once, they could continue to man-in-the-middle the user after the browser plug-in is uninstalled.

It is best to do all security related things on the server-side to mitigate XSS vulnerabilities, which used to be more prominent.

I think what you're looking for is an SSL certificate, which will encrypt the POST or GET data as it transfers to the server.


Naive implementation of Rainbow Table and/or Hellman's trade-off This question is the same one I asked here. Since I haven't got any response or even a comment I will post it here as well.

Is there any naive implementation of Hellman's cryptanalytic time memory tradeoff in C and/or a naive implementation of Oechslin's rainbow table algorithm in C as well?

I have seen some implementations of rainbow table but they are always focused on being fast through the usage of assembly-level operations or being designed to work on a specific platform such as CUDA or FPGAs.

Please take a look at the article - it's about naive implementation of Rainbow Tables for cracking MD5 hash function. It also has sources attached to the article. The main drawback - it's in Russian, but Yandex.Translate or Google Translate can easily cope with it.


Hacking attemps from unkown source I'm running a docker container in Kubernetes cluster running in aws, I exposed the container through LoadBalancer service and limited access to it just to my ip address using aws security groups, but I still getting GET/POST requests that seems brute forcing the endpoints of the application.
Illustration:

My question is how is this possible even I limited access just to my ip address? and how I could mitigate this issue?

These requests are coming from your private network, not from the public internet.
172.20.76.173 is part of the 172.16.0.0/12 subnet, which is dedicated for private networks.  See https://en.wikipedia.org/wiki/Private_network for more info.
Is it possible that the security policy that you created is only applied to the public interface, and not the private interface?


Command line Nessus/OpenVAS or NSE to find specific vulns? Which methods do you use to quickly scan a network for certain vulnerabilities?

I read in the O'Reilly book Network Security Tools that Nessus had the ability to test for one vulnerability only, but that it had to be done via the command line. But that was long ago, and Nessus is different now. Is this possible today, and if so, what's the correct syntax?

Is this also possible with OpenVAS? If it's not possible with either Nessus or OpenVAS in their current incarnations, would it be easier to write Nmap NSE scripts to find these vulnerabilities -- and what would be the trade-off in terms of functionality, reliability, and performance compared to Nessus/OpenVAS?

An example list of the types of vulnerabilities that I'm talking about can be found in the Pen Test Bookmarks, under the section "MSF Exploits or Easy". I'm trying to build and enhance my own version of common/easy exploits based on my own personal risk management and penetration-testing experience.

Regarding nessus:  ./bin/nasl works well, especially given the “-M” flag.

It’s pretty easy to modify existing nasl scripts or to copy and paste a single nasl script to derive a custom check.

The "-M" option is key because it enables script dependencies in cli mode.  For example, the apache_http_version.nasl script has a dependency defined, which looks like:

  $ grep dependencies ../lib/nessus/plugins/apache_http_version.nasl
    script_dependencies("http_version.nasl");

If you run a single nasl script that has dependencies without the "-M" flag, your results will be empty:

  $ sudo ./nasl  -t 10.10.10.5 ../lib/nessus/plugins/apache_http_version.nasl
    $

But, if you add the "-M" flag, then you get the below (and a working check):

  $ sudo ./nasl -M -V -t 10.10.10.5 ../lib/nessus/plugins/apache_ssl_overflow.nasl
  ----------[ Executing ping_host.nasl ]------
  ----------[ Finished ping_host.nasl ]------
  ----------[ Executing http_version.nasl ]------
  ----------[ Finished http_version.nasl ]------
  [...]


selft signed certificate for AES128-GCM-SHA256 cipher To generate self signed certificate for AES128-SHA256 cipher using openssl, following commands are used.

AES128-SHA256 cipher commands :-

 openssl genrsa -aes128 -out 1.key 2048
 openssl req -config csr.conf-new -key 1.key -out 1.csr
 cp -f 1.key orig.1.key
 openssl rsa -in orig.1.key -out 1.key
 openssl x509 -req -sha256 -in 1.csr -signkey 1.key -out 1.crt
 openssl x509 -inform PEM -in 1.crt -outform DER -out rsacert.der

Can anyone help to know parameters to generate self signed certificate for AES128-GCM-SHA256 cipher suite certificate which I can test using openssl s_server and s_client?

AES128-GCM-SHA256 and AES128-SHA256 both use RSA certificates for authentication and key exchange. They only differ in the symmetric cipher and MAC used - which are independent of the certificate. This means that you can use the same
RSA certificate with both ciphers, i.e. there are no changes needed in certificate creation specific to  AES128-GCM-SHA256 compared to AES128-SHA256.

Note also, that the algorithm you have specified to protect the private key (i.e. genrsa -aes128) has nothing to do with the cipher used in the TLS connection. Similar the signature algorithm you have specified for the certificate (x509 req -sha256) has nothing to do with the cipher used. The meaning of AES128 and SHA256 in AES128-SHA256  is instead that AES128 is used as the symmetric algorithm to encrypt the traffic (not the private key) while SHA256 is used as MAC for integrity checks on the traffic (and not as signature algorithm on the certificate).


Hardware / firmware backdoors : TPM as a security risk - How to turn it into security advantage? --- Question:
What are the exact risks of using TPM 2.0 or owning this integrated chip? In what circumstances?

What are the solutions to minimize risks?

Details:
My primary goal was to try to find out, how could deeper level backdoors compromise nowadays disk/messaging "encryption" practices, and how to solve them.

I found the well known article where the German government practically says, that having windows 8/10 with TPM 2.0 is probably acceptable for the average customers but otherwise its not recommended for Federal use, because it is a potential source of backdoor.
Now after that the Wannacry defeated their whole railway system, exploiting an already known, but intentionally undisclosed Win security hole, their worries seem to be legit.
But other firmware security developers like Guido Stepken (also in Germany) say if the computer is bought with preinstalled Win, the Endorsement Key is already signed by US authorities, than its practically enforcable by US law to insert any backdoor into MS products, or provide these keys, and then of course anyone with knowledge can practically have control over any machine (there were several successful attacks demonstrated too).

In this case, its not enough to wipe the hdd/ssd, and install a Linux distro, and ignore propriatery firmware installs (which may also be a risk).
The next what we can do is to disable TPM and UEFI - how can we trust than that it really happens?
This leaves the system more vulnerable to attack, therefore we need to find a way to make Linux work with UEFI - can it be trusted in a previously Win certified machine?
Can we secure the system so the data is not tied to the TPM? (data loss due to physical error.

I searched for a few days, and I didn't find any clear answer, most of the articles are either infinitely paranoid or simply ignore the risk side, or MS advertisement. I need a rational balance between.

If I'm not exact enough, or you need sources, I react upon demand.
Thanks for the effort, trying to reply.

While we aim tech to solve all problems for us, in security, trust is an important contributing factor.

So the short answer is: When hardware, firmware (and why not chip-level?) backdoors are part of your threat model, TPM is just not good enough.

I'm skipping a longer answer coz your question already includes the scenarios to justify this answer. :)

It is a problem mainly because it is designed to inspire trust and thus lower your guard. In practice (as commented by @eckes) other risks are much bigger.

Edit based on the comments:
Scenario: We can't trust signed updates by Microsoft (or any other OS publisher.

Yes TPM can be used to "sign our own bootloader" to counter the problem. As you already pointed out ("ignore the fact that..."), we need to assume trust of already installed components or accept the risk as you have pointed out ("ignore the fact of...").

IMHO, when you don't trust a vendor, you can't use any of the components (not just those protected by the TPM) supplied by that vendor without extensive verification. Further, you have to disable updates, or subject every update to the same level of verification.


Keyboard sniffing through audio recorded typing patterns I've been thinking about this for a while; I know people are aware of wireless wiretapping of keyboards. However, has there been research on how to wiretap keyboards based on typing patterns? I'm thinking whether microphones can be used to build a model of typing patterns to extrapolate what someone is typing on a keyboard.

In a similar vein, but slightly different.  Rather than using audio recordings this link shows that you can point a laser at the back of a laptop monitor and determine what is being typed based on the vibrations of the screen.

Here is the original presentation slides


Outbound Port 443 Open but Not Allowing SSH My college wireless network has a firewall blocking all outbound ports except 443 and 80. The wired network, however, has none of these restrictions.

I can connect to HTTPS sites (obviously). On my server host, I forwarded port 443 and wrote an IPTables rule to redirect it to 22.

From home I can connect as well as using 3g/4g and on the wired college network. I can SSH into the machine on port 443. However, when I am in the wireless network, I cannot.

I will be trying an SSH over SSL tunnel, and though it would solve problems on, say, a laptop,  I'm not sure if I'll be able to make the proper configurations on my phone.

My theory is that there is DPI or some kind of filtration other than just outbound ports. Thanks guys!

Most likely they are using Deep Packet Inspection. There is a tool called stunnel that allows you to encapsulate any protocol over SSL/TLS. I would have to warn you against using this to bypass your schools filters though, as you would likely be breaking policy or contract which could result in legal or academic punishment.

It is cool tech so I think it deserves a mention. As always, don't be stupid.


NTML2 Session Response and Browsers I've been looking at the NTML2 Session Response which is apparently supported transparently by commonly used browsers.  NOTE: This is not to be confused with full NTLMv2 authentication.  This in-depth and detailed explanation describes the core process.

The upshot: this scheme is known to be subject to offline dictionary attacks as discussed in this presentation from 2004.  One of the main issues is that it creates a MD4 hash of two bytes which means you can compute the 65536 possible results for that part of the response for any given challenge and client nonce and rule out (generally) 65535 out of 65536 passwords by doing just the MD4 hash.

What I find really surprising is that Chrome is 'willing' to engage in this scheme (IE: not surprised).  Disabling this option on a given server manageable but that doesn't prevent people from setting up simple web pages that will silently negotiate with the browser to send the insecure response.  Am I wrong to think this it's irresponsible to make this the default behavior?  Shouldn't this be opt-in given the risks and how esoteric this is?

On a side note, if anyone has any reference on what rate of MD4 generation is achievable, please respond.  I can find things for MD5 but I believe MD4 is easier.

Sending your logged in user credentials (SSO) is limited only to the intranet zone. http based NTLM authentication is widely used inside corporate networks and is not considered a security risk unless an attacker managed to get a foothold inside your network. (which will happen)

By default the intranet zone is defined by anything that's in the same subnet as you, the same DNS suffix as you, local proxy exclusions or anything that you manually defined.

This is still a good attack vector to gain credentials assuming you managed to get into the corporate network, and i've used it many times when pentesting networks. (for NTLM reflection/relay, or just as to brute force the password)


Do spaces in a passphrase really add any more security/entropy? I often see passphrase suggestions written as a sentence, with spaces. In that format are they more susceptible to a dictionary attack because each word is on it's own as opposed to a large unbroken 20+ character 'blob'?

No (with a minor exception at the bottom).

The passphrases "correct horse battery staple" and "correcthorsebatterystaple" are equivalent entropy-wise.  Choosing to put spaces in an incorrect spot or sometimes including spaces and sometimes not including spaces will give you a few extra bits of entropy; but its not worth it for the extra difficulty remembering it.  You'd gain a few bits of entropy for the entire passphrase for weird spacing pattern; while just adding another word would add about 13 bits (assuming a diceware dictionary of 7776 words corresponding to 5 rolls of a six-sided dice; note that lg(65) = 12.92; lg being the base-2 logarithm).  (There's no disagreement between my answer and Thomas's; an attacker would have to check for passphrases both with and without spaces unless he had extra information about whether you tended to use spaces in your passphrases).

Beware the distinction between random words and meaningful sentences.  A passphrase "quantum mechanics is strange" is much lower entropy than say "heat fudge scott canopy"?  Why?  In meaningful English you have patterns like certain words combine frequently (quantum mechanics) or certain patterns must appear to be grammatically correct (subject, predicate, subject complement) that in principle could be exploited by a sufficiently sophisticated attacker (even though I am not aware of any cracking algorithms that currently utilize this).  The informational entropy of grammatically correct written English is about 1 bit per character so the first passphrase has ~30 bits [1], while the second passphrase has about 4×12.9 ≅ 52 bits of entropy; so would take about 222≅4 million times longer to crack.

Be wary of incorrect analyses like http://www.baekdal.com/insights/password-security-usability that make many fundamental information theory mistakes.  E.g., "this is fun" is incredibly weak being comprised of some of the most common English words in a syntatically correct sentence that is very common ('this' ~ 23rd most common; 'is' ~ 7th most common; 'fun' ~ 856th most common word) [2].  If you tested just three random words from the top 1000 english words, it would take you only 1 second to crack it, assuming a modern GPU and you have acquired the (salted) hash.  This is roughly equivalent to a 5 random alphanumeric characters (not counting special symbols).  If you search google for the quoted phrase "this is fun" it appears 228 million times.

EDIT: Minor exception: in the rare case when consecutive words in your passphrase form another word in your dictionary (or your attacker's dictionary), then not having spaces (or another separator) between words lowers your passphrase's entropy significantly.  For example, if the random words forming your passphrase were "book case the rapist" and you had no spaces, an attacker could get in by trying  all combinations of just two words 'bookcase therapist'.


OpenPGP.js deterministic encryption? I'm encrypting something with a public key generated using the ed25519 curve, with OpenPGP.js. It goes something like this:

var options = {
    data: str,
    publicKeys: publicKeys,
    armor: false
};

openpgp.encrypt(options).then(function(ciphertext) {
    var bytes = ciphertext.message.packets.write();
});

From what I can observe, the output is deterministic -- i.e. it's the same output every time without a random component.
I'm exploiting this fact in my database design, and thus I need it to always be deterministic.

Is this something I can assume? Is this documented anywhere? Is it a correct behaviour for OpenPGP?

I'm kind of in doubt now because this post specifies that it should have a random component: Will encrypting the same file with GnuPG and the same key produce the same ciphertext?

It should have a random component. The way encryption with asymmetric keys usually works is that you generate random AES key, encrypt the data using AES and then encrypt the random key with your asymmetric key. This is done for performance reasons. However, because the key is random each time, the resulting cipher-text should be different each time. I am not sure why it is not in your case.


eBay web site tries to connect to wss://localhost:xxxxx - is this legit or they have some Malware JS running? In helping a corporate user log on to eBay, I noticed that when on the login page, a stream of errors were coming up in the Firefox JS Console about not being able to connect to wss://localhost. This is a bit concerning, obviously. Why would a web site need to connect to a web server running locally.

In looking further, I found that this request comes from check.js at this URL:

https://src.ebay-us.com/fp/check.js?org_id=usllpic0&session_id=586308251720aad9263fb1e7fffd7373

Is this some malicious script injected into eBay or do they have a legitimate reason for doing that? Anybody knows?

This is ebay running a local port scan over websockets. It has been reported recently:

https://twitter.com/JackRhysider/status/1264415919691841536 (original research)
https://www.bleepingcomputer.com/news/security/ebay-port-scans-visitors-computers-for-remote-access-programs/ (bleeping computer article)

I don't think it's malicious, but it is bad practice, it's sneaky and erodes user trust. They do it before you accept any T&Cs of any kind allowing probing into your own computer.

Similar tactics are used by banks in more or less open ways (it varies).


How dangerous is storing the hashed password in local storage? I'm looking at a web application that does something I find very unusual in the handling of login sessions.

The application hashes the password with SHA256 and salt and saves it either in session storage or in local storage in the browser (depending on if the user wants to stay logged in permanently). It also uses a proper hashing for passwords again on the server side (PBKDF2) and the application is served via HTTPS.

This approach seems more dangerous than storing a random value for identifying a user session, but I have some trouble to think of ways to attack this that actually pose a serious danger. There is the potential that someone that gets access to this value could brute force the password, but an attacker that gets to that point can already cause serious damage and probably get the password in other ways as well. To convince people to change this I probably need better arguments than this.

What specific disadvantages has this approach compared to the typical approaches for session storage?

It's really dangerous.

The use of the local storage to store session identifiers is never recommended as the data is always accessible by JavaScript.

Please use Cookies to mitigate this risk using the httpOnly flag.

A single XSS (Cross Site Scripting) attack will be able to steal all the data in these objects and/or load malicious information, so don't consider the "local storage" to be trusted and less for a session identifier/hashed password.

Ref: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage


What does the letter in an OpenPGP key's bits definition (like 4096D) denote? I noticed that when looking at OpenPGP keys on a key server, the key's bits definition is usually followed by a letter, as in "4096D" for example. However, there are also keys with other letters than D, for example here are two keys with "D" and one with "R". There are also keys postfixed with a "g" , as seen here. What does that letter mean and how can I find out what is correct for my own key without uploading it to a keyserver?

I'm using GnuPG/MacGPG2 v2.0.

It indicates whether the key is DSA or RSA.  You can read more about the differences between the two here.

You can determine which type your key is using gpg --list-keys at the CLI.  I'm not sure what GUI you'd use on a Mac so I can't speak to that.

C:\>gpg --list-keys
--------------------------------
pub   4096R/2C55AF0B 2014-10-28 [expires: 2017-10-27]
uid                  Gowen Fawr (gowenfawr) <gowenfawr@example.com>
sub   4096R/6ADD2CE0 2014-10-28 [expires: 2017-10-27]


Cryptography - Perfect Secrecy Assuming you have a block cipher that (when given a 128-bit key) yields an instance of a true pseudorandom permutation... how can you use that block cipher within the above constraints to achieve practically perfect secrecy?

"Secrecy" depends on the context. Secrecy of what, where, when, against who ?

If you have an ideal block cipher, then you can use it in a mode of operation which turns it into an encryption system for data messages of arbitrary length. If the block cipher is ideal (there is no way to distinguish the block cipher from a randomly selected permutation that is easier than trying all possible keys), and the blocks are large enough, then encryption will ensure confidentiality up to the exhaustive search effort.

Note the subtle points, though:

Most block cipher modes require an IV with some mode-dependent requirements. For instance, CBC requires a uniformly random unpredictable IV. Some other modes are less strict and need only a non-repeating IV (e.g. a message counter suffices).
Encryption does not include integrity. However, some modes include an integrity check, which is a good idea (e.g. GCM).
Depending on the mode, it may be possible to leak information upon decryption; CBC in particular got attacked many times (see padding oracles). There again, modes with integrity checks like GCM tend to fare better.
Encryption hides data contents, not data length. Length can leak information, in particular when used with compression (because compression makes data length depend on data contents).
Encryption does not create secrecy, it just moves it around. With encryption, you can reduce the problem of keeping gigabytes of data confidential, into the problem of keeping a single 128-bit key confidential. Supposedly, the latter is easier than the former, but you still have to do something (that's called "key management").


Can anyone tell me at this platform that what is the difference between filtered ports and blocked ports? please help me out, I am confused in this.

Upon closing a port, nmap reports it "closed".
When it reports it "filtered" it means that it is behind a firewall or other security control so nmap cannot resolve the port and reports it filtered. It can be open behind the firewall but from your network, it is behaving as a closed one.


Is it feasible to make an IMEI sniffer the size of a matchbox within EU legislation? I want to produce a list over the GSM phones in an area. I don't care about what data goes back and forth, neither are the various conversations relevant.

Most phones have IMEI (International Mobile Equipment Identity), this could serve as an identifier.

Given the fact that phones will operate on different frequencies, is it even feasible with a relatively small unit to sniff the GSM meta data in an area of approximately 30 meters?

I would like to perform this within EU legislation but without the explicit support from any network operator.

This is certainly possible. And many such devices do exist.

Whether this is legal is not a question for this site, but I would strongly suggest talking to a lawyer in your area who deals with this type of law. There's a really, really strong possibility that local laws prohibit exactly what you're talking about.

In particular, the simplest technique is to transmit a strong enough signal to cause nearby phones to temporarily disconnect from their towers and attempt to communicate with you. If your device can do this on GSM frequencies, then it almost certainly runs afoul of local communication laws, since your device will not have a license to do so. Though exceptions for experimentation with devices you build yourself may exist in your locality.

It may be possible to discover IMEI numbers through passive-only sniffing, which would mean a much smaller build, less power, and less legal complication. I would recommend pouring over the GSM specification to see if this is possible.

You'll need to read it sooner or later if you intend to build this device. Might as well read it now.


Is a biometric eye scan more secure than a multi-factor authentication I have come across the following question in a Security+ exam guide

  You are tasked with creating a high-security authentication system for physical access control to a military installation. Which of the following authentication systems would be most appropriate?

Biometric eye scan
Security badge
Smart card and PIN
Encrypted login and password

The answer at the end of the chapter was:

  For high-security installations, biometrics is an extremely secure method to authenticate users based on unique physical characteristics.

My question is

How is it possible the answer was not number 3?

Bad guys will have to steal the smart card and somehow get the PIN from the authorized personal which is TWO jobs

while in a biometric eye scan they have to do ONE job

Biometrics can be effective as authentication or as identification, but not both at the same time.

According to Wikipedia, retinal scans are accurate to approximately one in one million, meaning on the earth today there are approximately 7,000 individuals who will be identified as you in a retinal scan. Assuming no further authentication is necessary, these people will be both identified and authenticated as you in a single (mis-)step.

But if coupled with an external identification step, biometric authentication becomes a second factor. Typically identification is accomplished by an identification badge ("something you have") while authentication happens through biometrics ("something you are"). So it does turn out to  be true two-factor authentication.

This is inherently better than card-and-pin because of the three available factors, "something you know" is the easiest to fake.

So assuming identification happens using a token of some sort (which is very typical in biometric authentication installations, but not explicitly stated here), then the question is poorly-worded but has at least the right idea. Assuming instead that the eye-scan stands alone as both identification and authentication, then answer 3 would be correct.

Either way, the question could use some clarification. It refers to authentication alone without even a word about identification; but that's an absolutely critical factor in evaluating the security of the system and definitely makes a difference here. It's left to the reader to divine the contents of the question-writer's head, which is poor form in writing standardized tests.


Reverse a key diversification algorithm What are the possible ways of reversing a key diversification algorithm? This is used to generate a different key for each user.

I know the operands involved (three 4 bytes values) and the result (the key, also 4 bytes long), but I don't know the function that given the operands generates the key.

I have read something about MIFARE key diversification but my case is different and it should be easier:

I know there is no master/secret key involved and that the final key is based only on these 3 values I have so I just miss the arithmetic/logical operations between these values.

Any suggeston?

You are essentially asking if it is easy to reverse engineer the function which is used to map 96 bits (3x4 bytes) input to 32 bit (1x4 bytes) output, without having any further information about this function.

Given of how many different functions exist which do such a mapping I don't think this is possible. You might try to make some guesses for trivial combinations of various hash functions, shifting, XORing or similar but if anything more complex is involved this black box approach with not having any information about the internals will fail.


Planning Incident Response / Business Continuity An IT company has already most of the standard procedures / precautions in place to do day-to-day business in a secure way e.g. policies for users what to do and what not to do, technical solutions like antivirus / spam protection / log management / .... There are also plans to restore systems and what service has which dependencies etc. for when something really goes south (either because of an attack or simple system errors) and plans how to deal with “normal” incidents like fire in the datacenter, virus infection of server / clients, total fail of service X. Now I want to prepare for a big fallout like the compromise of multiple systems and services with no clear understanding where the breach is and how the attacker could gain access and likely no clue what systems are compromised.

Question(s): How would somebody prepare for an incident that is not predictable? Are there templates someone could create to help guide through the (unknown) situation? How to take care of the (naturally) occurring panic that such an incident would cause? Should management get guidelines what to do or have a say in this situation at all (in my experience they don’t really understand what’s going on, are not helpful and are only concerned with identifying who to blame)? Is all hope lost in such a situation and should an external service provider be called to deal with the situation? The main problem here is that I can’t produce a step-by-step manual for a situation that is not predictable. Also a problem is that one team can’t check what systems are possibly compromised due to separation of power and restricted rights and I don't know which teams to call when nobody can tell which systems are affected.

Note: There is no incident response team or dedicated security analysis team in place. The only ones who really know the infrastructure and how their systems work are the people who do the standard workload e.g. windows team, linux team, vmware team, storage team, network team, … and for most of the teams there is 24/7 standby.

This is a difficult question.  To write proper incident response procedures you will probably want to consult with someone who does this as their full time job.  They will be able to guide you through the creation of procedures for your business, by taking into account your level of tolerable risk, assets (company name, etc.), legal/regulatory exposure, and many other factors.

At the moment I wouldn't say that you should hire someone in case of a breach, rather hire someone before it happens to put together your plan.  And yes, while it may be expensive, think of it like an insurance plan.  This is what you're going to do when the company is in deep crisis.


Session Fixation using XSS What are the precondition for performing session fixation attack using XSS?

i.e., in which parameter should the script be injected so that it sets the cookie in browser.

Know condition: Pre and Post login the session Id remains same.

Precondition for Session Fixation via XSS

The precondition is as you mentioned that the session id does not change on login, as otherwise session fixation does not work.

Additionally, the session cookie must either not be httpOnly (as you couldn't overwrite it from JavaScript) or not exist yet (ie the user is not currently logged in).

Alternative Attacks

Why would you want to perform session fixation via XSS? For it to work, the victim must enter their login credentials so that the fixated session id is associated with their account.

You could just as well read out the entered password. Now you have full access to the application (not just temporary access), session restrictions do not apply (bound to IP or useragent for example), and it doesn't matter if the session id is regenerated on login.


Privacy risks of entering contact information in forms that use Google APIs A lot of websites use ajax.googleapis.com. Some also use it for forms. As filling forms often entails entering personal information, I'm wondering whether there is a risk of that information being readable to Google.

For example, when ordering product online, I have to enter a shipping address and other contact information. Does Google now have my address?

I'm of course hoping that this is all implemented as javascript being loaded from Google's servers once, without any further interaction with Google. I.e., once loaded, I'd hope that the code only runs locally in my browser and only sends the entered data to the owner of the website, not to Google.

Related question, but from the perspective of a website designer: Privacy risk in using Google APIs

Yes, Google could run a different script than the one the site creator intended, and it's not hard to have a script send off entered information. However, the reaction upon getting "busted" doing that would be pretty severe among developers, and probably lawyers as well. There are terms and conditions, and contracts are to be followed by both parties. There is little incentive for Google to capture info they likely already have, so this is probably not a realistic concern.

You can see all the script's activity in the developer tools, including in non-chrome browsers. I suppose Google could engineer chrome in a way to cover up what script was loaded, as well as hide the ex-filtration http request, but we're getting really tin-hatty here, and there's other tools like wireshark that would ensnare them. In short, it's simply not possible to do this perfectly, nor worth it for them to do this in general.

If in doubt, and doubt is healthy, use the integrity attribute on CDN resources to prevent this exact scenario in supporting browsers (~60% at time of writing).

EDIT:
There is a hidden privacy consideration here. It's not the info being entered, but everything else Google can tell by you using such a service:

Who - Which user is loading the script (IP)
What - What script; something for validating forms, watching vids, etc (script url)
When - What time was the script loaded
Where - What site/section/page is the user on (refferer)
Why - Google's a pioneer in deep learning  ;)

If you self-host the script, google gets none of that, and thus your users gain a little privacy.


Where is the version number in an x509 version 1 certificate? I'm parsing x509, versions 1 and 3.  I found the version field in the v3 cert, but I have two v1 certs (one from my organization, one I generated via OpenSSL) and in both of these the first non-sequence field is the serial number integer:

    > openssl asn1parse -in ca.der -inform DER
    0:d=0  hl=4 l= 645 cons: SEQUENCE
    4:d=1  hl=4 l= 494 cons: SEQUENCE
    8:d=2  hl=2 l=   9 prim: INTEGER           :B7D50AE5F7DB09FD
    .
    .
    .

The reason I'm confused is that the wording in RFC 1422 seems to quite clearly suggest that the version is an actual field and that it is the first field, before the serial number:

  3.3  Certificate Definition

   Certificates are central to the key management architecture for X.509
   and PEM.  This section provides an overview of the syntax and a
   description of the semantics of certificates.  Appendix A includes
   the ASN.1 syntax for certificates.   A certificate includes the
   following contents:

       1.  version

       2.  serial number

       3.  signature (algorithm ID and parameters)

       4.  issuer name

       5.  validity period

       6.  subject name

       7.  subject public key (and associated algorithm ID)

   3.3.1  Version Number

   The version number field is intended to facilitate orderly changes in
   certificate formats over time.  The initial version number for
   certificates used in PEM is the X.509 default which has a value of
   zero (0), indicating the 1988 version.  PEM implementations are
   encouraged to accept later versions as they are endorsed by
   CCITT/ISO.
   .
   .
   .

I'm looking at RFC 1422 because wikipedia says:

  "The structure of version 1 is given in RFC 1422."

My expectation is to find an integer field of length 1 with value 0x00 before the serial number in a v1 cert.

Is version 0x00 (v1) just implicit? That is, will there only be a version field if version > 0x00?  What does this mean for the version field description in RFC?

Short answer: The RFC (1422) mentioned by Wikipedia is not correct. Not only is the format mentioned in an earlier RFC (1114), but that RFC correctly references the ITU document which does have the original description: the 11/1988 version of the X.509, available here. In section 8.7(c) of that document, it is stated that "if the value of a type is its default value, it shall be absent." Therefore, a version 1 cert is the default version, and should not be included in the cert that is signed.

Longer answer, with a bit of explanation:

The newer X.509 specification (which is not in an RFC, but the ITU document is not freely available) that relates to public key certificates is most recently documented in RFC 5280. Here's a part of section 4.1, which covers the ASN.1 encoding:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         -- If present, version MUST be v3
    }

Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

Two parts of this notation that refer explicitly to versioning are the version tag itself, and the issuerUniqueID, subjectUniqueID, and extensions sections. The version tag says that the default is v1, and the original spec said that defaults should be absent. When the later revisions of X.509 added versions, those new versions were no longer default, and did appear in the signed cert.

Although you can use this newer specification to generate a version 1 pubkey cert, there's really no need. You can label a new cert with the version 3 tag (using the integer 2), and just choose not to use any of the new sections.

The new spec is backwards compatible with the original. ASN.1 is used for encoding in all of these cert revisions. ASN.1 is very compact, and mostly relies on the defined format of a structure to determine what any given field means. That is, what you see with all of the "::=" syntax is a definition that you follow when parsing the blob of data you get. The first field listed in the TBSCertificate sequence is the version, which is an integer. The next field is the serialNumber, which is also an integer. If the version field is missing, which it may be if the cert is a version 1, it could be really difficult to know that the serialNumber is not the version. (It is possible--and likely, with CA certs--that the serial number is a single digit number.) The way around this--which is used in the specification shown here--is to use DER tagging. If the version tag is present, it is tagged using DER tag "[0]." The serialNumber is not tagged, so if you encounter an integer without a DER tag, you know that it is probably a version 1 cert. (It's also possible that you just have an incorrectly formatted cert--look at enough certs, and you will find all sorts of ASN.1 formatting mistakes.)

Version 1 certs don't have any of the other sections marked with DER tags, but version 3 certs (the version you will encounter most often on the internet) don't have to include any or all of those sections either. To know which, if any, of the sections are present, you look at the DER tags. Most version 3 certs will have extensions, but not issuerUniqueID or subjectUniqueID. In those certs, you will see the [0] tag for version, 1 and [2] for subject and issuer uniqueIDs, and [3] tag for extensions. Many version 3 certs you encounter don't have uniqueID sections, so the [3] tag immediately following the subjectPublicKeyInfo is the indication that the extensions are next to be parsed.

You will not encounter many version 2 certificates. Because X.509 and ASN.1 isn't confusing enough, there is an X.509 specification for "attribute" certificates--a different kind of certificate which does not contain a public key and follows a different format (with similar fields in a different order)--which are always labeled as version 2 by definition. See RFC 5755 for more information, and the format, for attribute certs.


How do I prevent users from modifying resources they do not own? I am writing a server where I have an entity StoreOwner that "owns" or has a @OneToMany relationship to a Store entity (one store owner has 1 to N stores). Each Store has Offer and Item, each also have a @OneToMany relationship with the store (one store has 1 to N offers and 1 to N items).

I am already using GWT Xsrf protection and a session ID that gets associated with the logged in user after each log-in (cookie).

There's one thing missing IMHO: what if a logged in user sends a delete request to the server with IDs of items that he does not own of a store he does not own either? At the moment, I am doing this in my StoreService:

// StoreService.java

@Transactional
public ItemDTO deleteItem(String sessionId, Long storeId, ItemDTO itemDto) {

    // sessionId is the cookie I have placed in my database
    // This way I want to ensure that I am only accessing a store
    // that is associated with the logged in store owner (the user basically)
    Store store = this.storeOwnerRepository.getStore(sessionId, storeId);

    Item item = ConvertDTO.convertItem(store, itemDto);

    // Check if the store ID that I got using the cookie is the
    // same ID as the store ID from the item that should be deleted
    if(item .getStore().getId() == store.getId()) {
        item = this.storeOwnerRepository.deleteItem(item);
    } else {
        // If this didn't work we have a potentially hostile user:
        throw new RuntimeException("Is somebody trying to delete items of a store he doesn't own?");
    }

    itemDto = ConvertEntity.convertItem(item);
    return itemDto;
}

It is the first time that I am trying to write a bigger server application and I want to prevent users from doing such things.

My question is twofold: [1] does what I am doing would really prevent a logged in user from smuggling the IDs of another store he does not own to my server? In addition, [2] can I simplify this a little bit?

My problem is that as the application grows one might - every now and then - forget this check

if(item .getStore().getId() == store.getId()) { /* .. */ }

Of course, I could move that into my StoreOwnerRepository, but do I have better options?

This is called Access Control.

You need to check that a user has access to a record before performing an operation on it.

The simplest method would be to use a different database or schema per tenant. Or...

As you use Java, you could use Spring Security. It now integrates with Spring Data JPA, allowing you to pass in the userid/username into your SQL queries easily.

Or use Row Security right in the database. Oracle if you have $10M to spare, or this will be available for PostgreSQL in October. You can mimic it with updateable security_barrier CHECK OPTION views as of PG 9.4. For this you'd have to have the web server tell the db server the name of the current user.

You probably want to add an owner_id column to your "child" tables. Use an on update cascade foreign key to the parent table.


Recreating uploads/linked images with imagecreatefrom* php As suggested on my StackOverflow question, I am now directing this towards the Information Security group, since no one was able to answer my question despite multiple up-votes.

User uploaded images account for a large portion of the content on the site I'm working on. I tried storing them outside of the webroot and fetching them with readfile() for security reasons, but it was just too slow so I had to go back to the old method.

Now I'm looking to make sure all uploads are 100% sanitized since they'll be stored inside the webroot. My question is, if a user were to rename a harmful script to a .jpg, .gif, .png, or .bmp and uploaded it, would it still be harmful when executed or fetched if the image was recreated with a function like this:

function imageCreateFromAny($filepath) {
    $type = exif_imagetype($filepath); // [] if you don't have exif you could use getImageSize()
    $allowedTypes = array(
        1,  // [] gif
        2,  // [] jpg
        3,  // [] png
        6   // [] bmp
    );
    if (!in_array($type, $allowedTypes)) {
        return false;
    }
    switch ($type) {
        case 1 :
            $im = imageCreateFromGif($filepath);
        break;
        case 2 :
            $im = imageCreateFromJpeg($filepath);
        break;
        case 3 :
            $im = imageCreateFromPng($filepath);
        break;
        case 6 :
            $im = imageCreateFromBmp($filepath);
        break;
    }
    return $im;
}

In other words, is there anyway to trick one of the imagecreatefrom* functions into executing content as a script instead of an image or would even a harmful script that's been run through this be reduced to a broken image?

Update
I will also be checking file types and extensions, but I wanted to know if the user managed to bypass those, would this last resort help in protecting my server and/or clients in any way. Thank you.

would even a harmful script that's been run through this be reduced to a broken image?

No, any harmful code in the image is still there.

But if it's secure really depends on what you do with the output of imageCreateFromAny.

On its own, imageCreateFromX doesn't do anything to the image. It doesn't recreate it, it just creates an image resource identifier, so if you want, you could further change the image. But any harmful code inside the image is preserved.

Your exif_imagetype check can easily be bypassed, so it doesn't ensure that the image doesn't contain harmful code.

So if you do not check the file extension, and you use your function eg like this: imagepng(imageCreateFromAny($imageName), $imageName);, then that would be insecure.

  is there anyway to trick one of the imagecreatefrom* functions into executing content as a script

Lets hope not. That would not be a vulnerability in your code, but a vulnerability in PHP itself.

So what is the solution then? How can you make sure that the uploaded image doesn't contain any harmful code? Two ideas come to mind:

As @Steffen Ullrich says here, you can transform the image to a different format, which will most certainly destroy any harmful content
You can search inside the file itself for harmful content. It should be possible to exclude images containing PHP code by excluding <?, <%,  and <script (case insensitive) this way.


Rogue TCP packets and SSL implict sequence numbers I would like to understand how does the SSL implicit sequence number helps SSL in detecting rogue TCP packets?

In fact, the RFC 6101 states :

  sequence numbers:  Each party maintains separate sequence numbers for
        transmitted and received messages for each connection.  When a
        party sends or receives a change cipher spec message, the
        appropriate sequence number is set to zero.  Sequence numbers are
        of type uint64 and may not exceed 2^64-1.

Could not an attacker take advantage of the pre-knowledge of how SSL sequence numbers behave to conduct a successful attack?

I don't know what you consider a "rouge" TCP packet. But, there are two major attack vectors to consider:

Modification of an existing packet or insertion of a bogus packet: this is detected by validating the MAC of the record.
Replay of a previous packet: the recipient knows which sequence number to expect. This sequence number is when computing the MAC. When replaying an older packet the sequence number used in the MAC of the older packet will not match the one used to compute the MAC of the new packet and thus the MAC will differ.


Exposing different services on the same port My current project contains multiple heterogeneous TCP servers, but our IT guys have clearly declared that they will give me only one 443 port, which is fair enough.
Two options are on the table now.  One is VPN.  We can set up a VPN server inside our cooperation and implement the access control.  The other one is to implement some kind of software switch, which peeks the recognizable features of any [S] packet and then route the connection to responsible service.  Our IT guys are neutral to both approaches for now before any evidence shows that one is superior than the other.
The pros of VPN are that it is a well-established technology and widely used in practice.  In our scenario, it ensures sensitive information to be encrypted.  The cons are the effort we will need to implement access control policies and mechanisms.  The number of services will possibly grow, and the service will go multi-tenant, so it will become more complex.
The pros of the software switch are that it is simple to implement because the features/protocols of the sub-services are well known to us.  The cons are that no such practices are heard before (I might be ignorant here), and we are not so confident if exposing such an in-house solution to the Internet is a good idea.
If you were me, what approach do you prefer?  Why?  Details can be clarified if needed and allowed.
I really appreciate any comments and answers.

I would caution coding your own version of a switch; is the development time really worth it compared to using a VPN solution? Can you securely code it and ensure no internal data is inadvertently accessed?
Should you decide to proceed with a modified TCP proxy, you can implement some architectural changes to increase security:

Ensure the TCP proxy server is in a segmented DMZ, and will only have access to those two applications. Should the TCP proxy server be compromised, only those two applications may be impacted.
Only allow communication to encrypted ports. Do not allow plaintext transmissions.
Log IPs in traffic -- remember, your applications may not see the true client IP anymore.
For any applications using HTTP(S), implement a WAF.
If the applications have a High Availability requirement, possibly consider implementing a load balancer as well as some mirrored servers.
It would not hurt to run a monthly or quarterly vulnerability scan with a tool such as Nessus, OpenVAS, or even nmap's Vulners plugin to get a picture of how exposed your application is to known vulnerabilities.

I would additionally recommend looking at the Application Security Verification Standard and reviewing what security controls you may be missing, and whether or not you can accept that risk from a business standpoint.

However for the sake of the argument, I would lean towards a VPN (or SSH proxy) anyway. From a security standpoint, here are some benefits:

All traffic is encrypted
You can implement some form of access control based on user ID
You can rest assured that VPN software is security tested very well, as it is the front door to most organizations.

For security purposes, make sure that your VPN server is in a segmented DMZ from the rest of your network. Ensure that this DMZ can communicate externally, as well with the two applications you need to be accessed externally. Therefore, if the VPN server or user credentials were ever compromised, the attackers would only be limited to attacking those two internal applications.


NMAP discovery scan reporting host offline, pinging the same host gets ICMP responses I ran an nmap -sn scan on a host, and nmap reported the host as down. I then pinged the same host with ping and got ICMP responses. I'm confused, because I was sure that -sn among other things, did an ICMP echo request.

Output from my two commands:

~ $ nmap -sn 192.168.1.237

Starting Nmap 6.40 ( http://nmap.org ) at 2016-08-16 09:35 BST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.00 seconds

~ $ ping 192.168.1.237
PING 192.168.1.237 (192.168.1.237) 56(84) bytes of data.
64 bytes from 192.168.1.237: icmp_seq=1 ttl=128 time=9.82 ms
64 bytes from 192.168.1.237: icmp_seq=2 ttl=128 time=5.25 ms
64 bytes from 192.168.1.237: icmp_seq=3 ttl=128 time=2.95 ms
64 bytes from 192.168.1.237: icmp_seq=4 ttl=128 time=9.10 ms
^C
--- 192.168.1.237 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.957/6.785/9.826/2.810 ms

Any ideas why NMAP could be confused? I'm running the scan from my Ubuntu 16.04 box, the target is a Windows 10.

If you want to run a ping scan, make sure you are running as root.

From nmap archived docco:

  When you run an Nmap ping scan as root, the default is to use the ICMP
  and ACK methods. Non-root users will use the connect() method, which
  attempts to connect to a machine, waiting for a response, and tearing
  down the connection as soon as it has been established (similar to the
  SYN/ACK method for root users, but this one establishes a full TCP
  connection!)

So you need

sudo nmap -sn 192.168.1.237

Your ping will have the SUID bit set, so that it always runs as root no matter which user you execute it under. This is why it is possible for ping to detect the server, whereas nmap cannot.


Does Kerberos support vendor specific attributes? As the question title says: Does Kerberos support vendor specific attributes allowing access segmentation within a given client device?

Microsoft has no SDK/API to change the kerberos protocol, and it wouldn't be a small feat to reimplement kerberos on both sides (client and server) as an authentication package.

I think you are missing a key point with your use case, kerberos is an authentication protocol, as such it should only deal with checking that you are who you say you are, network location isn't part of that.
what you require is authorization, this is abstracted away from kerberos as a security measure and it is a bad idea to change that.

what you can do is change the authorization part - on the Domain Controller you can decide which user is allowed to login to which computer (or a OU of devices) using group policy. if this is for your specific application you can always implement it at that level.

another way is to create a site per subnet and allow logon to each user per site. look here.


How should I select an antimalware solution? As I prepare to reinstall the software on my machine, I am currently reevaluating my choice of anti-malware software for home use. What factors should I be considering? How reputable are AV-test and AV-comparatives? The latter site gave G data a perfect score in their latest tests. I've never heard of that company before, so I be particularly interested to hear from anyone who's used it.

AV-test and such should be taken a bit lightly.

The tests they do, not always match your needs, and the malware they test aren't always real-life situations

each antimalware solution has a different engine, and usually detect differently, but on really widespread casessuch as conficker, or other worms, all (or most) AV companies share information.

for instance, the 0-day that attacked RSA were on VirusTotal for a long time, only no one thought of checking it. The real competition between AV makers is who will block "it" first. But in most cases it won't affect you unless your internet usage is not so good..

as for G-data, I haven't tested it, most people will say "I had AV type X and never had a virus". Well, either the malware bypassed the AV and they never know they were attacked, or their surfing habits aren't risky enough to get attacked.

I use at least 2 or more (currently looking for a 2nd AV) antimalware solutions. I currently have ESET installed, which I'm quite pleased with in addition to Spybot, which also monitors registry changes.

I plan on testing many AV to see what works best.

So far, I've tested Panda Cloud antivirus, but it really slowed my pc and surfing so I had to uninstall it..

Bitdefender seems best according to av-test:

http://www.av-test.org/en/tests/home-user/

also, my advice is to incorporate some type of sandboxing such as sandboxie to help mitigate risks


Is it secure to use similar password over different accounts? I have a strong password which is a long, unfamiliar word phrase. I would like make other account use a password with similar level of complexity but I don't like to remember so many password over different login ( important emails x 3, bank login x 1 ).

Can I replace some word of the above stated password and use it anyway? For example: aaLongDifficultPhrase, bbLongDifficultPhrase?

I would not bother trying password management software because there are only 1 master password which can reveal all password you own. I would never write down my password.

This is an interesting question. A general rule in cryptography is that creating any patterns in keys or passwords is a bad idea, because patterns weaken the system. For example in your case say you log into 10 websites using a base password of myb@s5PW, and add a password suffix on the end. Maybe for stack exchange you use myb@s5PWstEX, for blog site a you use mhb@s5PWblSI, etc. Or maybe you use aamyb@s5PW and bbmyb@s5PW instead. Either there is a discernible pattern, even if there's only one password known.

Let us say that Stack Exchange was hacked (unknown zero day vulnerability, nothing they could do about it), and all user passwords were gained, including yours. I'm sure that somewhere someone is putting this information into a database, so that DB will then have your username with a password next to it. Say then the blog site was hacked the same way, then there would be two passwords linked to your username with an easily understood pattern. If someone wanted to hack one of your other accounts all they'd have to do is make educated guesses based on the pattern. You could make this more difficult by making your patterns more complex, but it's so easy to brute-force all combinations of myb@s5PW that no amount of complexity isn't going to make that strong. If fact it wouldn't be a stretch for an attacker to figure out your pattern even with one example, if they were looking for it that is, but it's unlikely one would try unless they were targeting you specifically.

So from a pure code-breaking perspective it's a bad idea, but like so many other things in security that's not the only factor. The fact is that most people use the same password for multiple sites with no variation at all, so a hacker who gains the password for one site will in many cases get access to loads of other sites. Why would a hacker go through the trouble of looking for patterns when they potentially have millions of user accounts to tap with no work whatsoever? Only if they are targeting you specifically would you need to worry about that.

Add to that the issue of remembering multiple complex passwords. Unless you are Rain Man you would never be able to memorize 40 strong passwords, so having a base password system that makes sense to you but would take some work to figure out is a workable solution for today's authentication issues.

As as for keeping them all straight write them down, and keep them in a locked desk at work or in a locked drawer in your home. Seriously, the vast majority of people who are trying to gain your passwords are probably halfway across the world from you, who is going to break into your home or work to gain the passwords to your stack exchange account!

This is an approach based on someone with an average level of risk. If you do know someone who might break into your home in order to gain your passwords then using any sort of pattern in your passwords is a bad idea.


how to validate PKCS7 signed message signed with a self-signed cert via OpenSSL CLI openssl cms -in demo.p7m -inform DER -verify verifies the signature on a CMS / PKCS7 encoded message but if the cert that did the signing is self-signed I get a "self signed certificate" error. ie. it doesn't seem to actually verify the CMS / PKCS7 signed message.

Any idea how I can verify a CMS / PKCS7 signed message that was signed by a self-signed cert?

#Try "-signer"
Add the "-signer" parameter.

Like so:

openssl cms -in demo.p7m -inform DER -verify -signer MYSIGNERCERTIFICATEFILE

EDIT: aint' working.


What is the drawback of allowing multiple accounts on a single email? I run a website where users authenticate using email and password. Some users would like to have two or three accounts using the same email address. I see the use case in their situation, and am trying to figure out which drawbacks it has.

As for authenticating I don't see them: basically it's a query where both email and password are variables. So that would work.

Password reset in case of loss would not work, as email is the only variable in that case. As admins can manually reset passwords, that would be acceptable.

Is there anything I'm overlooking?

Password reset, as you've identified. Any type of email notification will not be able to target a specific account.

You could make your site work this way, but it's not a good idea. It's just strange, non-standard functionality. Why require admins to manually reset passwords when users could do it themselves?

What happens if the user forgets which password is for which account? If they request a password reset, how does the admin identify which account to change?

Why does an individual user require multiple accounts? You could investigate the problem they're actually trying to solve, and find a better way to do it.

If it was my project, I would simply tell the client 'no'. Emails must be unique.

It sounds like you're solving one very small (potentially nonexistent) problem by creating lots of new problems.

I could nearly guarantee that eventually your users will ask for an automated password reset utility, or automated account notifications, and you won't be able to provide it.


Should you really check user uploaded files for malware/shells? It's clear that the system has to filter user input. I always thought that the standard is also to check user uploaded files for malware/shells.

I'm curious if above is really needed. There is a PHP (Laravel) application that is accepting file uploads from the user (via REST API). The file will be stored on the server temporary, after that, it will be uploaded to S3 storage.

The idea is that our users can upload files to share internally. Some kind of dropbox for internal share.

I want to give our users full freedom for uploading files, but how safe will it be? Is it really necessary to validate uploaded files if those are stored only temporary on the server and why?

There's three different concerns that get conflated a lot:

You need to make sure the server can't be tricked into executing code.
You need to make sure the server can't be tricked into serving a user-uploaded file with a Content-Type (html, svg, xml) that allows Javascript to execute within the site's origin when a user accesses the file.
Optionally you might want to stop users from accidentally sharing malware by blocking it from being uploaded.

Part 3 is optional. You can imagine the extreme case where you're literally making a website for people to upload malware samples for inspection. In that case, you wouldn't want to implement #3 at all. That server shouldn't do any filtering and shouldn't prevent any files from being uploaded. Files are just bytes; as long as nothing is executing them, they aren't inherently unsafe to store or process. For regular sites, #3 is a nice-to-have, but it should be prioritized after #1 and #2 and can not be done instead of them. Parts #1 and #2 are always necessary.

The main way #1 can be failed is if you're using PHP and you save the files to a directory where PHP is enabled. Then if the user uploads a file with the extension .php, the server will executes it if the user requests it. You can prevent this by disabling PHP on the directory that uploaded files go into. You could also have an explicit whitelist of extensions which doesn't include .php. You should test your application by trying to upload a php file that contains some php code (<?php phpinfo();) and verify that the upload is either blocked, or shows up exactly as you uploaded it.

To solve #2, you need to make sure files are only served with specifically-allowed "Content-Type" headers. Most web servers default to choosing the Content-Type header based on the file extension, so you either need to override that so all files get a safe Content-Type ("application/octet-stream" is a good default that tells the browser to download the file) with maybe a few content types whitelisted (mainly just non-svg images), or make it so there's a whitelist of allowed file extensions. You should test your application by uploading an .html file and making sure that it does not display as a web page. It needs to be blocked, or prompt your browser to download instead of viewing in-place when you access it.


What exactly does a default port scan look like? I am trying to run a default port scan without setting off the ids on my test network What is the best option to use for a default port scan of a server on my test network without setting off the ids using nmap. -f is not a switch i am wanting to use.

You may not want to attempt a "default" scan at all if you attempting to evade IDS detection. A single connection attempt to a closed port could even be enough to trigger an alert; 100 or 1000 such attempts certainly will be detected.

To limit your chances of detection, focus on a small set of ports you are interested in, and specify them with the -p flag. Additionally, you can adjust the aggressiveness of nmap's timing. It may be possible to fly under the radar of the IDS with a slow enough scan. Use -Tn, where n is 1-5; 1 being least aggressive and 5 being most aggressive.

The nmap manual also contains some advice about IDS evasion, such as using fragmentation, decoys, spoofing, and host randomization.


Can trading cryptocurrency using Binance be a security risk? My family runs a architecture business and have a server where lots of things are stored (I don't really know what) and I wanted to get into cryptocurrency trading, however, our IT guy that runs the servers says that cryptocurrency trading is a massive security risk. Is this true, if so what risks are associated?

Cryptocurrency is complicated. If you don't know what are you doing, it's very insecure. If you know the fundamentals, it's very secure. But it's a very bad idea to use a business server for that. Why don't you use another computer for that?


Is the root certificate issued from one Certificate Authority is same for all the requesting organisation? Let me please explain the question a bit more through an example:

There are lots of companies who have their certificates signed by Verisign (or any CA). I understand that Verisign signs these certs with its Private Key (same key for all certificates to be signed?). Now the question is for all these companies certificates, the root certificate will be the same or different?
Suppose org-1 has its certificate signed by Verisign. And as a client, I've stored it's root certificate in my TrustStore. I want to connect to another company, org-2's SSL site. Do I need to add another root certificate in my TrustStore, if its signed from same Verisign?
In my understanding. Its not required as the root CA (Public Key) remains same for a CA. Please correct me, if I am wrong.
As a SSL site owner, if I get my certificate signed by Verisign, do I need to share that with my clients? Most of the browsers come with pre-installed root cert from popular CA like Verisign. So most probably, I don't have to. Right?

Yes, your understanding is correct, and it highlights some of the odd behaviour of how PKI (Public Key Infrastracture) works.
I will summarize your questions:

Will Verisign's root certificate be the same for all companies that it signs certificates for?

If two different companies get their certificates from Verisign, do they share a root CA?

Answer: It depends what product you buy from them.
According to Symantec SSL's (formerly Verisign) page "Buy or Renew SSL & TLS Certificates", they offer a number of different types of certificates:

Most of these will be issued off Symantec / Verisign's public CA. As you mention in your 3rd question, if you host a public website, then you want your site to be trusted by Firefox, Chrome, Safari, etc.
The "Internal Network" option is a bit different; Symantec offers something called "Symantec Private Certificate Authority" in which you get your own dedicated CA hierarchy. This means your company's users will need to install your root cert into their browsers / OSes, but you get more control over the format of your certificates, and most importantly your internal certs won't be published in the Certificate Transparency logs.

As a SSL site owner, if I get my certificate signed by Verisign, do I need to share that with my clients? Most of the browsers come with pre-installed root cert from popular CA like Verisign.

Answer: Correct.
That is the entire reason that publicly-trusted CAs exist: the certificate served by your webserver will chain to a root CA that the browser already trusts.

Summary
In general, all certificates issued by Verisign / Symantec will chain up to one of their publicly trusted root CAs, however Symantec does offer a Private Certificate Authority service, so some companies that get their internal network certificates from Symantec may in fact have their own private dedicated root CA (which is hosted / managed by Symantec).


Directory traversal & default filesystem permissions (755) for web server I'm trying to get a better understanding of the potential security holes my default filesystem permissions might be creating. It appears I am capable of traversing my filesystem, serving simple php pages that display info from files outside my /var/www Web Root:

echo file_exists('../../../bin/filename');

I don't know if this capability is normal if the permissions of my Web Root are set properly. I have the permissions of /var/www as 750, where owner:group = root:www-data.

Since my Web Root's parent directories, / and /var, have owner:group = root:root, their permissions need to be 755 because child directories will not be capable of having more permissions than their parents, and the www-data user that apache is running under will fall into its parents' "other" user category. So, it seems like the ability to traverse outside the Web Root might be normal.

Assuming this behaviour is normal, is it a good practice to set directories that are not parents of my Web Root, like /bin, /sbin, etc., with permissions of 750 so www-data in this case can't get to them?

In terms of restricting what a webserver can do - I usually grant access to the content by the webserver via the 'other' entity (rw-rw-r-- / drwxrwsr-x) - this allows me to set up a group (in some cases multiple groups) of people who can maintain (write) the files. On a simple machine it also means I can strip execute and read permissions elsewhere minimal impact. But using chroot (or containers) is a more effective solution where applicable.

Your example code seem to be using PHP: disabling allow_url_include and setting open_basedir are essential first steps in hardening a server (there's lots more - but this is straying off-topic). Setting open_basedir prevents nearly all directory traversal mechanisms. But the really important thing is to not process paths supplied from the web unless you you cannot avoid the issue - and even then thoroughly validate the data using a whitelist and realpath().


What about fuzzy passwords? For "correct" entry within a margin of error? I'm wondering if a fuzzy password system would be in any way beneficial to users, or worth implementing.

The idea would be that a certain margin of error is acceptable for allowing the user to log in.

Things would be kept track of like what the user remembers best about the original password and what they obviously never seem to recall at all.

The user would be allowed and/or expected to slightly change their password with each attempt.

They would be expected to be sticking with their "fuzzy" recollection of the password. Going back numerous stages might be expected, but remembering the password in a grossly accurate manner would not.

Allowed numbers of attempts per day would also change gradually based on the user's difficulty in logging in. If the user managed to hit one or more of their previously remembered fuzzy recollections of the password, then the assumption would be made that they legitimately are having "trouble", some error margin would be temporarily increased, and they would be asked to try again the next day. With the slightly increased error margin, they might be in luck. If they still fail, they might be S.O.L.

The idea is that the users might be lacking the usually expected level of either sophistication or completeness in their brains, and so some automatic compensation might be needed to allow them to make errors in authenticating their identity but still have normal access to services.

A "fuzzy password system" is a system which accepts several distinct passwords as valid (all the variants over a base password). Correspondingly, it decreases the password strength, thus the security of the system (an attacker who tries possible passwords does not need to hit the exact password, an approximation would be enough). In a password-based system, the password is already the weakest point, so making it even weaker does not seem to be a very good idea.

Accepting the password to be "fuzzy" would be good if it convinced users to choose longer, more random passwords (since they don't have to remember it exactly, they can afford more complexity). However, I strongly doubt typical users would seize the occasion and select so much stronger passwords that it would more than compensate the decrease in security implied by the acceptance of passwords with small mistakes. I even doubt it would make users change their password selection habits at all.


Are networks using EAP-TLS affected by Heartbleed? Does the Heartbleed bug affect WiFi networks secured by WPA2-EAP in TLS mode? Since it's using TLS to secure connections between the server and clients, is it possible to attack the server using the Heartbleed attack and read the memory, stealing the private SSL key from the server?

There are two main ways in which SSL/TLS and EAP may mix: EAP-TLS and EAP-TTLS. Basically, EAP is a generic protocol for exchanging "messages", and the "authentication method" defines the message contents. In the case of the TLS-based EAP methods, the messages contain the various handshake messages from SSL/TLS. In EAP-TLS, the normal case is that the client uses a certificate, and the certificate-based authentication from TLS is then leveraged; with EAP-TTLS, client authentication is not performed during the handshake, but an additional authentication protocol (which may itself use EAP) is played within the tunnel.

In any case, the normal SSL/TLS handshake messages are sent and received and processed, including the "heartbeat" extension of ClientHello and ServerHello. If a given implementation of EAP-TLS or EAP-TTLS uses a vulnerable version of OpenSSL to process the SSL/TLS handshake, then yes, the so-called "heartbleed" attack should apply, subject to the usual (and mostly unknown) vagaries of such kinds of attacks (namely, the buffer overrun will reveal what lies at that place in RAM, which depends a lot on the operating system and overall applicative layer).

Notably, the vulnerability occurs in the processing for the very first handshake message (the ClientHello), thus nothing in the rest of the protocol (e.g. cipher suite choice) has any impact on it.

However, we may say that most WiFi access points are never updated, so this specific vulnerability is just one more at the end of the long (and growing) list of vulnerabilities which apply to most deployed access points. In that sense, there is no reason to panic (the situation is bad, but it already was, and it is not made significantly worse).


Is it safe to store APK signing passwords in private git repository? I develop android game using cocos2d-x. For android release, it contain this fields in proj.android/gradle.properties:

# uncomment it and fill in sign information for release mode
#RELEASE_STORE_FILE=file path of keystore
#RELEASE_STORE_PASSWORD=password of keystore
#RELEASE_KEY_ALIAS=alias of key
#RELEASE_KEY_PASSWORD=password of key

Entire project (including this file) is placed on BitBucket in private repository. So I have four questions:

Is it safe enough for regular developer at all?
If someone get access only to this file (and APK from Google Play), what can he do?
If someone get access to this file and keystore (and APK from Google Play), what can he do?
Is there a way to store it separately from git project?

Not really, no. As nbering said, it is very hard to remove it from git history if you ever want to share it. Git is also not really meant to hold this kind of information.
Not much. The password only encrypts the key, so without the encrypted key, they can't really do anything.
A lot. They can create a version of your app with malware inside it and pass it as yours. However, without access to your appstore account, they may not be able to publish it directly. This still allows them to distribute it in other ways, eg. through different appstores or using the web. If they do gain access to your appstore account, they can publish their malware version as an update and users would have no way of knowing.
Yes and no. If you use manual builds, then you can just add the file into gitignore and distribute it in other ways. If you use autonomous builds, most git sites support special functionality for storing secrets.


Is it unsecure to let my personal computer user name be known publicly? I took a screenshot of a certain finder window to ask a question on apple.stackexchange, and the image includes the name of my home folder, i.e. my user name.

Should I bother to blur that out?

Is there any chance that information could assist a hack or inspire a hacker to aim at my machine?

The information revealed is the username via home folder name, not the hostname.

In theory, any information about a computer is helpful in attacks. What you did was disclosed recon information or partial user enumeration.

But practically? If the username is not your real name, or doesn't contain any personally identifiable information such as birth date city or anything of the sort and is purely a pseudonym? No don't worry about it.

Targeted attacks on personal computers require more information than just a user name, a lot more, and usually the goal would be some sort of reverse shell that will either be within the permissions of a limited user (your account name) or root, depending on the exploit. In the case the shell results in a user, the attacker already knows your account name. In the case of root, he doesn't care.

And blanket attacks are only effective if they don't rely on enumerables such as usernames so again they don't care.

I think you're fine.

EDIT:

Personally I would blur out any information that distinguishes my computer from any other, but I'm the paranoid sort. I would advise you to be conscious of this sort of thing in the future, but I wouldn't lose any sleep over this one.


How do APN hacks work? I've been going through speed caps bypass of Indian ISP using APN hacks which involves either changing sever field or proxy field or ip-versions MNC.

I am just curious how APN works in this case. How is it used to impose speed caps?

The APN is just a field that is sent to the mobile network when your phone establishes a data connection (also called a PDP context).

Equipment down the path can decide what to do with your traffic based on the APN, like routing it to different paths of the network, routing it to a company's internal network over VPN (companies can pay to have their own APNs which connect directly to their network, bypassing the need for an on-device VPN if they trust the mobile provider - which they shouldn't do).

The behavior you're seeing is just the result of years and years of technical debt - the alternative APN you're using may not even be in use anymore by the provider, it's just still there and they've forgotten about it, so they also forgot to implement traffic shaping on it and that's why you can bypass bandwidth limits. Since we're talking about a mobile carrier, it seems that mis-selling and implementing artificial limits like data caps is more important on their roadmap than cleaning up technical debt.

On a properly designed mobile network there is no need to have more than one APN as the network can differentiate between subscribers by their SIM's ICCID (which is also sent to the network and known to the equipment managing the PDP contexts) and assign policies regardless of which APN is in use. This removes confusion and prevents customers accidentally/maliciously using a different plan which could result in an incorrect policy being applied or extra charges.


sslstrip gives error "exceptions.AttributeError: 'int' object has no attribute 'splitlines'" when used with ettercap I have 3 VM's running in VirtualBox. All 3 VM's are connected to a virtual network created from VirtualBox with the IP 192.168.56.1/24

For all VM's are configured Host only Adapter

1 Linux web server that hosts the OWASP broken web applications : 192.168.56.3

2 windows machine that is a client accessing the website : 192.168.56.5

3 Kali linux machine performing a man in the middle attack : 192.168.56.4

Here is what I did.

sslstrip is started

First sslstrip is started.

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

sslstrip -l 8080 --favicon --write=/root/Lessons/sslstrip/sslstrip.log

ettercap is started

ettercap --mitm ARP:REMOTE --quiet --text --write ~/Lessons/ettercap/ettercap.log --iface eth0 /192.168.56.3// /192.168.56.5//

Output

Scanning for merged targets (2 hosts)...

* |==================================================>| 100.00 %

2 hosts added to the hosts list...

ARP poisoning victims:

 GROUP 1 : 192.168.56.3 08:00:27:FE:F6:AC

 GROUP 2 : 192.168.56.5 08:00:27:E6:E5:59
Starting Unified sniffing...

Text only Interface activated...
Hit 'h' for inline help

Now from the windows client browser I visit the home page 192.168.56.3/

It loads correctly.

Now I click one of the links, Mutillidae II

This causes an error in sslstrip

Unhandled Error
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/twisted/python/log.py", line 103, in callWithLogger
    return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/twisted/python/log.py", line 86, in callWithContext
    return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/twisted/python/context.py", line 122, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/twisted/python/context.py", line 85, in callWithContext
    return func(*args,**kw)
--- <exception caught here> ---
  File "/usr/local/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
    why = selectable.doRead()
  File "/usr/local/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 243, in doRead
    return self._dataReceived(data)
  File "/usr/local/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 249, in _dataReceived
    rval = self.protocol.dataReceived(data)
  File "/usr/local/lib/python2.7/dist-packages/twisted/protocols/basic.py", line 579, in dataReceived
    why = self.rawDataReceived(data)
  File "/usr/local/lib/python2.7/dist-packages/twisted/web/http.py", line 649, in rawDataReceived
    self.handleResponseEnd()
  File "/usr/local/lib/python2.7/dist-packages/sslstrip/ServerConnection.py", line 119, in handleResponseEnd
    HTTPClient.handleResponseEnd(self)
  File "/usr/local/lib/python2.7/dist-packages/twisted/web/http.py", line 612, in handleResponseEnd
    self.handleResponse(b)
  File "/usr/local/lib/python2.7/dist-packages/sslstrip/ServerConnection.py", line 131, in handleResponse
    self.client.setHeader('Content-Length', len(data))
  File "/usr/local/lib/python2.7/dist-packages/twisted/web/http.py", line 1314, in setHeader
    self.responseHeaders.setRawHeaders(name, [value])
  File "/usr/local/lib/python2.7/dist-packages/twisted/web/http_headers.py", line 220, in setRawHeaders
    for v in self._encodeValues(values)]
  File "/usr/local/lib/python2.7/dist-packages/twisted/web/http_headers.py", line 40, in _sanitizeLinearWhitespace
    return b' '.join(headerComponent.splitlines())
exceptions.AttributeError: 'int' object has no attribute 'splitlines'

If I manually put https in the address bar, this error doesn't happen. But then no SSL stripping happens.

Since Twisted 19.2.0, the headers' values are expected to be in byte string but the value of the 'Content-Length' header passed by SSLstrip to Twisted is len(data) and this is an integer. So if you replace len(data) with str(len(data)) in

File "/usr/local/lib/python2.7/dist-packages/sslstrip/ServerConnection.py", line  131

it should do the trick.


Is it possible to detect the application level protocol in a TLS tunnel without interception? Consider a proxy that doesn't intercept TLS, but allows CONNECT tunnelling, but only to limited ports (eg: 443 only). If someone runs an ssh server on port 443 and connects to it using CONNECT, would it be possible for the proxy to detect that the protocol inside the tunnel is not HTTP, and block the traffic?

It is possible to do limited traffic analysis without doing decryption based on timing, size and direction of transferred data. For example HTTP/1 has a request-response pattern where the requests from the client are usually small while the responses from the server are much larger. Additionally the information in the TLS handshake often allow to distinguish normal browsers from other clients based on supported ciphers and their preferences, used TLS extensions etc.

There are actually many articles and publications about this topic which you can find when searching for passive traffic analysis tls.


How do I choose whether to trust a particular website? From @GrahamLee's comment over on this question, this is a very good point:

How do I choose whether to trust a particular website when the only information I have relevant to my trust decision is the web?

Do I trust it because of history? It has always appeared right so probably is now?
Do I count the number of other sites that trust it? The web of trust concept?

or what else?

I believe in cross-fertilizing between sources of information. Most of them start on the internet, but we have more and more ways to link virtual resources (e.g. websites) with the physical world. Following are a few ways I use to see if I can trust a website. I hope it helps :)

Does the site look professionally made?
Does the site have a certificate? Is it valid? Please keep in mind that invalid certificates are unfortunately very common.
If there is a login/e-business part in the site, is it using SSL?
Do I find any positive/negative feedback on this website on forums/mailing lists?
Does the whois.net information give me any information that would
help me trust the namespace owner?
In the contact section of the website if there is an address? Using a research engine, can I find other businesses at the same address? Can I find a telephone number of another company to check with them if the site is legit?
Can I see the building on Google street view? Does this building give me
confidence?

A bit more advanced:

If there is a login feature, do simple injections techniques work?
Browsing through the HTML/JavaScript code, do I see any reason not to trust that website? Here I'm looking for visible access control flaws, stored logging and passwords...
If the website is using a CMS (e.g. wordpress, SPIP) is it a "safe" version?


Tor IP and cookies in hidden services So when you connect to tor it gives you a specific IP right, who's IP is this exactly? And when you visit an open website who's IP is visible to the site, mine or the exit node. And while you're connected to end to end untrusted hidden service if the website tracks you with cookies is my original IP visible or the one assigned to me by tor?

I use orweb on android for hidden services and I use different browser for google, Yahoo,etc so I'm not exposed by ad cookies.

The cookie usually doens't hold IP information.  And your browser isn't -as far as I know- able to determine your IP address and pass this on.  Even when it would be, through a plugin/activeX control, it may be the RFC1918 IP address which is fairly useless.

A cookie, however, can identify your browser.  A website can set a unique value which your browser remembers when it visits that site.  If you don't clear your cookies (and there's more ways to do it, see evercookies) - and you connect using a different node.  The target site will see a new IP address, a new country even, but it's the same browser/session, and hereby the site owner may derive that you are the same person.  But as a general rule of thumb, installing plugins could compromise your privacy.

So they may see that you (your session) logged in from China, an hour later from Belgium, then from Ohio.  Assuming you are using some sort of routing network such as Tor.

From an IP point of view, it will be the IP address of the final Tor node.


Is message signing important in a client-server chatroom already over TLS? If I have a client-server web chatroom, is it important for public or private(client-side encrypted) messages to be signed on the client side? Am I correct in assuming (correctly set up)TLS will prevent any MITM risk?
Each user has their own private/public key for pm encryption.

Clarity: I am developing both the chat server and client

Using TLS doesn't prove the user's identity.
When you use a web browser to connect to a chat room, the server doesn't authenticate your web browser. Only your web browser authenticates your server.
If you are using a chat client, it MIGHT use client side authentication. Even in that case it will just ensure that you are using a valid client. The certificates stored in clients are not the user's certificates. If a web chat room did create certificates for each user, then a user would have to be educated to install it's server on the client and also it will be a pain for multiple accounts to access the chat room using the same client (say a shared computer in the house).

To prove that it is actually you who is sending the messages, you should use message signing unless each chat client has a unique key and you have a mapping between the chat client and the user..