Wifi security SSID clarification I've read several Wifi security related questions on here. There are two things related to the SSID which I don't fully understand.

Is there a best practice for SSID naming?
I know that changing the SSID from the vendor default is recommended and that if two APs have the same SSID but different encryption/ passphrases, Wifi clients will still try to connect.

So, should SSID naming be more complex than say single words such as "wizardofoz" to something such as "wizardofoz_1d3h2"?
SSID hiding is not a security feature and I understand that hiding SSIDs for convenience such as when you have corporate private and public Wifis has its place.

What I'm not entirely clear on is what happens in the two states: hidden and unhidden.

In the hidden case, the AP does not broadcast the SSID, e.g. "wizardofoz". So instead the Wifi clients which have the SSID configured and saved, broadcast "hey where are you wizardofoz".

In the unhidden case, the AP broadcasts the SSID, and configured as well as unconfigured Wifi clients see that the SSID "wizardofoz" exists. In this instance the Wifi clients which have the SSID configured do not broadcast looking for the SSID.

Have I summarised the hidden/nohidden SSID cases correctly?

If so, in a scenario where a Wifi client (e.g. iPhone) is in a remote location from the known AP SSID ("wizardofoz") and we assume that the known SSID is hidden.

Is a rogue user more likely to create an AP with that SSID and try to get the handshake information compared to the unhidden case where the Wifi client would not broadcast the SSID it has saved.

Have I got that last bit right?

UPDATE: With respect to Lucas Kauffman's answer regarding my scenario above, by what criteria do you determine whether to hide the SSID?

Not really but preferably you have at least one part in it which is random (unless for instance when you need roaming. Another reason is that WPA uses the SSID as salt for the hash. This means that rainbow table exists if you have a on often used SSID (i.e. linksys)
Yes correctly. It's security through obscurity (but it can be useful). Attackers will generally send deauth packages on all channels in the hopes that a client is connected and will start broadcasting the SSID.

For your scenario it depends, to discover a hidden SSID you need to have at least one client connected to try and discover the SSID. So it depends, he might switch between attacks (depending on his goal).


Robots.txt and admin areas I'm using some popular commercial forum software and to help secure the admin area more I have changed the name of the admin folder; however I was wondering, with regards to robots.txt if I go ahead with putting:

User-agent: *
Disallow: /random_admin_name/

Then wouldn't I just be exposing the "secret" admin name now!?

So my question is - how do I stop the admin from being indexed and found by someone else?

Renaming it to something, then shoving that name into robots.txt just shows an attacker what directory you want to protect. Think of the following: "I will put my jewels into the third drawer, but leave a sign for a robber that says: 'don't look in the third drawer!'"

Your real option to protect you here, is to place an .htaccess file in the directory you DON'T want accessed, and in that .htaccess file, ONLY give yourself the option to view that directory

Order Deny,Allow
Deny from all
Allow from 127.0.0.1 (where this is your IP)

Or you can add mod_security and add a similar re-write.


Success rate of pixie dust attack Recently I read about the pixie dust attack in which a WPS PIN is decoded with time stamp and other resources within a fraction of a second. The only drawback is that it only works on WPS enabled routers. So what are success rates of this attack. Is it 100 percent or very low? Is it better than bully attack or pixie is better?

These days, most wifi routers incorporate various forms of protections against attacks like pixie dust, e.g., not allowing multiple tries for the PIN in quick succession. Some even require a human admin reset after, say, 3 wrong PINs.

Furthermore, the weaknesses of WPS are well known, so more people are disabling it if they can.

Thus, the success rates are not high these days.


Is it as safe to use a programming language as a browser? To browse the internet on sensitive websites (government websites, banks, etc...), is it as safe to use a modern web browser as a programming language? Specifically, python + requests + beautifulSoup for example?

Modern browsers are massively complicated pieces of software: they can run at least one complicated interpreted language, handle a bunch of different types of media files, and connect to a wide range of services, which can use a whole range of different methods to transfer data in both clear text and encrypted forms. That tends to mean there are a lot of things that could go wrong resulting in data being exposed to an attacker.

However, they are also subject to a lot of scrutiny when it comes to the security aspects. They implement careful memory management for sensitive pages, isolate tab contents from other tabs, have vigorously tested encryption libraries, and in many cases get constantly fuzzed looking for flaws in processing routines. Chrome has (At time of writing) about 1500 CVE issues, but, and this is quite important, the majority of these are fixed quickly.

On the other hand, a script which loads a specific site and performs one specific actions is relatively simple, even if it uses pre-built libraries to do heavy lifting such as performing SSL connections. That makes it less likely to contain issues caused by unexpected interactions between components, but it is used by fewer people, so any issues less likely to be discovered. It probably doesn't make any attempt to ensure that passwords and other sensitive information isn't written to disk inadvertently, and may even contain hard coded credentials, which could be exposed if the system it is running on is compromised. It relies on the developer to keep encryption libraries up to date, and to handle any changes to the responses from sites which are required (e.g. if the site uses an API with an Authorization header added by JS, the script will either need to run the JS, or perform equivalent steps and add the header when required).

The script is also unlikely to handle things like HSTS headers or give alerts when certificates don't match expectations, meaning that if it is used on an insecure network, an attacker may be able to intercept the traffic generated.

The threat models for each are different: the script is likely to be vastly less secure if an attacker is able to compromise the system where the script is running, while an attacker who can place malicious code in an advert shown on a sensitive page is likely to be more successful against users of full browsers - a script is probably going to ignore the advertising code, or not be vulnerable to the methods used to try escape the browser sandbox.

Personally, I'd stick with the browser though - the developers are thinking of problems I've not even considered, and implementing fixes for them without me needing to lift a finger, and as long as I keep my browser up to date, these improvements just turn up like magic.


Does my UI need to be secure if my API is? I'm working on a project that is creating two new, separate web modules (possibly even on different servers) to support a new web application, with one serving up a static JS-based UI and the other project providing an API. The API will be secured by role, meaning that you must be logged-in and have the right role(s) in order to access endpoints, however I was wondering whether there's much merit in securing the UI?

I'm not talking about SSL, as hopefully we'll be able to enforce that on both projects, but more about whether it's ok to just dump a single, large JS file onto a user's machine (once they've logged in with any role), regardless of which roles they have, and to rely on the API to secure the data?

I get the feeling I'm missing something fundamental here, but as far as I can see the only real risk is in terms of application logic in the UI being visible to all customers, although it would obviously be minified - and therefore obfuscated.

Apologies for the slightly vague question ... I'm afraid this is not an area in which I have much experience.

I think you are on the right track.  As long as the API is secure and won't allow incorrect behavior, then there is no way for the UI to be manipulated to cause bad behavior directly, at least as far as the application is concerned.

The problems start when you realize that from the user's perspective the UI can't be trusted though.  If it is possible to manipulate what the user sees, then it may be possible to get them to enter incorrect information by misleading their input.  Similarly, information leakage from the UI may or may not be a problem in your context.

You won't have to worry about bulk exploits breaking business rules, since the API won't allow it, but you still have security concerns around the end user experience.


Is there a way to securely lockdown a website to an Iphone? So with a typical website, perhaps the fastest and most effective (arguably) way to secure the site is to add a simple .htaccess and restrict by ip addresses:

.htaccess
DENY from ALL
ALLOW from xxx.xxx.xxx.xxx

but I want to access my website via an approved iphone. Is there an equivalent way to do something like the .htaccess and add each approved device? I doubt the logic will be in an .htaccess file but the end goal is to have a secure device (iphone) that is pre-authenticated to my site without every having the end user enter a site-specific password.

A partial example of this would be how Apple assigns provisioning certificates to a developer's Iphone so that only that developer may run an app that is not released yet.

Once again, I am looking for a solution that never asks for a password (at least not from my website).

You can use Apache's mod_ssl to authenticate against client certificates.

The example is from cacert.org, but you can create your own CA to accomplish the same goal.


Understanding Snort log I am new to Snort, and I have ran Snort through a .cap file and got the logs that I should interpret. If I take for instance a block of log like the one below:

[**] [1:2463:7] EXPLOIT IGMP IGAP message overflow attempt [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
05/29-19:44:02.238185 249.94.153.251 -> 249.94.153.77
IGMP TTL:255 TOS:0x0 ID:9744 IpLen:20 DgmLen:502 MF
Frag Offset: 0x1FFF   Frag Size: 0x01E2
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0367][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0176][Xref => http://www.securityfocus.com/bid/9952]

I know that this is an alert generated by GID=1 signature id 2363, revision 7 (if I'm not wrong; also that means a denial of service alert), but what does the other information mean?

[1:2463:7]: Intrusion Signature
EXPLOIT IGMP IGAP message overflow attempt
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
05/29-19:44:02.238185: message explaining the possible consequences of the the attack.

249.94.153.251: Source IP: this is the IP address where snort believes the attack come from.

249.94.153.77: The destination IP: this is the IP address of the attack target.

IGMP TTL:255 TOS:0x0 ID:9744 IpLen:20 DgmLen:502 MF Frag Offset: 0x1FFF   Frag Size: 0x01E2: Basically, in this attack the attacker creates and sends a malformed IGAP packet, and if decoded by a vulnerable version of Ethereal/tethereal, can cause a buffer overflow and the subsequent execution of arbitrary code. So, this data describes information about the IGMP packet that triggered the alert. Like Time to Live (TTL) and Type of Service (TOS) for more information look at http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0367][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0176][Xref => http://www.securityfocus.com/bid/9952]: these are additional links that provide more information about the vulnerability that make this attack possible. The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for publicly known information-security vulnerabilities.

For other snort signatures look at https://www.snort.org/rule_docs/

I hope this will help to understand snort alerts


How does Google track a user? Some days ago, I was studying Web Programming for academic purposes. So I was learning SQL Injection by applying it on a sample website sqlzoo.net/hack/

But soon after it, in the Google ads on every page, every ad has been of "acunetix - Learn to prevent SQL Injection attacks". I don't get ads of other categories. Why do I only get ads of how to protect my PC and relating to SQL injection?

Amazed i am, I want to know how Google tracks my page transitions.

Google uses what are called cookies to do this. Nearly every website uses cookies of some form.

From Wikipedia:

  A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is a small piece of data sent from a website and stored in a user's web browser while the user is browsing that website. Every time the user loads the website, the browser sends the cookie back to the server to notify the website of the user's previous activity.1

Here's some information about Google's cookies: https://www.google.com/policies/technologies/types/


Should all Server Certificates from one CA have the same CRL I am setting up my own PKI, and I came across a question to which I couldn't find an answer.

I want to specify CRLDistributionPoints in my server certificates but I am curious whether to use the same URL as I did for the CA or use a separate one for every server certificate. What is "best practice"/reasonable?  I don't understand CRLs.

Each CA certificate is supposed to have one and only one CRL.  It is serialized and signed with that CA certificate, and each subsequent serial number supersedes previous ones.  However, items should not be removed from it ever.  I don't believe behaviour is defined where a CA maintains multiple concurrent CRLs.

That said, as a CA, you may (must) maintain a separate CRL for each CA certificate (subordinate or otherwise).

The reason for multiple crlDistributionPoints is to allow you to increase reliability by giving multiple URLs.  This isn't really necessary because there are many different ways to provide reliability, but it can be helpful I am sure in some scenarios.


Handshake failure with identical client hellos I'm at my wit's end investigating a handshake failure I'm receiving.

We have two separate clients using .Net + Server 2012 R2. Both are attempting a TLS handshake with the same destination IP. Wireshark shows the client hello as identical for both sides, but only one is successful. For the unsuccessful one, the server responds with a handshake failure (error code 40) immediately following the client hello.

I've done a diff comparison of the hex dump of the client hellos and the only noticeable differences are the timestamp and random.

Success:

Failure:

What could be the problem at this point? Could it even be a TLS issue if there are no differences in the client hello? I haven't been able to find any resources that could explain this.

Even ideas at what to investigate will be helpful.

EDIT:
If other's run into this, the problem was network security software BlueCoat. We created a bypass rule for our client server and the handshake is now successful.

This could be the action of a Network Intrusion Detection System, like snort, that has found some reason to refuse to allow one of the systems to connect.

NIDS systems work by sniffing all the packets on the network, identifying those that may be associated with suspicious behavior (such as a port scan), and then responding in some way.  By default, most NIDS will just write an alert in the log if they see something.  But your network team might have gotten more aggressive, at which point they may have enabled "active disruption".

Let's say that the failing box was used to do a network scan, and your NIDS caught it.  It would record that IP address, and every time it sees a packet on the network associated with that IP address, it sends a forged RST packet to it that looks like it came from the server's IP address.  That would prevent the machine from connecting to the server, which would certainly stop an attack.

I recommend engaging your organization's network security team, and see if they have any record of the failing machine's IP address being caught by their NIDS.


Remote Auditing a Secure WiFi Network-Obtaining enough of the Secured-Network credentials to attack without being in range of WiFi I was wondering if there are any methods I'm unaware of that will allow an attacker to attempt to obtain WiFi access outside the physical range of the WiFi signal.

When using net-stumbler or any other signal detection suites, we all know it'll report the following:

BSSID/Mac,PWR,RXQ,Beacons,#data,#/s,CH,MB,ENC,Cipher,Auth, and ESSID.

I'm familiar with the common WiFi attacks that  it requires the attacker to be in  physical range of the WiFi.

My Question is:
Are there any other methods of finding out network information enough to remotely attempt to audit the security parameters of their WiFi/network?

I hope I conveyed my thoughts enough... Please let me know if I can provide any further details to the scope of my question.

I believe the PTW attack on WEP only requires you to be within range of one of the clients of the AP, not the AP itself.  Other than that, I'm not aware of any attacks that can be done without being within range of the AP.  Some information-gathering can be done by listening for probes from former clients of the AP, but I don't know if you would call this an attack.

Note that this range can be a lot longer than you'd expect.  Without using any special equipment, I've picked up APs from as much as 15 miles away.  Quirks of radio propagation can change the coverage area as well: I've picked up APs that are out of line-of-sight by pointing an antenna at a tall building and catching the reflected signal.


Please help diagnose multiple incoming packets We have an internet-facing router and it is significantly slowed down. We investigated the network traffic and came up with following information:

All the packet size is same (i.e. 40 bytes)
All different source IPs
Source port is the same for each request (i.e. 1234)
Same destination port (i.e. 80)

Is this a DDos attack? or any other attack signature?

looking at the traffic pattern, It's a clear SYN Flood attack, a type of DDoS attack which is still prevalent and used by a lot of threat actors. Recently, even Google and Cloudflare DNS servers were affected by this and more on this at https://sissden.eu/blog/darknet-attacks-on-google-and-cloudflare-dns

From remediation standpoint, if your service is critical for your customers, you may try looking at DDoS mitigation providers like Incapsula, Akamai etc. They offer dedicated services along with automated scrubbing technologies which can handle various types of DDoS attacks.


What are reasons to ask for 2FA before password? My employer's login flow asks for a username, then a 2fa, then a password. They do it this way because they fear someone could try to brute force passwords and create a denial of service attack by locking out all our accounts. This flow breaks my password manager and because I've not seen a similar flow elsewhere I'm betting there are compelling reasons not to do things that way.

What are compelling arguments for the traditional flow of username -> password -> 2fa?

I actually like the flow your employer has better, to be honest. If you can't get past the code entry you most likely would never get past the password prompt (which is what would lock the account out, typically). So, this flow actually does seem to prevent it from getting that far.

I think the reason everyone uses the traditional flow is due solely to the fact that their authentication method is already in place and they're adding 2FA as an after-thought (additional feature) rather than having it built in from the ground up to implement it in the same manner as your employer, or they simply haven't thought about it in the same way to see the benefit.


Identifying suspicious encrypted traffic Firstly, I welcome a better title for this question. I admit I'm a security novice.

I'm trying to determine whether I have malware and what that malware may be doing. Using Wireshark, I see several suspicious streams, including addresses ending in .ln and .ch that send all data encrypted. When I run whois it always times out, unless I specify explicitly the whois server to use (this is itself suspicious to me), so I've resorted to using an online client at http://whois.domaintools.com/.

One stream that is more consistently present goes to lga15s42-in-f21.1e100.net, every few seconds, and is sending over TLSv1.2. Packets are often of fixed sizes (60, 107, 125) but are sometimes larger and not repeated sizes.

~The whois entry for 1e100.net is particularly suspicious to me.~
Scratch that. I had invalid entry by mistyping the domain. Actual entry is for Google, Inc, which greatly reduces suspicion of this traffic.

Amended question, since the traffic would seem to be going to Google: why is Google sending this info over TLS on a non-standard port? Is that basically the way they should send background queries? It is annoying because to a security novice (or for that matter, not a novice), such traffic adds noise. I would be happier if such queries went over clear-text on standard protocols, as I'm trying to figure out if I've been rooted.

ps. Should have mentioned, the computer in question is a MacBook Air Retina Pro, running OS X 10.9.3.

The domain is 1e100.net but the whois entry you show is for le100.net, with an l, not a 1 (if these appear to be the same for you, then choose a better font).

The 1e100.net domain is a lot more legitimate, and its name is some sort of joke. Indeed, if you do a whois request on it, you get:

Domain Name: 1e100.net
Registry Domain ID:
(...)
Registrant Organization: Google Inc.
Registrant Street: 1600 Amphitheatre Parkway
Registrant City: Mountain View
Registrant State/Province: CA

which means that the domain is registered by none other than Google themselves. The joke is a reference to the Googol, a term for the huge integer 10100, which would be written in so-called scientific notation "1e100".

That the domain is used by Google is documented by Google, there. Basically, you are observing a Google product (say, Chrome) trying to talk to its home base, possibly to know if there is a new version available, or as part of some mechanism of Google search / Google+ / whatever. That's not a malware.


Why are there Hashes next to downloads? I've seen several sites wehre they would put the hash of the downloadable file next to the file. Why do they do this ?

I understand the purpose of comparing the hash of your file with the online hash but if an attacker could change the downloading file he shouldn't have any problems for changing the site too or the hash on the site.

Doesn't make that the hash almost useless ?

You are thinking about problem the wrong way.

One reason to have the hashes close to the download is to you detect if your download has been corrupted. It's not uncommon to have a corrupt download, so having the hash will verify if you downloaded cleanly.

The other reason is that is common to a site host the files on another host, like a Content Distribution Network. In those cases, the site owner has less control about the files, so someone could tamper them, even having direct control over the main site files. This will make sure that nobody tampered the files on the remote host.


What would typically be considered an acceptable string entropy for passwords? I have gained interest in creating a way to check password strength (think password strength meters - yes - another one). I've found many ways to award a score on a policy driven approach (one capital, special character - you get it), but I've also begun to look into string entropy. Specifically, I've found this JavaScript implementation of Shannon entropy

In their example, "1223334444" awards 1.8464393446710154 in bits of entropy per character. I assume, then, the entropy for the string is the character count multiplied by the length - then being 18.464393446710154

My question is, though, in real-world terms, what does this value mean? Is it decent? poor? Where does the poor/decent/strong acceptability rate begin and end for values such as this? Likewise, whats considered "overkill" for an acceptable user expectation?

As I understand it, the amount of entropy in a password represents the number of guesses required to know what that password is. Each bit is a single yes-or-no decision, and ideally, the attacker would either get a "correct password" or "incorrect password" result (so, they have to guess the whole thing, all at once). For n bits of entropy, that requires 2^n guesses.

The desired strength depends on what sort of threat you expect to face. In particular, it depends on how fast the attacker can make guesses, and how long you expect the attacker to keep trying.

Once you have those numbers, your target minimum entropy (in bits) should be:

n = log_2(totalGuesses) = log_2(guesses/sec * durationInSeconds)

The persistence of the attacker is something which I don't know how to estimate. For the sake of argument, let's assume that you want your password to be secure for 1 week after the attacker starts guessing.

Number of guesses per second depends on how the password is protected, and what sort of access the attacker has. For an online attack (i.e., trying the login form of a website), you could rate-limit it to a fairly low value; 10 per second would be achievable. For unsalted MD5, it's safer to assume billions of guesses per second. For a strong hashing algorithm like bcrypt, it will be somewhere in-between (MUCH slower than MD5, in any case).

So, at 1 billion hashes per second (offline MD5 cracking), you would need to defend against about 6*10^14 guesses total, requiring about 49 bits of entropy. At 10 guesses per second (online, rate-limited attack), you need to defend against about 6*10^6 guesses, so you need about 22. bits of entropy.

Of course, per-character estimates of Shannon entropy will not accurately estimate the difficulty of cracking a password, and the percentage error will vary wildly depending on various factors. The approach you're taking will only give reasonably accurate results for computer-generated passwords, NOT for human-generated passwords.


How to roll my own security mechanism - avoid SSL I'm looking at implementing my own security mechanism rather than using SSL due to SSL being 'hopelessly broken' and also because it is an interesting exercise :)
This is for a client-server internet application.

Caveat - I am not a security expert - just been reading up on security.
I will also be building the client application therefore I will have control over the implementation both sides.

SSL Problem

The main problem I see with SSL is due to the swapping of public keys at the handshake stage, and a man in the middle intercepting this. SSL tries to avoid this problem using message signing and certificates etc to validate the server's public key to the client. But an attacker with a forged certificate can still get around this.

Workaround

Due to this problem of safe public key exchange, I'm thinking this can be avoided by simply not having to swap the server public key, by having 'known' server public key built into every client application. Say a 3072 bit RSA key.

Implementation

The implementation for each communication session would thus be
client generates a public / private RSA key pair
client encrypts its new public key with server's public key and sends it to server
server decrypts message to discover client's public key and then uses this to encrypt any responses to the client
client continues to send traffic to server encrypted with server's public key
each message sent from the client also contains in the header:

the client's username encrypted with the server's public key
a hash of the un-encrypted client message - using as input to generate this hash, another hash of [client username + realm + client password]

Observations

Server can prove identity of client by first decrypting message using its private key, and then calculating hash of the unencrypted message using the hash of [client username + realm + password] which it has stored in its database.
Man in the middle cannot monitor traffic as it is encrypted both ways
Man in the middle cannot pose as client because he cannot generate a valid message hash
Man in the middle cannot pose as server because since he cannot decrypt initial message, he cannot discover client's public key in which to encrypt responses to the client
The client's password itself is protected against brute force scrutiny as the hash which used the clients password as input, is against the un-encrypted message, so attacker would first have to decrypt the message before beginning a brute force attack against this hash

Seeing as I'm not a security expert I am hoping if someone who know's more about security can spot any holes in this approach, or confirm if it is good. And also if a 3072 bit RSA key can stand the test of time without being broken.

Thanks!

You're confusing SSL/TLS with its most common usage pattern, which is TLS in conjunction with X.509 certificates and a Public Key Infrastructure (PKI, RFC 5280).

While it's really important to secure a TLS connection by authenticating its server site (to prevent active MITM attacks), the TLS specification doesn't actually mandate to do it using X.509 certificates, even less using a PKI.

As @jathanism said, you can choose not to rely on a hierarchical PKI, by using a self-signed X.509 certificate. You will have to establish trust in the server certificate by some other means.

In addition, TLS can also be used with OpenPGP certificates, Kerberos or Pre-Shared Keys.

TLS itself has had very few known bugs as far as I know, e.g. there was the renegotiation bug (CVE-2009-3555), which has been fixed (more recently, there were also certain issues with certain block ciphers, which can be fixed by choosing better cipher suites, or upgrading to newer versions of TLS).

The issues you're talking about (and often discussed in the press) tend to be related to PKIs, i.e. how to establish trust in the remote party. How this should be done isn't dictated by the TLS specification itself.

If you want to try to find a better way, by all means do some research, but I'd suggest focussing on this part and leaving SSL/TLS and the cryptography side of things alone.
You'll probably find that the biggest problems regarding PKIs and their alternatives are administrative, not so much technical ones.

The other aspect of authenticating the remote party is to check you're talking to the intended party (i.e. host name verification).


Why is it dangerous to socksify a whole system? Today, I configured my browser to use a ssh/SOCKS5 proxy setup to keep my web traffic confidential even when browsing from insecure networks (e.g. a public WLAN hotspot). I was then thinking that it would be even better for my privacy to do the same for all applications that connect to the internet. I should note that I understand that SOCKS works on the application layer of the OSI model and that it would be the easiest to use a VPN if one wanted to tunnel all system traffic.

There are however many tools available that make it possible to proxy arbitrary applications through SOCKS. One of these tools is called socksify and its developers state that it is possible to use it globally, at least on some systems. However, they go on to note that:

  You should not attempt this unless you know what you are doing, as it is a potentially dangerous operation.

(source)

What do they mean by that? What are the potential dangers of socksifying all applications on my system?

Based on the surrounding text, it doesn't seem like they are warning you about potential security implications or bad practice, but rather the fact that it may break connectivity for some parts of the system/applications.


How does one test AV against zero-day malware? Lately, I've read several articles about anti-malware software and one thing caught my eye - ability to detect zero-day attacks.

In short - how does anti-malware / anti-virus industry test their own software against zero-day threats? How can someone claim that AV X protects system against 93% of zero-day viruses?

First off, virtually all AV companies have several "fly traps" or "honeypots". A fly trap is a network of desktop computers with Internet access and zero protection that exist to "catch" malware. Bot-scripts on the computers crawl the web looking for risky sites, and break all the rules for safe browsing that are drilled into us normal people. As a result, they pretty much become petri dishes for computer viruses.

These fly traps serve two valuable purposes to security experts; first, these boxes catch new malware that may never have been seen before, giving experts notice that a zero-day threat exists. Second, once they've isolated something new, they can introduce it into a completely isolated, "clean" fly trap with a lot of monitoring tools, and watch it do its thing; see how it replicates, what protocols and ports it uses, what files it modifies, what harmful effects it can have; generally, everything they need to know to be able to protect AV subscribers from this new threat. They can also introduce it to a computer protected by their AV software, and see how well it fares; anything the virus does that the AV doesn't catch and prevent can be specifically looked for by tweaking their virus definition files or their heuristic algorithms to add this known threat.

In addition, AV experts have been at this for years. Decades even. Despite news stories reporting worms like Confickr, Storm, Stuxnet etc, these are the two or three a year that are notable; thousands of new viruses a year go unreported, because they're really just a rehash of something the AV guys already knew about. As Techbrunch said, most AVs have a heuristic detection algorithm layered on top of looking for specific known viruses. There are areas of a computer that are obvious targets (kernel, device drivers, network adapter, I/O hooks), and there are well-known ways to try to get to them. AV algorithms continually scan a protected system looking for these general red flags. Those thousands of new but unoriginal viruses trip the heuristic detection, the AV interrogates the source, collects information, quarantines anything that might have been maliciously affected and calls home to report this new potential malware. This heuristic algorithm basically turns every AV-protected computer in the world into a huge fly trap for the company writing the AV; what better way to see what needs to be defended against than to see infections happening in the real world?


Is it safe to have 2nd SSD with dangerous software? (disk encryption of the first drive turned on) Currently, I'm using 1 SSD and I think it's safe. I'm thinking about using 2nd SSD for unsafe software (pirated software). Is it possible that the virus on the 2nd drive can reach the 1st drive, somehow damage the PC, or bring other unwanted effects?
There is a BitLocker disk encryption turned on on the 1st drive. I'm not going to provide the key to unlock it to the 2nd system, also I'm not going to open or execute the files of the 2nd drive by the 1st drive system.
Both systems are Windows 10.
Also, I thought about using a virtual machine for this purpose but found the information here that it's not 100% safe since the virtual machine can execute programs on the same CPU, which is unsafe, and there are some other vulnerabilities.

I'm using 1 SSD and I think it's safe.

You are "safe" in this sense when you have a full backup of your ssd which is not physically connected to any running computer.

Is it possible that the virus on the 2nd drive can reach the 1st drive, somehow damage the PC, or bring other unwanted effects?

Absolutely yes. If malware runs on your computer, it is trivial for the malware to destroy all of your data, no matter on which disk the data is stored in.
You should never run malware directly on your system. Either you use a dedicated computer for that or (more practically) you use a virtual machine like virtual-box or vmware with a clean OS (without any private data) to execute malware.

I thought about using a virtual machine for this purpose but found the information here that it's not 100% safe since the virtual machine can execute programs on the same CPU

This can be the only problem using a virtual machine. It is rare that attacks like this will work (depends on the malware you are using). But using a virtual machine is much more safe than using no virtual machine.


Why do most browsers store browsing history by default? Why do most browsers store browsing history by default? It seems like people often have to go to the hassle of manually deleting their history or using incognito mode. Are there some major advantages to storing this data in most cases?

There are a lot of advantages. Here are some:

Auto-completion of previously visited URLs you forgot, which can speed up the web surfing process tremendously. You might have remembered parts of a URL or website title, and your browser can usually pick those up if you typed them in. I love this feature.

This can offer extra security. As mentioned by kasperd, it can greatly reduce the risk of typosquatting.

Storing previously-loaded data in a cache to speed up web-browsing. Great for slow connections. Great for reducing load on web servers.
Storing cookies so websites remember your login information, etc.


Guarantee one unique identity per node I'm in the early stages of designing a decentralised systems protocol, based on a blockchain, for a thesis. For the protocol to remain secure, each node in the system must be capable of generating one, and only one, unique identity for itself. Nodes will publish data onto the blockchain under this identity. The system will be subject to attack if a node is able to generate multiple identities for itself without detection.

Do any such identity generation/verification solutions exist?

This is impossible (or, if you really want to nitpick, it can't be done usefully).

Proof: suppose that you were able to detect when one node generates two identities. An entity wants to carry out the attack that the unicity of identity prevents. That entity can create two distinct nodes and have them cooperate to carry out the attack.

You can apply heuristics to try to detect when multiple nodes are controlled by the same identity, but that won't be easy or reliable. You can raise the cost of creating a node, but that only works if the attack isn't a very damaging one.


Does the modulus of a TLS certificate uniquely identify the client? I'm working on a project using a trusted-peer setup. I want a way to uniquely identify each actor in the system, ideally across certificate re-issues as well.

In my understanding, the modulus of a TLS cert uniquely identifies the client, and should not change when the cert is re-issued. The only thing that would change the modulus would be if the private key were compromised and therefore changed. Is this correct?

EDIT: also, is it correct to assume there is a 1:1 mapping between private keys and moduli?

If we are talking about RSA, then the public key is, nominally, the combination of:

The modulus n
The public exponent e

while the private key is the knowledge of the prime factors of n (traditionally, n is the product of two prime factors p and q of similar size). Formally, the private key is really the combination of the modulus and the private exponent d, but if you know n, e and d then you can recompute the factors p and q.

Therefore, if two distinct public keys share the same modulus (hence the same factors), then they have the "same" private key, in the sense that anybody who knows the private key for one of the public keys also knows the private key for the other public key. Thus, the two keys are "the same" or at least correspond to the same private knowledge.

So you can, indeed, claim that the RSA modulus alone uniquely identifies a private key, hence (presumably) a private key owner.

However, you must take care that while a private key is normally known to a single owner (otherwise it is not really "private"), a single person may perfectly own several key pairs. In particular, when a certificate is "re-issued", this really is a brand new certificate, which may or may not contain the same key. This depends on the CA procedures: some will reissue certificates with the same public key, while some others will insist on the generation of a new key pair. You cannot reliably assume that when a server "renews" its certificate, the new certificate will include the same public key.

Also, the notion of "modulus" is specific to RSA, and does not apply to other pubic key types, in particular EC keys (used e.g. for ECDSA). If you want to identify things by public key, you are encouraged to simply use the whole public key, as encoded in the certificate.


Why should I hash passwords? I've read that every good web application should hash passwords. I found many articles about hashing.
So I started implementing hashing on my website and then I asked myself why should I do it? When a user sends his or her login (name+password) to the server, the server loads the password of the given user name from database and then compares passwords. There is no way how the user could get password from the database.

Most likely I'm misunderstanding the concept, so can anyone please tell me why anyone should be using hashing?

For any reason, your database may be compromised and its data may be obtained by someone else. If the passwords are in what we call plain text, you will have leaked a piece of sensitive information that your users have trusted you with: their password (which is very likely to be a password shared in multiple services). This is a very serious issue.

Instead of plain text, passwords are typically hashed with an one-way hashing function. If the cryptographic function used for the hashing is strong, then the passwords are much safer, because even if someone gets their hands on your database, it's computationally infeasible to calculate the passwords (given only the hashes).

On the other hand, the hashed information remains useful to you: Because the same hash function will always yield the same hash for the same input, you can still hash any attempted password and compare the result to your saved hash to verify a user's authentication attempt (without knowing the correct password beforehand).

Of course, just hashing is not enough nowadays. There are lookup attacks that often make decryption (of hashes created from predictable passwords) very feasible. To counter these attacks, each password is hashed together with a unique randomly generated piece of input (called salt). The salt is stored in plain text in the database and it doesn't have to be secret, because its main purpose is to render precomputed hash dictionaries useless.

Almost all serious platforms use hashing and salting to store their users' passwords (unless they make use of something different but comparably secure that I'm not aware of). Incidentally, this is exactly why you can reset your password in various services but almost never recover it: The hash can be overwritten by the system, but it can't be decrypted.

You should by all means do the sane thing for the sake of your users' security and salt-and-hash your passwords. There are plenty of resources online that explain the process and the pitfalls in detail. One of them is "Secure Salted Password Hashing: How to do it Properly".


Are old API keys in git history a security vulnerability? I recently made the mistake of leaking my Mailgun API key in an open-source GitHub project.  I immediately invalidated it, but Mailgun support has asked me to take the additional step of deleting my GitHub repository.  So far they have refused to re-activate my sending domain until I do this.

Why is this so important?  It's admittedly embarrassing to have that in my public record, but how could it be used against me?

Update: Mailgun is now telling me that an old API key is not a problem.

Either it's safe to publish an old API key on the title page of New York Times, or they don't actually have a correct invalidation procedure.

Users often stick with API keys for years, almost nobody's going to replace them unless something really bad happened to those keys, e.g. they were stolen or leaked. In this case, a new key would be issued and an old one must not be valid anymore (hence invalidation) for anything API-related from the very moment a new key was issued. Add an hour or, heck, even a day for all sorts of CDNs and caching, it still has nothing to do with deleting a Github repo.

Regarding some suggestions in comments,

  New keys may be computable from old keys

An API key itself is just a random sequence of bytes. A new key should probably be computable from nothing except pure enthropy. Anyway, an old key is a wrong base for new keys. If a new key depends on those old ones, they'd better think once more on the design of their API auth.

  Mailgun may be afraid that people will try the old keys against their server, which would increase the server load.

Anyone can try an arbitrary random sequence of bytes against an API server. Processing an invalid API key once in a while must be affordable for an auth server. There are also methods and even products which help to protect against brute force if it's a real problem. I don't think having an old key leaked will somehow significantly influence the server load (except if their only server is a Raspberry Pi instance).

What if the key isn't leaked but stolen? Do you have to convince the thief to delete an old invalid key from their databases? This is ridiculous. Mailgun has no reason to require that.


One time password question Suppose F(X) = (5X) mod 9 is used to generate a one time password.

I am supposed to generate the first 8 values using the above formula, starting with the seed value of F(5)

Well I know that F(5) = ( 5 * 5) mod 9 gives me 7. Thats my first value. But what about the rest of them?

I know what the answers will be, but I'm not sure on how to use the formula to get these values?

Answer: 5,7,8,4,2,1,5,7

For the rest use formula:

f(x)=(5*x) mod 9

For example if you have f(5)=7 the next step is

f(x)=(5*7) mod 9 = 35 mod 9 = 8

and so on


How does one properly check foreign USB Drives before getting them in your Network? Is the presented approach considered "safe"? Current Situation:

I´m currently employed at an Hospital and with rising danger of ransomware etc. spread by usb drives we decided to block all USB-Ports (roundabout 600 Clients/Windows only) via Symantec Endpoint Protection. This blocking can determine if a device is a HID-Device (we use Smart-Card-Keyboards, Fingerprint-Mice and Voice Recorders which rely on USB in crucial areas where these Devices need to work, Input Devices like normal Mice and Keyboards are mostly PS/2) or a Storage Device. If It´s anything other than a HID-Device the Port gets locked. Also you can grant USB privileges for certain Users/Computers where they are absolutely necessary (Admin PCs, Technician PCs, etc)

Current Problem:

It´s common Practice that users (Doctors, Managing Employees) come in with their private USB-Sticks to import data, like medical studies, presentations, pictures, etc. and want them imported in the System (simply saying no is not an option unfortunately) which is obviously a pretty huge security Risk

Current Solution:

There is a specific Computer that is in a completely separated network where users put in their drives and they get scanned by SEP, if it´s check came out ok, an admin puts the drive in his PC (!) and copies the files to the network share the user needs. Obviously this is also not very secure, not only are we relying only on SEP for Protection but also this method is prone to BadUSB Attacks etc.

What i wanted to do

To securely integrate these foreign USB sticks I thought of a combination of different approaches:

Step 1
The user has to physically go to a First-Level-Support Employee which uses a Raspberry Pi (locked in a box with high security Locks that only IT-Managing Positions have access to the Keys) where CIRClean, (https://github.com/CIRCL/Circlean) an Open Source "USB Sanitizer" made by the Luxembourg Government, would run on and USB Ports are placed on the outside of the Box. This Raspberry Pi distro should strip all files from "dangerous" things like Makros in Word/Excel Files or Convert PDF Files to HTML (and stripping possibly embedded Javascript) and Copy these "sanitized" Files to another USB Drive now considered "probably safe".

After this step the user can take back his Drive and further working steps get done by the First Level Supporter. This first step should get rid of more "unsophisticated" attacks, like BadUSB, makro-viruses and so on.

Step 2 (AirGap1)

The First Level Supporter gets the "probably safe" USB Stick to a Machine running Qubes-OS (https://www.qubes-os.org) which is configured so that the USB-Controller is a separate VM. This Machine would then automatically check the USB-Drive with various different Antivirus applications. This should allow us to check for more sophisticated attacks like good programmed Rootkits. After the automated script running various AV-Checks the First Level Supporter takes the now "known" to be safe USB Stick and gets to a third Machine

Step 3 (AirGap2)

This Machine is a regular Windows PC that is in the Hospitals Network, SEP is installed and performs another security check on the drive before it gets Mounted, afterwards the Employee just drags the Files to the Destination the User wanted them and is finished.

Why I´m here

Unfortunately CIRCLean sounds like a neat tool but I could not find a version that runs properly (I´m not alone with that, I cannot post more than 2 Links but just look at the issues on Git).

So after all this background story, where coming to my Question:

How does one ensure foreign USB Drives are secure ? Is my approach any good, and if so, how would you "switch out" the non working CIRClean Part?

I would suggest going for the raspberry route. But instead of requiring administrators to perform the action, this could be constructed as a self-service station instead, of course locked with high secure locks and such too.

As the raspberry pi is not x86 it cannot run malware destined for windows, linux or mac PCs at all. It can run malicious scripts, but thats another thing and can be blocked.

Configure the raspberry pi to have a touchscreen, so the user can select files he want, and then make sure to block all keyboard access.

Now to the trick that will make this completely safe:

1: First, you restrict the interface to only show files of specific permitted file formats. For example (jpg, png, gif, tiff, svg, bmp) (doc, pptp, etc).

2: For pictures, you can use GD to convert from all known image formats, to PNG: (even PNG->PNG). This will strip off any malicious data that can be contained in these files, as only the raw picture data is copied over, not any metadata. (Note that you need to convert the picture to a plain GD object first)

3: For Office files, you use a Macro stripper, to strip off any macro data, and then use a document converter to convert from DOC->DOC, PPTP->PPTP etc. You don't need to use CIRClean, theres other macro strippers that can be used.

The reason you should use a converter to convert to the same format as the source format, is that such conversion will still require that the file contains valid data for that format, so for example renaming lets say virus.exe to virus.doc, will render a empty output file in this case.

This will completely cleanse the files. And this are also immune to "BadUSB" attacks as long as you configure the raspberry pi to not accept keyboard input. Mouse input will be mapped to the touchscreen, which have a very limited interface to select files.

To prevent any malicious USB from leaking secret data, its advisable to only allow copy in one direction, from USB to home dir, NOT the other way around.

So here comes the complete idea:

The user walks up to a self-service USB terminal (that is scattered around on the hospital). Insert his USB, on the touchscreen, the user selects the files he want. He can only see files of permitted file types.
After that, the files selected, are cleansed, and then copied to his "home folder". The login could be done with smart-card.


LDAP and anonymous bind for PCI compliance We have to setup a central auth for PCI compliance and I'm wondering if it's ok to allow anonymous bind or should I create a user to do the bind for the services needing ldap?

Allowing anonymous bind might permit an unauthorized host to perform authentication attempts if it has access to the LDAP port.  This really only opens a brute-force attack vector, which should be mitigated by the account lockout requirements of PCI DSS 8.5.13 and 8.5.14.  In addition, you can presumably document the network segmentation to show that only relatively trusted networks have the access required to take advantage of LDAP.  You should be able to demonstrate that your PCI DSS 10.2.5 controls are sufficient to detect attempted misuse of the LDAP authentication channel.  You must, of course, use LDAPS (LDAP-over-SSL, 636/tcp) instead of LDAP (unencrypted LDAP, 389/tcp) to be compliant with PCI DSS 8.4.

With those four mitigations in mind, you can probably make a good case for anonymous bind.  Frankly, the alternative is having to store and protect bind credentials on all your endpoints, which in my opinion is more of a problem than anonymous bind.

As with all things, your QSA may disagree, and that's who you have to convince. Documenting controls and reasoning behind your decision should help.


Pen test cell-phones A customer has asked me to conduct a pen-test on the phones of their employees. The customer's target are the text messages within their employees phones. The text messages are stored on the SIM for security reasons. Physical access to the phones is allowed only when the phone is turned off. The customer has asked for what approach we're going to take on conducting the pen-test.
I came up with the following approach but it is not satisfactory.
Such as breaking the pin-code which is asked when the phone is turned on by cloning the card 1000 times and brute-forcing the pin-code. The idea is that if after 3 tries the first card locks. I then continue doing the same with the second card. This way I have more chances for brute-forcing the pin.
First question:
Is this a good idea or are there any flaws in this approach?
Second question:
Can you advise me on a better/easier/cheaper approach?

A few questions come to mind with the brute force attack:

What is the length of the PIN
What is the timeout length

Now for actually trying to break into the phone I would first look for wear on the screen protector, smudges, or wear on the keypad (specifically numerals).  If you are allowed to match it to an employees desk I would look for written down passwords and/or calendars marked with what appear to be important dates (birthdays and anniversaries).  Also, looking at the wear on the keypad of their computer keyboard could be a large indication as to what their PIN is, namely because humans don't like to have multiple passwords for multiple systems.


My college hosts a critically vulnerable service. I warned them 4 years ago. What should I do? Four years ago, I discovered that an applet on my college's website sends SQL queries directly to a server application. The databases contain nominal and personal information about students and grades, and possibly more (SSNs?), but I'm not sure as I haven't tried anything, because I'm a good person.

In December 2010, I warned them of the potential vulnerabilities, and they thanked me. I know for a fact that the CTO was warned.

Four years later, the application is still up. The mechanics haven't changed, and the (deobfuscated) packet capture still shows SQL requests going to the server from the client. It could be that the server somehow checks them against a list of valid requests or something, but I can't be sure, and there are probably a few tripwires that I don't want to risk triggering without formal authorization–which is not something that I expect to get.

What should I do?

If you are no longer a student in that college, then you could sue them for not applying due care in the handling of your personal data. Technically you could also do that if you are still a student there, but no longer being a student means that they would have a harder time retaliating if they are so minded.

The crucial point here is that being a potential victim gives you an acceptable reason for putting your nose in these matters. Otherwise it would be all too easy to flag you as an Evil Hacker™ and handle the problem by throwing you in the lawyers pit, instead of actually fixing the software.


Is it possible to identify my cellphone model if I connect to wifi? Would it be possible for the IT department to trace the model of my cellphone if I connect to the wifi provided by the company?

The answer is yes; they can definitely see what phone you are using if they know where to look.

In addition to the MAC OUI, which reveals the manufacturer, the device may advertise its hostname as the manufacturer and model number (looking at my network's DHCP clients, I see some right now, e.g. a device named "SAMSUNG-SM-G890A"). Also, if you are browsing HTTP websites (or using apps that communicate over HTTP), the user agent string in the HTTP headers may contain the device manufacturer and model number. Some apps may also transmit this data for analytic or telemetry purposes.


Implementation of a FREE web filter I just want some advice for the implementation of a web filter for a school network. Just want to block some contents and url. A free tool should be fine I guess.
Any recommendations?
Thanks!

Squid/Squidguard is kind of the de facto standard for this kind of thing. It's free and runs on Linux. This can work if your intent is to filter all traffic on the border of your network instead of installing a filter on each machine.


Intrusion Prevention Logs I received an email from a client with IDS logs. I was wondering if the following log has any real indications of the server being compromised. If there are certain things I can do to diagnose the situation I am open for any suggestions.

###Log Start##
02/28/2011 08:58:42.352 - Alert - Intrusion Prevention - Possible port scan
detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 8897, OPT - TCP scanned
port list, 8869, 8867, 8863, 8898, 8899
02/28/2011 09:08:01.144 - Alert - Intrusion Prevention - Possible port scan
detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 12470, OPT - TCP scanned
port list, 12403, 12454, 12462, 12466, 12472
02/28/2011 09:09:20.080 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 14037, OPT - TCP
scanned port list, 13972, 13970, 14023, 13979, 13983
02/28/2011 09:10:58.496 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 15749, OPT - TCP
scanned port list, 15755, 15715, 15697, 15717, 15751
02/28/2011 09:14:24.112 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 19277, OPT - TCP
scanned port list, 19239, 19266, 19269, 19273, 19275
02/28/2011 09:15:50.592 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 21033, OPT - TCP
scanned port list, 21071, 20965, 21111, 20955, 21090
02/28/2011 09:26:15.016 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 37244, OPT - TCP
scanned port list, 37260, 37278, 37235, 37238, 37247
02/28/2011 09:28:53.592 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 40411, OPT - TCP
scanned port list, 40468, 40453, 40454, 40455, 40465
02/28/2011 09:29:19.128 - Alert - Intrusion Prevention - Possible port scan
detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 41163, OPT - TCP scanned
port list, 41217, 41216, 41178, 41137, 41138
02/28/2011 09:40:38.240 - Alert - Intrusion Prevention - Probable TCP FIN
scan detected - x.x.x.x.x, 443, OPT - x.x.x.x.x, 55567, OPT - TCP
scanned port list, 55555, 55553, 55582, 55589, 55561
###Log End##

There are no indications of a compromise in the logs. They only show at worst port scanning. This is the act of looking for open ports, the next stage if open ports were found would be to check the version of software running and then to try to exploit potential vulnerabilities to gain access. This would show up in the logs as well (as long as the IDS has not been incorrectly tuned).

However, it would be worth looking at the web server logs to see if the source address of this activity corresponds to a valid IP using the web server. Sometimes when clients try to connect to a service they make a connection on the remote port (in this case 443) and the server attempts to open up a high port for the return traffic. If this is blocked the connection may try to establish a different high port and so on. This can have the effect of looking like a port scan.


What are these incoming connections in my wireless router logs? I am analyzing my incoming connection log from my Linksys E1000 wireless router. [Bonus points if anyone can tell me how long these routers store logs because I can't figure it out anywhere, so I can't really correlate well.]

I have three entries. One is a known entry as it shows my friend's ISP and says the port that I have Mumble server configured on.

The other two entries are from unknown IPs. One resolves to a Serbian IP. The other one somewhere just as concerning. The destination port is 54876.

What am I seeing here? The only port I have forwarded in my router is for Mumble/Murmur. Isn't everything else implicit deny? What is port 54876 used for and is this scanning or what could this entry be?

The syntax in the entry is 'External IP' from wan to port 54876 is accepted

One on several possibilities is that it is just the result of an outgoing connect.  You connect to port 80 on a web server(or any other port/server), but on your end the connecting port is randomly selected.

Logs on routers are usually very short lived, they usually have room for a few 100 or maybe a 1000 if your really lucky and that is it.

If you want to do some serious analyst you will have to find a compatible open source router firmware like Tomato or DD-WRT.  Otherwise you probably won't be able to access the logs.

Large groups of bot nets scan ports and ips randomly to avoid being detected as port scans.  In a year or so I have 62,000+ ip address attempt connect to different unused ports.  I add 100 a day or so.


Wifi box produces three SSIDs? While using a friend's wifi, he said I should use his SSID, let's call it XYZ's Wifi. When I started my Macbook Pro, three SSIDs came up. Two were called XYZ's Wifi and the third was called XYZ's Guest Wifi. One of the ones called XYZ's Wifi disappeared within 1-2 seconds and did not reappear. But the "guest" wifi did persist and I was told not to use it.

Are there actually Wifi boxes out there that support two simultaneous SSIDs?

I advised him that maybe a neighbor is using a router with the same/similar name to trick him, and capturing packets.

How can I tell whether they are actually both in the same router, or different routers?

On the Mac it seems we don't have an iwconfig command, so I don't know how I can print out the MACs of these router(s).

Thanks.

Are there actually Wifi boxes out there that support two simultaneous SSIDs?

Yes, this is also a major feature in more advanced wireless systems.

  Two were called XYZ's Wifi and the third was called XYZ's Guest Wifi. One of the ones called XYZ's Wifi disappeared within 1-2 seconds and did not reappear.

That probably relates to the mechanism by which this usually happens. Each broadcast of an SSID uses a different MAC address. It's possible that two addresses were spun up with the same name, then one of them changed to have the guest name.

Having these different identities allows for different settings including varied speed, security, and other settings though security is often the focus in being able to permit an open network and an authenticated network in parallel.

  How can I tell whether they are actually both in the same router, or different routers?

Ultimately, checking the router configuration is the appropriate answer to that question.


Security with sending faxes from pc I sometimes need to send faxes and thought I would buy a modem for doing this and use Windows Fax and Scan software that comes with Windows 10. Does the type of or specifications of the modem determine if my data will be secure? I don't really understand how security works with faxes. Will the data I send be encrypted when sending a fax?

No, data sent by fax is not encrypted. A fax is essentially a series of pixels sent as tones over a phone line. If the phone line is secure, the data being sent is exactly as secure as a phone conversation - with exactly the same risks of being overheard, but a slightly different requirement for receiving it. If an attacker can intercept the message, they can get the same output as your intended recipient.


Should I mount my mac Truecrypt Volume elsewhere? I've read in various places to not mount your truecrypt volume in the same place as your Dropbox or Sugarsync folder. I believe this only matter for Mac/Linux, but I need some verification.

On a Mac, when I mount a container, it states that it's mounted at '/Volume/Container_Name'

Does that mean it's mounting inside the dropbox folder itself even though it says Volume?

Because when mounting, there's an option to mount to another folder, see screenshot here: http://cl.ly/1i3v2n2Y0G2e2102272k

So should I be mounting it to that other folder? If i don't choose that folder, will the container info be left in the dropbox folder?

If I understand your question correctly....

You shouldn't mount an encrypted volume, something you presumably value a great deal, into a folder where a third party application uploads the your unencrypted files to "the cloud" At that point your files are only as safe as Dropbox or Sugarsync.

So, you CAN mount it there... but only if you want your stuff to automagically start uploading.


Can I describe the PDF's certificate-based signatures using W3C's DSIG Core? Can I map the specialized specifications of PDF's certificate-based signatures into the [XML DSIG Core] standard?

I'm imagining PDF as an "XML file analog", to be mapped into the W3C's ecosystem.

... Expressing in another words,  is Adobe's PDF signature thingy in any way compatible with general-purpose file-signing tools specified at [XML DSIG Core]?

Notes:

As @SteffenUllrich suggested, a "real-world use case" will be fine... But this question is about simplifications and abstractions, so the better is to (only) imagine a use case.

Use case: a published article of a government gazette. The article is a digital document with legislation content. The publsisher house must to publish in two formats, PDF and EPUB (or other XML-based format), both with the same signers, and they using the same tools and same certificates.

The technical staff of the publisher house must to answer the present question, to ensure to auditors (as well as citizens, lawyers, etc.) that both signatures (XML and PDF) will use the same tools and will have the same level of reliabilty.

The "analogy map" is also to move from  the "strange Adobe-centric universe" to the W3C's ecosystem view.

Of couurce, each format have different fingerprints (different checksums)... Imagine the PDF and EPUB as  products of the same matrix (the content must be the same), they are like "twin sons" that will use same infrastructure whenever possible, reducing production costs and audit costs.

... In the real-world the "twin sons" like XHTML and PDF are producs from a XML matrix, by XSLT and Prince convertions, and, after convertion adding a commom workflow to use digital certification (signatures).

The publsisher house must to publish in two formats, PDF and EPUB (or other XML-based format), both with the same signatures, and authors using the same tools and same certificates.

Given that the PDF and EPUB content is different (i.e. different bytes) it is impossible for both to have the same signature.  But since they are probably generated from the same source document one could create a signature for this common source document. If the instructions on how to create the PDF and EPUB from this source are relevant one could also sign these instructions together with the source document.

If it is relevant that both the PDF and the EPUB have signatures which can be verified in the reader applications then one must generate signatures which match the different standards used in PDF and EPUB. It is probably possible that the same certificates can be used for this. But it might be that there is no single tool yet which can handle both PDF and EPUB and create signatures in the appropriate formats - in which case it should not be too hard to use two different tools with the same certificate.

  But this question is about simplifications and abstractions, so the better is to (only) imagine a use case.

Abstracting this use case again the OP is essentially asking if it is possible to have the same signature for essentially the same content but provided in different formats, i.e. different bytes. In this case the answer is no, i.e. since the bytes are different the signature will be different too. It is also not possible to derive one signature from the other.

It is possible though to use the same X509 certificate to add a format-specific signature to the various formats which then can be verified in readers supporting such signatures (not all do). This is at least true if the signature is based on X509 certificates (it commonly is) and the common X509 certificate fits the requirements for signing in both formats (which have usually the same requirements).


Using Tor with Tails only as a client I'm running a VM with Tails to use the Tor network with the Tor browser. I've heard about the risk of getting an exit-node myself and the tipp to deactivate this option.

Where can I do this in tails?

When you use Tails it acts purely as a client. No need do deactivate something. Everything else would violate user expectations and threaten your privacy.


Disclosure and HTTP status codes Disclaimer: yes, I have checked the Which HTTP status codes are interesting from a security point of view? which sounds relevant but not entirely.

These days it's supposed to be a good practice to not disclose extra data for non-authenticated users. Eg: email addresses for "forgot password" feature: when instead of saying "this email is not registered" hence disclosing that a user is not there/or is there you always return the same message like "check your email with the password reset link".

So far so good.

But what about HTTP status codes, more detail: for 404 vs 403.

Say you have some secured area where multiple people have different access to. Say it's a user management for multiple organisations.

And if you have a sequence based primary key for users that is used in the link to user's profile, eg: /admin/users/42 then you might iterate over the counter and comparing the status response code 404 - for non existing, 403 for existing determine how many users are there.

It's a simple example and I think there are a lot of similar things around.

So the question: should we prefer security over semantics and use only 403 (or 404) exclusively in all cases?

You practically answered your own question, It's completely viable to use a plain response for harden your system against an analysis attempt.

Other option could be: Use a random UUID to identify your users publicly and keep the primary key only for internal use. A UUID of 16 characters should be enough to mitigate this type of attack.

Finally you should consider log all the failed requests to get users information (403, 404).

Now, What method is better for your situation? is something that you have to decide, consider the next points:

If your system is already in production phase, then it could be
better make a little patch to formalize all the user failed requests
to a 403/404 response.
If you are in the design phase then you could opt for the second
option and build a cool hardened system for your users.


How to prevent an arp poisoning attack (from the client's POV) How can I defend against an ongoing arp poisoning attack on a network that I am connected to?

That is possible by defining static ARP entries for local IP's you are connected with, on Windows machine you could define static ARP entry using netsh .

EX:
netsh interface ipv4 add neighbors "Local Area Connection" 10.1.1.1 12-34-56-78-9a-bc


What is Win32/Kryptik.FM? ESET detected this trojan, but I cannot find any information on the Internet on what it is.  Google is only returning links on how to remove it, or what files have been detected to contain it.

Semantec's threat database doesn't have it listed.  Same thing with Mcafee's Threat Library.

What website can I go to that will tell me what this trojan does?

You can upload the infected file to VirusTotal and get results from more AVs, maybe you'll get another names for the mallware. For example in this report, the reporter states that is it Trojan.GrayBird - unfortunatelly he does not explain his statement. I you search VirusTotal for "kryptik" there are few comments that it is a fake AV.

  Backdoor.Graybird is a back door Trojan Horse that gives its creator unauthorized access to your computer. The existence of the file, Svch0st.exe, is an indication of a possible infection. Backdoor.Graybird is a Delphi application.


Desktop App with SQL Server security issues I'm in a discussion with Information Security team about a legacy Desktop Application accessing a SQL Server database directly using LINQtoSQL.

The Information Security team insists that there are many security vulnerabilities in a Desktop application and a SQL Server with open port to network communication.

As a +10 experience developer I can only list this risks involved:

Unsigned Application: company's authority can't be certified allowing attacker to create a copy of the app with malicious codes.
Unobfuscated code: the attacker can decompile the app change its code an inject malicious codes.
Open port: can be exploited with an stolen SQL SERVER user + password to Data leak

But I know how we can mitigate all this issues instead of spending the enormous effort to migrate the whole desktop app (+8 years old) to (intranet) web app.

Do you guys have further arguments against this client server architecture?

Unsigned Application: company's authority can't be certified allowing
  attacker to create a copy of the app with malicious codes.

Keep in mind an attacker could do the same with a web application if it isn't properly secured with TLS.

  Unobfuscated code: the attacker can decompile the app change its code
  an inject malicious codes.

Obfuscated code is a relatively small hurdle for somebody who is already motivated enough to reverse engineer it. I'm not really sure what would be changed or injected in this case.

  Open port: can be exploited with an stolen SQL SERVER user + password
  to Data leak

Your users likely have access to credentials for the database, whether they are hardcoded in the app or user provided.

I think the real issue is that the database is directly exposed, and your infosec team is probably worried about access controls and auditability. A web application abstracts away the database and allows for business logic to be put in place. You don't want users to, for example, either maliciously or accidentally, delete the entire database, modify all records, add questionable/unvalidated data etc. Or maybe users should have these permissions, but you want a detailed log of who, what, and when.

While some/all of these things may be possible with the database's built-in controls, it will likely be much more complex to manage and more error-prone. I think it depends how much effort you are willing to spend configuring a database versus creating a web application. It also depends on the trust level of the users who have access.

This question and the answers discusses this issue in much further detail.

Also, a desktop application is not sufficient to employ controls and validations, as it is under control by the [untrusted] user. Client-side logic can be modified or bypassed entirely with a direct connection to the server or by changing the application. Credentials and other "secret" information buried in a client-side application can almost always be recovered. If it's encrypted, it can easily be grabbed out of memory when it is used. Or, if network comms to the database aren't encrypted, it could be sniffed there. For these reasons, any important logic must always be validated on some sort of server backend.


Bench marking Snort and other IDS/IPS I am looking for facts and figures of research or surveys done which have bench-marked Snort with other IDS/IPS on various parameters like overall performance, accuracy, speed, documentation, scalability etc.

That's a very general question.

Your concern should not just in relation to Snort, it all depends on the platform that you install it on (o/s - yes it does run on Windows, CPU, memory etc) and what elements (pre-processors for fragmentation or stream reassembly) of Snort that you enable (look in the configuration file, typically /etc/snort.conf, for more information) and what rules you enable or add.

If you want to test it, I'd suggest downloading Security Onion (http://securityonion.blogspot.com), a Xubuntu-based Network Security Monitoring distro, as it comes with both Snort and Suricata. It is a fantastic project and so easy to learn with as everything is essentially pre-configured. (Disclaimer: I try to help out with the Security Onion project).

Snort is very scalable and I know is actively used in networks with over 20gb/s but remember the platform aspect above.

Additionally, both Snort and Suricata have active mailing lists for their users where such performance issues are actively discussed.

I'm sure vendors like Tipping Point, Sourcefire (commercial aspect of Snort), Enterasys (if they're still around), Cisco etc have comparison whitepapers on their sites but beware their bias.

Regarding the 'rule size' and 'accuracy' aspects, these are becoming like the AV industry a little now with the "I'm bigger than you argument".

Here's some links for you -

http://www.aldeid.com/wiki/Suricata-vs-snort

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,7913.msg42307/topicseen,1/

and an old one

http://www.infosyssec.com/forum/viewtopic.php?t=14


Are CryptoKey Objects stored in IndexedDB stored in Plain Text on the users machine? I'm considering storing a sysmetric encryption key in the form of a CyptoKey Object with extractable set to false in IndexedDB and I was wandering whether this is safe or not.
The questions that I didn't find the answers to are:

How are the keys stored on the users computer ? in plain text ? encrypted ? or as function states ? if the implementation is browser dependent, how does chromium do it ?
How easy is it for a malware on the users computer to retrieve the key from the storage ?
if this comes down to endpoint security, how secure is chromium's implementation in this sense ?

most of what I found so far can be linked to this answer

"I need to access the key from the js environment without the user entering an encryption password"
As @mti2935 points out, it is unencrypted in major browsers, and basically impossible at this point in time to achieve this goal without storing the key-encryption-key 'somewhere else'. I second that observation (for Firefox up to about 2019 at least, last time I looked at indexed-db).
Here is a possibility that wouldn't require you to store your long-term key un-encrypted: it won't allow your user to get away with 'doing nothing' if they want something more closely resembling security...

an input type=password field, which possibly the user might choose to 'remember' in their password manager^ - this becomes the long-term key input
this long-term key is then derived using a built-in WebCrypto PBKDF2, and used to decrypt the application symmetric key stored in indexed-db - you might wish to use another pbkdf such as Libsodium's Argon2 implementation, crypto_pwhash

^ If the user chooses to store the long-term key input (as a 'saved password') in their browser, then they won't need to type this again. It will be stored encrypted, and possibly further secured if the user applies a password for the internal password database key.
One obvious downside to this is potentially the repeated use of the pbkdf, which may interfere with the user's experience, depending on how 'hard' you tune it. Another is the static nature of your long term key, and what would be required if the user wishes to update any of the inputs. Since you don't specify how you're using the symmetric key that you wan't to store, I'll assume it's to access other encrypted data stored locally. (If you edit your question to clarify, I might update this answer.)
As to how the initial long-term key input is derived, you might consider having the user provide additional material via a key-file that they hold. You would then take the secure hash of any key-file that they choose, using a local file picker and the built-in keyed hashing functions.


TLS record layer implementation I have some general confusion about TLS protocol. One question is about session id. Should a session id inside the TLS hellomessage have a session id length field? I do not read anything about it in the request for comments on TLS. If there a client is not resuming a prior session then it says it should remain 'empty'. What does that mean? Perhaps id session length (itself a 1 byte field) of zero, followed by no session id field? Or a session id field with zero byte? Or should I remove the session id fields completely?

Additionally in this question https://stackoverflow.com/questions/35361617/how-to-format-a-tls-record-to-be-sent-with-winsock-for-https I have received TLS fatal alerts 70, regardless of the protocol combinations I offer? If I reverse the byte ordering of the plain text I get a fatal alert for 10?

Any help is appreciated.

There are three (soon four) versions of TLS, each with its own RFC (plus a retrospective historical one for SSLv3), but at the basic record level for unencrypted records -- which is, initial handshake records through first CCS or alert -- they are the same.

RFC5246 for TLSv1.2 in the section on ClientHello defines at the top of page 41 that structure (ClientHello) to include SessionID session_id. Similarly for ServerHello at the bottom of page 42. Note that HelloRequest is also classified as a hello message (and a handshake message) but does not contain a session_id or indeed any body at all. SessionID is defined on page 40 as

opaque SessionID<0..32>;

You should recognize that syntax as a variable-length vector previously explained in 4.3 which also explains how the length prefix of every variable-length vector works.

'Empty' means no bytes in the value i.e. a length of zero, encoded as a length prefix of zero followed by no (or equivalently not any) content. If you think about the encodings defined in section 4 it is obvious that you cannot omit a field from a fixed structure; some (not all) variable-length fields can be empty, and some (only some) structures have variants where you use only the fields of the one variant applicable in a given situation as specified. However, the extension field in Client or Server Hello is defined as a variable-length sequence of items each of which begins with an explicit (2-byte) type, so you can include or omit, and reorder, extension items within the extensions field -- at least for encoding; whether a peer will accept a set of extensions is up to that peer.

If you want to implement TLS you really need to understand the applicable RFC(s) for the version(s) you want 2246/4346/5246, plus several related ones like 3546/4366/6066 for extensions, maybe 4492 (and SEC1 etc) for ECC, maybe added suites like 5288/5289 for GCM, etc.


Can I get a public key from PGP signature? I have a PGP signature of a known message. However, I am not sure who signed it.

Can I get the public key - or, at least, the fingerprint/other way of searching for it on a public keyserver - just from the message and a signature?

Example: I have this message/signature from here https://futureboy.us/pgp.html

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I vote YES on this important measure.

Alan Eliasen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iEYEARECAAYFAlHZCvgACgkQ5IGEtbBWdrF5HgCfc4xhT29ouAWdo1PMlyDKIfaq
pGoAoKig5sCXukrPPoKC1ZYB5CW7BzNL
=WPPL
-----END PGP SIGNATURE-----

Can I somehow find who signed it, just by looking at it?

Yes. The format of the signature is defined in RFC 4880. If you decode the base-64 and interpret the data, you will find that the bytes from position 19 to 26 (inclusive) are the issuer ID in this case:

ID hex: E48184B5B05676B1

which matches the "Long key ID" behind your link. If you convert the ID to base 64, you can find it in the original signature data, because 18 bytes happen to divide evenly into 24 base 64 characters:

ID b64: 5IGEtbBWdrE=
Signature: iEYEARECAAYFAlHZCvgACgkQ5IGEtbBWdrF5HgCfc4xhT29ouAWdo1PMlyDKIfaq...


The non-compliance of the EU cookie law as a finding in a penetration test report? I recently noticed a penetration test report wherein the non-compliance of the European Union (EU) cookie law was stated as a finding under an "other" category. I consider this more of a legal, privacy-related matter and not so much security.

Why would this be in a penetration test report? Are there possible security-related concerns that I'm not aware of?

I don't know of any technical security impact relating to not adhering to EU cookie laws.

Ultimately I think this is mostly down to the discretion of the assessor and the context of the assessment. Privacy issues are security-adjacent and come with similar PR impacts, and may even be judged to infringe upon the rights of the individual, so I think in some cases such findings may be useful.

For me the question isn't so much whether these things should be reported to the client, as whether or not they should be in the pentest report itself. There are other communications channels that can be used to relay this information. It may well be that this was discussed and the client asked that it be put into the report. It could even be that compliance concerns were one of the key drivers to having the assessment done in the first place. Some scopes explicitly include looking for findings that might embarrass the company or its associates (content injection is a fun one here).

I have reported everything from functionality problems to typos (albeit serious ones with vulgar consequences) to clients when doing pentesting work, when appropriate, because ultimately my job is to help improve their system. I don't think it hurts to include this kind of thing in a report because it can always be removed and filed separately at the client's request.


U2F devices: backdoors possible? Following the recent post at ZDNet on Google Titan devices designed and manufactured by a Chinese vendor and potentially prone to built-in backdoors: is it even theoretically possible to inject a backdoor on a U2F device, given the protocols and standards used?

If so, how could such backdoors actually work?

A backdoor is actually quite simple: keep track of the secret key used on the device. Either by generating them randomly and storing them after writing to each device, or by generating them all from a known seed. All of the security of a U2F device is dependent on the device key staying secret.


Is Chrome for Android leaking my phone number? I accidently clicked on an advertisement, and opened it with chrome. It was one of those things where you can subscribe to an App Store for £4.50 a week for apps which are usually free anyway.

This is the app screen (left) with app permissions (right):

App screen shows the last six digits of my mobile number at the bottom.

And this was the URL:

http://ace.jamster.co.uk/m/flappybird/index.xhtml?pid=876&ydr_pid=1706&ydr_cid=6170&tsp=1365269&pubref=n5_FLIP-39615-k66R8UBzO_Bc6rT89xJSWWIL&ydrid=14f43412e6e0efdo14d515ocf246d4d1133

How can I fix this security problem?

The permissions for the Chrome app for Android show that it has access to Identity. Therefore it is able to see your phone number.

Unfortunately Android, differently from iOS, does not allow natively to fine-grain installed apps' permissions (it's more an "accept everything or don't install this app" philosophy). I've read about some wrapper applications such as MoboClean that allow to do this, but I haven't tried them myself.
UPDATE: Android 6.0 Marshmallow introduced fine-grained permissions, which make you able to choose which specific permission to grant to an application.


Code analyzer for Objective C? Has anyone come across a code analyzer that could be run on OS other than Mac to scan for Objective C (for iOS) code?

OCLint works on Linux and OSX. It doesn't focus on security, but integrates with Clang, a static code analyser to do style and security at the same time. Of course, if you don't care about style you can just use Clang to begin with! But if your code is tidy and readable, your security reviews will be a little less painful.

Agnito also scans objective-C, and it costs $0, just like the other tools.

(I am not affiliated with these projects.)


X.509 certificate policies question I asked another question about certificate policy mappings.  This is a different issue.  This is about Certificate Policies.

To quote from the X.509 RFC:

   In an end entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the
   purposes for which the certificate may be used.  In a CA certificate,
   these policy information terms limit the set of policies for
   certification paths that include this certificate.  When a CA does
   not wish to limit the set of policies for certification paths that
   include this certificate, it MAY assert the special policy anyPolicy,
   with a value of { 2 5 29 32 0 }.

So say we have the following X.509 cert chain:

root CA ---> intermediary CA ---> client cert

It sounds like the set of policies possessed by each child in the chain will always be a subset of the parents policies?  Is that correct?

The base idea is that a policy describes the certification process over the whole path, not just at the level of a given CA. Within a given certificate C, the Certificate Policies extension gives the set of policies to which the process which resulted in the creation of C conforms.

During validation (see section 6.1 of RFC 5280), the verifier computes the "policy tree". In simple cases (see below for possible complications), the leaves of valid_policy_tree at the end of the processing will be the intersection of the sets of policies in all certificates in the path (the steps "prune the policy tree" are what really computes the intersection). In simple words, the set of policy which you obtain at the end will be the set of policies which appear in all the certificates in the path. It is quite logical: you can say that a given path conforms to policy 1.2.3.4.5 only if all certificates in the path were issued in ways compatible with policy 1.2.3.4.5, a property that the certificates themselves advertise by containing policy 1.2.3.4.5 in their Certificate Policies extension.

It is not required that each certificate only uses a subset of the certificates from the upper CA. This would be ill-defined, because paths may merge (a given CA may obtain several certificates from several über-CA, and they could contain distinct policies). The intersection work is done at validation, when a single path is considered. Conceptually, there is no path until validation.

Possible complications:

There can be certificates without the Certificate Policies extension.
There can be policy mappings, which allow for replacing some policies with others along the path.
There is a special policy called anyPolicy which alters the processing.
There are extensions which can inhibit anyPolicy, and/or require an explicit policy, beginning with a given path depth.

I have encountered a great many CA which get it wrong with regards to policies; that is, they include in each certificate a (non critical) Certificate Policies extension where they put a unique policy which is specific to that CA. End result is that, upon validation, valid_policy_tree is empty (this is not fatal, since these certificates do not include any extension requiring an explicit policy). This is using the extension as a kind of glorified comment.


Why do we use passwords on sites? I don't have passwords for my personal sites. To sign up a user pick their username and enter their email. There is a logout button if the user wishes to log out. To log in you enter your email and click the link that is sent to your email address.

Why are we using passwords at all especially if we register a users email?

At some point the user needs to be authenticated. The approach that you are detailing will shift this process to the authentication of the email account. Technically it could shift it elsewhere too, but at some point there will need to be a form of authentication.

The problem with delegating the process to a third party is that you place too much trust in (a) their security mechanisms, and (b) the non-secure transport channel for the email. Each of these creates threats that otherwise wouldn't exist in that (a) a poorly protected email host may allow an adversary to access your authentication emails, exposing the fact that your website utilises this mechanism, which means that they simply need to submit a new request, and (b) interception of the authentication email results in the same outcome.

The use of a password introduces a secret that is shared by only the authenticator (your site), and the user wishing to be authenticated. It exists in electronic form for a very short period of time, and within a security environment for which you define the level of protection relative to the threat model.


Why is leaving a passworded SSH over the internet so bad? I've heard multiple multiple times to never leave SSH with a password open over the internet. Why is this so bad?

I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack?

Are there more things to consider than just bruteforce or am I missing anything else?

Why is this so bad?

Because there are tons of bots just scanning the web for open ports and trying to log in, once a scanner bot finds an open SSH port it may be queued for another bot (or botnet) to try to brute force the password. One of the risks here is that eventually, they may succeed in figuring out the password and take control of the server.

  I understand the password can be bruteforced, but what if it is a very
  strong password that would takes eons to crack?

Having a long password is a mitigation technique, however the resources (bandwidth, disk space used for logs and CPU for example) consumption of a brute-force attack can also be damaging.

Mitigation

Some techniques to mitigate a brute-force attack on SSH:

Use a different port, don't get a false sense of security with this, but many bots do search for 22 exclusively. (Related question)
Disable SSH passwords
Require a private key for logging in
Throttle connections
Implement an IPS (Fail2ban and Snort come to mind)
Restrict login per IP address
Restrict which users can log in (different than checking the IP address)


Secure Electronic Transaction (SET Protocol) I've looked into the SET protocol and some of the information are outdated. Therefore, I would like to ask if the SET protocol uses 3DES or AES or just the DES and the RSA?

That seems like a question that can be answered by looking at the specification of the SET protocol. The Wikipedia page for SET:

en.wikipedia.org/wiki/Secure_Electronic_Transaction

lists several official-looking documents at the bottom under "References". You can probably find your answer in there.