The inner workings of iMessage security? This is a very interesting article about the iMessage technology used in Apple's very popular communication devices. So far, there has not been much technical details released by Apple. Hopefully someone here is able to shed some light on it.

What security technologies and protocols are used?
How are the messages encrypted?
Is it truly end-to-end secure? Can Apple or anyone else circumvent
the encryption?

Any other interesting information welcomed as well.

This is incomplete.  But hopefully of some use.
https://wiki.imfreedom.org/wiki/IMessage and https://github.com/meeee/pushproxy (especially the docs section) have done some reverse engineering of apple's proprietary protocol.
Seems that every apple device has a SSL/TLS client-side cert for authentication that setup to be known to apple's push server.  This is used to authenticate you as well encrypt the connection between your apple device and apple's push server.  I do not see anything about retrieving public keys of users you are sending messages to; hence your message is completely readable/editable by someone at apple's servers.
To specifically answer the three questions:

What security technologies and protocols are used?

Standard SSL/TLS certificates.  Apple's self-signed certificate uses RSA 2048-bit public key.

How are the messages encrypted?

SSL/TLS to encrypt the connection between the apple push server and your device.

Is it truly end-to-end secure? Can Apple or anyone else circumvent the encryption?

Yes.  To the best of my knowledge messages are in plaintext on apple's servers.

EDIT: Aug 26th, 2013: I agree this doesn't agree with the official statement made by Apple several months after this answer was written, which stated:

For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data. Similarly, we do not store data related to customers’ location, Map searches or Siri requests in any identifiable form.
We will continue to work hard to strike the right balance between fulfilling our legal responsibilities and protecting our customers’ privacy as they expect and deserve.

Personally, I don't place much trust in this statement where they got permission to report from the US government.  This has nothing to do with my opinions of Apple, but mostly stems from me personally placing little trust in a closed-source proprietary protocol whose inner workings and technical details are kept secret.
Maybe the statement was entirely true, but it seems strange in terms of why are Apple iMessages allowed to be encrypted but LavaBit apparently had to shut down under gag order or secretly disclose email of people like Snowden.  Would I expect Apple to suddenly stop allowing iMessages on principle under a court order they do not want to comply with?
Or it could be technically true, but fails to mention backdoors installed per gov't orders that allow them to remotely retrieve private keys from Apple devices (possibly only in the presence of a court order/gov't request).  Several observers have mentioned when you get a new iOS device, once you setup your account (either by knowing your password or doing a password reset with a few low-entropy security questions) your device automatically retrieves all your past iMessages from the cloud.  That implies Apple definitely has your messages and your private key stored at their end in the cloud -- granted the messages could be encrypted and your private key could be password protected (stored twice -- once with password, once with answers to security questions).  Granted anyone at Apple's end frequently verifies your password (e.g., any time you log in to an Apple Store), most passwords are weak, and it wouldn't be for Apple to either log or brute-force a password.
Or it could be a completely false press release that Apple was told to release per order of the US gov't so criminals would feel safe using iMessage for illegal activities.  Many observers questioned the veracity of the leaked DEA memo (as well as why would a DEA agent would leak it when it seems to tell drug dealers how to safely message without gov't intrusion).


Is a fake address/info to an ISP/service enough to be untraceable in theory? It got me thinking recently. Wouldn't a fake/incorrect address be enough to deter investigating/finding a criminal via cyberspace? The reason we know it's so easy to find someone is because they give their real address/info to an ISP -- so obviously with this info they can easily get to someone's residence.

What if you sign-up for some kind of ISP/service while:

1.Giving a different name/alias than your birth/real name (usually allowed).

2.Do so online (anonymity -- you can use any kind of library, cafe, public IP, VPN, etc. with a throaway device) and thus nobody can see/know who is signing up and can't act as a witness for someone.

3.Use some prepaid card/etc. that was also registered with an alias and has no real address linked.

4.Do something blatantly illegal using this ISP (which doesn't have a social security number since it's not require -- i.e., you can get a phone service with ISP and do not need SSN/etc. in the U.S. -- and also no real name, number or address to where they can provide authorities any real kind of leads).

How could they find the person? If they use the ISP given, it can be local or remote. If it's remote they can try and ask the company for info, but the company will only give the info they got and it's insufficient to have any possible leads with an alias; no social security number; and no real address.

You can argue it's possible to narrow down where the person could live, but they could move. Also, nobody knows what they look like and could be using highly anonymous means (i.e., very secured operating system leaving no means of a network trace). With all of this it seems theoretically impossible to identify any criminal. Payment method has no easy trace; everything could be done online these days and fake/wrong addresses are among the easiest things to provide. Face is unknown due to internet anonymity from the very source to the very end of the means of a crime.

Using the internet isn't like a phone call -- you can't merely triangulate/narrow down an exact location a person is connecting from if there is no way to find GPS traces/etc. from such a device.

On TV shows like Criminal Minds they make it seem like they can super-easily trace and lock-down even the smartest criminals, but I'm skeptical that in real-life these methods are anywhere comparable. Also, with zero leads and no address/name I'd imagine most authorities would give up.

So how easy is it really to be untraceable or theoretically untraceable given the ease of fake info/no face/no traces or leads/no social security info/addresses/lack of details to even begin identifying?

This depends entirely on the type of ISP you had in mind. Wired ISPs need to know your physical location in order to wire up your house, or at least they need to be able to tell contractors where you are so they can connect you to the ISP's Point of Presence. This includes dial-up, DSL and variants, cable, fiber, etc. If you give them a fake address, they aren't going to be able to provide you with any networking services.

There are also Wireless ISPs, or WISPs. You can theoretically give these ISPs a fake address or purchase it anonymously, but many of them can still locate you if they need to. Cellular networks, for example, can pinpoint your location by triangulation using multiple cell towers. One way to mitigate this threat would be to move to an area that is serviced by only one tower, making triangulation impossible. Another partial mitigation is to configure your cellular receiver to connect to the most distant tower it can rather than the closest, which can fool geolocation to a limited extent.

It would be easiest to be anonymous with satellite internet, assuming of course it was either purchased anonymously or obtained illicitly without a subscription (there are various guides to do this, but it requires building your own satellite equipment). As far as I am aware, it is very difficult to track bidirectional satellite internet when registered under a false address without expending considerable resources to track the location of the satellite dish on the ground. It would require a lot of time and a specialized plane to locate you. Note that both HughesNet  and ViaSat in the USA send data through L3, which was found out to be one of the companies sharing information with the NSA. If your threat model is such that anonymity at the expense of privacy is acceptable, then satellite internet may be what you want.


Should passwords be truly random? When generating a password, should it be "truly random" or should I make it a little less random by enforcing some rules?

If a password is generated at random, it could come out all-lowercase letters ("password"), or consist of only a few repeated characters ("abababab"). I'm thinking that this could be a problem, since brute-forcing would be easier.

So, what about making sure that a password consists of at least one character from several "classes", e.g. lowercase, uppercase and numbers? Or making sure that all characters are unique?

The point of randomness is to gather entropy.

Let's take an example:
I choose my password from the 4 first digits of the website plus the character ! and a number consisting of the ASCII number of the first letter.

Example: PayPal -> payp!70 ; amazon -> amaz!65

The entropy of this password is 0. Because the method is always supposed to be known, and nothing is random in this scheme.

If you use alternatively two passwords, the entropy is 1 bit. (2 choices possible)

On the contrary, if I use a 7 generated letter password with random selection, the entropy raises to log2(267) ≃ 32.9

(26 characters possible for each position then reported in term of bits)

The more you add possible characters (that are random) the more the entropy raises. Each "rule-driven" selection of letters do not add entropy (so for same length passwords, entropy is lower).

So in theory this second password has more strength than the previous with non alphanumeric characters. The problem of password is always the same : remembering the password. This means you need to lower the entropy for yourself. Such algorithm as the first presented above enable your to remember a complex password. The "security" given by this approach is a bet over the knowledge of this algorithm (also called "security by obscurity"). This is considered a bad security practice: a targeted attack on yourself (with knowledge of your scheme) will succeed. But usually it's a concession you make for practical use.

Making sure password uses alphanumeric characters + cases changes + non alphanum charcaters + ... is a practice driven by the goal of making a password with great entropy for brute forces attacks, i.e. attacks which consider no particular scheme in password generation. But for each type of attack your password would have different entropy, possibly 0.

To conclude, entropy stays a theoretical measure of password strength, in real life crackers will use a given method based on assumptions. So even if a truly random 6 characters password is consider equally secure if it contain only lowercases letter or both, in practice crackers may choose a method that will lower it.


.local domain any possible ways in getting the extension I was recently working on Broken link Hijacking and found a link in a target which reflected on multiple pages. It was portal.REDACTED.local which was not accessible and returned response as bad host.
So I never saw a extension that has .local so I just want to know if there is any way to claim this extension. If yes can you please share how can I claim this extension.
Thank you.

You cannot claim a .local domain. This is not a public top level domain but actually reserved for internal use. For more details see the Wikipedia entry about this top level domain.


Get key by monitoring power consimption of AES hardware core? Is it possible for an adversary to gain knowledge of the secret key by analyzing the power consumption of an AES hardware core? I think he/she can't, but I am having difficulty to give a reasonable explanation.

There are many ways to attempt to infer information about cryptographic operations, anything from processing time (see: hardware optimization analysis) to unintended emssisions (https://en.wikipedia.org/wiki/Van_Eck_phreaking but on the processor itself) to as you asked: Differential Power Analysis (https://people.rit.edu/kjm5923/DPA_attacks_on_AES.pdf)


Why is browsing while logged onto a VPN from public wifi more secure than not? I've been trying to wrap my brain around VPNs for a while now, but can't find a good source that answers the questions I have.

In particular, I can't understand why browsing from a public access point is more secure while logged into a VPN than not. It's my understanding that a VPN encrypts and routes traffic from the computer to the access point, across the Internet, to the VPN server, where queries are then directed to the appropriate destinations; responses then follow the trail in the opposite direction (Please correct me if this is a misunderstanding.)

Where exactly is the danger in not doing this? That is, why are my packets less secure originating from the public access point than they are from home? They still travel to the same destinations across the same Internet, and are likely going to be locally routed by the same ISP.

(There's something that seems like a good answer to this question here, but if I'm understanding it correctly, then it seems that all the articles touting the inviolable security of public browsing while logged into a VPN are misinformed.)

The thing about a VPN is that the connection between your computer and the VPN end point is encrypted.

If you go to Joe's Coffee House and use their public WiFi, depending on the configuration it is possible that anyone in the range of your WiFi radio can snoop on your traffic.  Even if Joe has secured his WiFi properly, anyone with access to the physical equipment (not necessarily Joe, but anyone with access) can tap the connection at the transition from WiFi to wired, where the WiFi encryption no longer protects the signal.

If, instead of connecting directly to wherever you want to go, you connect to a VPN, and from the VPN's endpoint connect to your destination, then everything that passes through Joe's is encrypted.  Your data could be sent in the clear from the VPN's endpoint to the destination, so you need trust in the VPN's endpoint.  From the endpoint of the VPN, your packets travel exactly the same path they'd travel if your computer were physically located at the VPN endpoint.  The VPN protects your egress from a network the trustworthiness of which is suspect.

Finally, most sensitive web sites these days, and many that are not, use TLS encryption.  Give or take a POODLE attack†, without the VPN, a snooper at Joe's could see where you connected, but not what you send.  With a VPN, the snooper can only see that you connect to the VPN, and not that you then connect to Bob's Bank in the trailer on main street.

† In 2020, POODLE attacks should be completely mitigated; to be vulnerable, you'd need both an antique browser and a server not updated since about 2016.


How to protect API from from malicious usage We are developing a community portal service using Java-Spring and Angular UI. We are also going to have an Android app soon. Our back-end exposes many services via REST API. There are couple of services which allows anonymous posting and creating service requests.

Here are our questions:

How can we protect API from DDoS-like attacks? Can we do IP whitelisting or put a cap on requests per minute for certain set of APIs?
How can we log such malicious requests?
Thanks in advance. Best Regards.

(See this question on SF at - https://stackoverflow.com/questions/38637175/how-to-protect-api-from-from-malicious-usage)

The API needs to be secure, so don't try to make trade-offs here. It won't be good ;-) However, don't trade-off on performance either, it needs to be very fast so then it will be stable. Use Cookies which are very good (there's plenty of info around here).
Apart from usual security precautions (Cookies etc), the following I found to be the must:

Good limits on number of concurrent requests to Tomcat (or whatever you use, it's normally in web connector directive) - you can load-test it so server is not overloading on full load, so that makes servers not crash under full load but also they got well utilized, for example with ab -c <number of connections>. And then, in front of these Tomcats put load balance to distribute traffic and shield from other attacks like packet floods. Load Balancer should have tuned TCP/IP stack for such scenarios (see below).
Geographically dispersed servers in Cloud, so with GSLB load balancing and autoscaling
Try to use in-RAM cache as much as you can
Use scalable databases, like DynamoDB in AWS, but good MySQL instance will also do, so they can scale-up with your load
Make sure any single API function is not slow, this can be done in unit tests (so with every test run you can see whatever there's no potential target for DDoS), making all API calls very fast you basically make DDoS problems very small and your website very nice.

The above things in bold are what usually I do after developers do their stuff basically to make it faster and more resilient and that's my 4 golden points :-)

From my experience it takes 20GBps network and 4-6 32 core servers to mitigate any spike like that to Tomcats anyway. It just doesn't happen more than that and the resources today are cheap to deal with it, and even on demand. The problem is when something is slow or not scalable like Databases, then the resources go too high and that's the problem.

For developers doing the API the main point is to use in-RAM cache. The rest is infrastructure / server with Tomcat build. I've seen some developers actually doing things like that and that's good and simple approach. So instead of every time checking Cookie with database, keep it in RAM, use sticky sessions etc. Same for other things. Like one poller to database which loads data into RAM every minute and other threads are using it without ever touching DB. I've seen this approach as well.

Infrastructure-wise, it's good to have Load Balancer in front of Tomcats and if it's not Cloud one, then you can do following.

Setup normal load balancer like HAProxy and put limits for each server, so in case of large number of real HTTP requests you can process them and forward to Tomcats, other software might be able to drop or filter bad requests base on configured rules - you could try Varnish Cache which is Cache, but for Load Balancer with filter it's also excellent and you can program your own logic.
Tune the TCP/IP stack of load balancer so it's resilient to large number of requests or SYN packets. So following tuning is effective:

No IPTABLES on it (just filter things on switch)
Disable SynCookies net.ipv4.tcp_syncookies = 0
Try net.ipv4.tcp_tw_recycle = 0
And net.ipv4.tcp_tw_reuse = 0

The last two can help achieving a lot's of incoming new connections per second.


Generate a wordlist using John the Ripper I want to generate wordlist with these rules: 8 characters, at least one uppercase letter, at least one lowercase letter, exactly two numbers. I've done a lot of google searching, and can't seem to understand how to do this. Can I get some directions on where to look or how to proceed?

crunch is a password generator that can do some of what you may be looking for.

crunch 8 8 -t ",@@@@@%%"

is a command that will generate a set of passwords that are exactly 8 characters long following the provided template:

, generates an upper case character
@ generates a lower case character
% generates a digit

You probably want to set various options to crunch to limit the output.  For example, a small test of only four characters, like this: crunch 4 4 -t ",@%%" generates 67600 words.

See man crunch for more details.


What are the guarantees that TLS provides without using a certificate in the scenario? Assume a scenario where we have a modular system including:

an Authentication Module (AM) which gets username and password of an internet user and issues a token for the user. User<-->AM communication is secured by TLS and AM has a certificate from a known Certificate Authority.
Some services that accept {Token, Request} from users and validate Token with AM and serve the Request. Each service is implemented on an independent server.

Tokens are bearer tokens. If we enable TLS for User-Service communication, do we need to get a certificate for each (service) server to make sure that Man-in-the-middle attack is not possible and tokens will remain confidential?

Yes

If the server doesn't present a certificate (or it is not validate), the client will happily give {Token, Request} to the presumed server. A MITM could act as the server, receive the tokens and requests and pass them to the real server.

They do not need to be signed by a public CA, though. You could be using your own PKI (a private CA to sign those certificates) if that makes your life easier.


What does the SSID have to do with a networks security concerning rainbow tables? I have noticed in a few places people mention that if a popular SSID is used, it makes a network more vulnerable to rainbow table attacks. I saw this in one location and assumed they'd mistakenly used SSID in place of the word password, but I just saw it again in an answer on this website.

As far as I know the SSID is just the network name, and rainbow table attacks are concerned with password hashes, so what would using a common or popular network name have to do with making it easier for a password attack to be carried out on the network. Is the SSID used in any way, or is there some wierd correlation between SSIDs and common passwords?

Thanks!

In WPA/WPA2, the SSID of the network is used as a salt to the encryption. A rainbow table therefore is only useful if the SSID used to generate it is the same as the SSID of the network you are attacking. Using a common SSID increases this chance.

Source


In a monitored network, can the admins tell if Tor is being used? I'm not asking if Tor is secure, I'm asking if an observer can know you are using Tor? For example if a persons ISP or company network monitors traffic would they be able to determine with certainty that a person is using Tor or not? For example, the exit nodes certainly are known, though I'm uncertain if the first node the traffic gets passed to is (publicly known)? A sys admin would be able to perform a whois and find out that it's a tor relay node (if they really wanted to know), wouldn't they?

As @Manumit asks "If anyone can pitch in on the missing piece, is "obfs3, scramblesuit, fte, and obfs4" ample obfuscation then?"

According to scuzzy-delta, yes:

  It is possible to detect that someone on your network is using Tor (e.g. You're a network administrator at a workplace, and an employee is using it), and the fact that you're using it is in itself interesting information.

His answer:
https://security.stackexchange.com/a/27848/76663

Using a bridged TOR connection is a safer bet but by no means the definition of safe, closer to gambling actually. The reason for this is they are meant to circumvent cencorship, if one bridge doesn't work for you in e.g. Iran you try another until you find one that's not blocked yet. However, I assume all bridged connections will work in lands of freedom, and therefore you have no idea what bridge connections your admin is aware of.

Diving deeper, this is an excerpt from https://www.torproject.org/docs/bridges.html.en

  Over the last few years, censors have found ways to block Tor even when clients are using bridges. They usually do this by installing special boxes at ISPs that peek into network traffic and detect Tor; when Tor is detected they block the traffic flow.
  To circumvent such sophisticated censorship Tor introduced pluggable transports. These transports manipulate all Tor traffic between the client and its first hop such that it is not identifiable as a Tor connection. If the censor can't decide if the connection is a Tor connection, then they are less likely to block it.

If anyone can pitch in on the missing piece, is "obfs3, scramblesuit, fte, and obfs4" ample obfuscation then?


How does "password / keyboard-input protection" work? I do own Kaspersky Internet Security (KIS) and BestCrypt Volume Encryption (BCVE) (unrelatedly) and both offer some mechanism (KIS) to "protect my passwords while I enter them". Kaspersky primarily does it when I use my browser while BCVE offers this only when entering the password that protects data volumes.

Also Kaspersky's solution doesn't really change any behavior in any way that I could notice while BCVE effectively blocks my password manager (KeePass) from entering the password for me. A similar strange behavior applies when I enter the self-protection password for Kaspersky to change its settings.

So my question is now:
How does (/can) this password protection "technology" work (conceptually)?

The only (ways) I can imagine this works is by temporarily disabling the keyboard hook system in Windows as well enforcing the clipboard to be empty, but I think they do more (in a clever way).

It's all a matter of API level: if you intercept an event using a (usually privileged) low-level API, you are then able to hide it to higher (unprivileged) level APIs.

Thus, these two solutions most-likely rely on low-level APIs so intercept keystroke events so they remain undetected to key loggers (hopefully) relying on higher level API.

In the case of BCVE, their own screen seems pretty self-documented and explicitly confirms the technique used, "Anti-Keylogger uses low-level Windows functions":

In this case, the implementation is relatively easy since BCVE can directly use the captured keystrokes destined to itself. The thing is a bit more tricky for Kaspersky since captured keystrokes must then somehow be sent to an HTML form field in a standard browser.

To implement this, Kaspersky injects a JavaScript file in user's web pages. This script then acts as a client and contacts a Kaspersky service running locally. This allows the script to fetch the key strokes as they come and fill the protected input field accordingly, thus effectively bypassing the standard keyboard input stack.

Here is a few information from Kaspersky people confirming this, but it seems that they do not publish a lot of documentation regarding their products internals.


On Hawkes' technique to bypass canaries I found this reference to bypass canaries: http://sota.gen.nz/hawkes_openbsd.pdf

It recommends to brute force the canary byte-for-byte. I don't understand how this works: "Technique is to brute force each byte of the canary individually along with time analysis". How can you do time analysis on a byte-for-byte basis? Isn't the whole canary compared at once? I thought that the the four bytes were compared with only one instruction.

This attack is also referenced in http://www.phrack.org/issues.html?issue=67&id=13

The idea is to control the length of your attack so you only overwrite the first byte of the canary. You can then brute force the 256 possible values for this byte, and using some kind of side-channel figure out which is correct. Once you've got this, you can brute force the second byte, and continue until you've got the whole canary.


Is it vulnerable to let users know their own and other users id from a database? Say, I have a table Users with the id being an integer. Each user somehow is aware of their id somehow, for example, in an url to their profile the id is included. Or it's exposed to them by some other way, doesn't way. How wise is it not to expose it to them? Could it vulnerable for me as a website owner to allow my users to know their own and thus the other users id? Or should I instead create either guid as the primary key, or add one more column called "long_id" and expose only it because it'll be difficult for them to guess it?

It really depends on what you can do with that knowledge,  Ask yourself the following questons:

As a user of the site do I need to know my ID to use it?
If a user knows their own ID what does that really mean?
If a user knows someone elses ID, what knowledge or access does that grant them?

Finally if the ID is used within a URL that displays someones details, does changing that ID and display someone elses details?  If so then that's an access control issue, not necessarily an issue with knowing the ID.

Regardless of knowing IDs as an attacker I would be interested in getting as low and ID as possible, either 1 or 0, as those tend to be the Admin user within the application.


should giving salt to unauthenticated users be a problem Let's say i have a scenario when the user salt is required in client side before login,

the user obtains the salt by this url http://my-api.example/get-salt/userid

that url should return a salt for any user without login or authorization, should this be a problem or cause some security risks ?

Note: that each user has a unique salt

There are two issues here:

Firstly, you need to avoid providing an oracle for "does this user exist in the system".  That means you need to provide a value whether the user exists or not.  Furthermore, this value must be consistent for a given userid (otherwise the attacker asks multiple times, and if they get the same answer every time, they know the user exists).  On the other hand, it must not be possible for the attacker to calculate the fake salt given the user id.  This means you need to generate a secret key for each installation, and the fake salt is generated by encrypting the userid with the key (or calculating the HMAC, or similar).  As noted in a comment, you also need to make sure that returning a real salt or a fake salt take the same length of time (otherwise the time taken can provide an oracle to tell whether the user exists or not).

Secondly, this is a cheap request for the attacker to issue, whereas the server is going to need to go to the database to see if the user exists, and if not, encrypt a value.  You will need some mechanisms in place to avoid this being a potential DoS vector.

Final thought:  I presume you are doing this, in order to offload the computational effort of hashing the password onto the client.  This is fine, and in the right situations, sensible.  However:

You must make sure you are using the browser to calculate the hash in native code, rather than javascript.  If you don't, the attacker with a leaked database (who is probably doing the hashing in native code on multiple GPUs) just has too big a performance advantage.

In addition, you need to make sure that you do one more round of hashing on the server and then compare the result with what is in the database.  If you don't, and the database ever leaks, the attacker will be able to log in as the user just by replaying the value from the DB.


Combine SNORT detection and log with active response OSSEC As far as i know, NIDS implemented in Network layer and HIDS in Host-based layer, Is it possible for NIDS( for example: Snort or suricata ) log that will included in HIDS(for example: OSSEC) log too ? Do the NIDS and HIDS are stand-alone system that cannot be integrated each other ?

The assumption is like below:

I Implemented both NIDS and HIDS in my server
NIDS for SNORT and HIDS for Ossec.
After, that let's say there are anomaly that could be found in network layer(i.e DDoS )
That's look like a job for NIDS (SNORT)
It should be triggered the SNORT rules.
SNORT Analyzed the anomaly, collected the information, and do some action that we assign in SNORT rules.
SNORT do some action for the anomaly that have been found.
After that, the information that SNORT collected will be send to Ossec.
If the attacker ( the anomaly ) can pass SNORT rules, there is a backup that handle the anomaly, and it was OSSEC

Is this possible ? or this is not a good idea ?

My motive by doing this is, i want to make a several security that located in Network and Host-based, so it make my Data center/server more safe than using one type of IDS

There is a solution from https://www.alienvault.com/. They offer a product that incorporates HIDS and NIDS in a box. They actually use Suricata and Ossec.


How to add all input required information in one single gpg command line? GnuPG documentation is not that great for a beginner like me and I coudn't find much detailed information ouside either, I hope you can give me some guidance about this:

I am developing a wrapper for the gpg command line tool. I would like to know if I can fit on only one command line all the input information needed to generate a key pair.

Currently I have to call: gpg --gen-key and input several other pieces of information like the key type, expiration info, name, email, and comment one at a time.

I'm couldn't figure out the gpg manual to assist on this, any tips are welcome.

I believe the answer can be found in this part of the manual: Unattended GPG key generation.

As an example:

cat <<EOF | gpg2 --batch --gen-key
Key-Type: DSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: Joe Tester
Name-Comment: with stupid passphrase
Name-Email: joe@foo.bar
Expire-Date: 20170115
Passphrase: abc
EOF


How Do AVs differentiate between normal cryptographic modules and viruses crypters I have read that some viruses -in order to avoid AVs- use crypters to encrypt their code so that the AV can't detect them.
so as a countermeasure, AVs are programmed to look for the crypter -in the case of crypted virus - which is usually contained in the malware's body.

So, my question is :
How does an AV differentiate between malware's crypters and normal cryptographic functions which might be contained in a legitimate app ?

Crypters and legit crypto common in apps are very different and have very different signatures.

Binary executables can't just be "encrypted" because they won't be able to be executed by the CPU or OS. Crypters are an obfuscation tool used to turn your code into very hard to read and reverse engineer code. This is done with a variety of methods and most don't involve the kind of "crypto" you would find in legit applications.


Should I install SELinux onto personal machines? I came across SELinux this week and the concepts seem interesting. However I don't see the use of SELinux being promoted as much as I expected. Why is this the case and would anyone recommend installing a SELinux kernel onto a personal Linux machine?

However I don't see the use of SELinux being promoted as much as I
  expected.  Why is this the case...?

SELinux is a security mechanism which, unless properly configured and tuned, is going to be either ineffective or inappropriately block functionality.  Think of it like a sharp kitchen knife; indispensable in the hands of a skilled chef, but either dangerous or prone to dulling in the hands of a novice.

As a result SELinux is most commonly* only used in canned, OS-distribution configurations which have been carefully designed and tested.  These uses are usually invisible to the user (the hallmark of a well-designed policy!)

SELinux is also most useful with programs that provide an attack surface, which is to say, network-accessible daemons.  As such, it's more appropriate for a server than it is for a "Personal Machine"

  would anyone recommend installing a SELinux kernel onto a personal
  Linux machine?

I would rephrase your question as "when would it be recommended to install...", as the recommendation is dependent upon the circumstances.

If you are interested in learning about security, and have never played around with Mandatory Access Control before, and you have a machine where you don't mind horribly if it gets wedged up and needs fixing, then I would recommend playing with SELinux.  MAC can be fascinating if you've never played with it before.
If you have less trusted processes (say, you're running a Minecraft or similar server for your friends but don't fully trust it) that make you nervous, and you're willing to spend some time and effort building a configuration that works without breaking things (and breaking, and fixing, things along the way) then you might want to consider SELinux... but recognize it's a bit of work if you're not just taking a working profile from somewhere.
If your personal machine is a tool for getting stuff done and you're going to feel inconvenienced if things need adjusting, and you don't have a particular threat level that makes you feel more nervous than normal, then I don't recommend SELinux.

*In my personal experience; YMMV.  For example, SELinux is enabled by default on Red Hat Enterprise Linux.  But on something like Ubuntu you have to go out of your way to add it.


Abilities of my ISP to stop me from browsing I visited a football site yesterday to stream a match online, and since then my connection is unstable. Like, I get connected at times and loses at times. I was over at my friends' and did the same and the network in his house was also weak while trying to visit that website, although I was able to visit the site using cellular data, later.
Can my ISP can do such a thing?

Yes, ISP's have the ability to arbitrarily block or throttle traffic based on the source of the traffic, or other factors.  This is what net neutrality aims to prevent.  See https://en.wikipedia.org/wiki/Net_neutrality.


Can location/owner of mobile phone be identified Let's say someone uses GSM network mobile phone to pursue his/her online activities on social networking platforms. The mobile phone is Android and all online activities are done through a VPN tunnel (Droid VPN). Posit He/She runs a Facebook account that cannot be identified whose account is it in person.

Can the origin/owner (by tracing mobile phone number/ location) be identified by anyone tracing that social platform or mobile activities? If yes how that can be thwarted?

Scenario example:

CellX(a GSM mobile phone) is on BTSY (network tower under which cellX resides).

On May 6, 2018 at 24:30:02:2034 owner of cellX posted on Facebook and BTSY adds timestamp, IME, apps that generated that packets, geolocation, destination of the packets etc.

Authority later collects all packets between 24:30:02:2034-5 seconds  and 24:30:02:2034+5 seconds i.e. timestamp filter.

From those packets authority applies further filters like geolocation (of suspicious places) and more filters just to track the original poster. Likewise more filter to be applied utill the poster is pinpointed! All these processes are done while the authority is unaware of the content of the packets due to encryption, let alone if the authority is able to decrypt the packets! Could you suggest a way of being pseudonymous?

Well, that is hard to answer. He should not be identifiable by the GSM internet connection thanks to the VPN, but the native Facebook/Messenger app will almost certainly identify him by grabbing data of his phone if allowed. Facebooks core business is gathering data about people and they do not shy away from that with their apps. They try to grab all contacts, phone number, GPS position, SMS and just generally everything they can get their hands on.

If you want to remain anonymous/pseudonymous I would strongly recommend avoiding Facebook if at all possible. If not, there is an opensource app that allows access to Facebook and tries to not reveal private information that is not voluntarily provided. It may or may not be successful at preventing identification of the user.


Is it safe to share an encrypted GPG private key? I use the pass password manager, and I am trying to come up with a convenient way to bootstrap new machines with access to the git repository. I also have a GPG smartcard (Yubikey) with a different keypair (I use a separate key just for pass).

Supposing I've exported the pass keypair as pass.sec.asc, my current thought is that I should be able to use my default (not-pass) keypair to do the following:

gpg --encrypt --armor --encrypt-to 0xMYKEY < pass.sec.asc > encrypted.asc

and upload encrypted.asc to a public location. Then, take my Yubikey to the new workstation, download encrypted.asc, and

gpg --decrypt < encrypted.asc > pass.sec.asc
gpg --import pass.sec.asc

and be able to access the passwords in my store.

Would it be ill-advised to publish even an encrypted version of my key?
Are there cryptographic dangers to encrypting a secret key?
Is there a better way to bootstrap new password-store machines in a mostly-scripted way?

As a general rule of thumb, adding private keys ANYWHERE public is a really bad idea even in it's encrypted form.

One method that I can think of would be to have the GPG keys pushed to the new servers via SSH when they are first created. This means that the key goes directly from one server to another and doesn't end up permanently stored somewhere that anyone can get to them.

If you do decide to go with the hosting on a centralised file repository option, ensure as much security as you possibly can by ensuring the system can also be accessed with authentication from an internal network user.

Edit:
Posting an update as I came up with a slightly more helpful solution + to answer a comment.

In theory, the comment saying that the key is as secure as the encryption algorithm is correct, in theory if the private key is really strongly encrypted then it's safe(ish)... however... by making that key accessible you signficantly open up the possible attack vectors. Anyone is able to challenge and attempt to decrypt that key at their leisure. A safer bet is to not only rely on the strength of a particular encryption algorithm, but to add some migitation by ensuring that the private key is kept confidential.

A really good idea for providing an initial setup of linux systems could be by using an automation tool such as ansible. My knowledge on this topic isn't quite up to scratch but from my understanding you could keep the private key secure on a single machine and using something like ansible vault to encrypt it while at rest. Ansible can then be run against the new machine that you would like to setup and it will deploy that key, ensuring that the key was not at any point publically available.


I'm concerned a website I use is vulnerable - getting vulnerabilities fixed (UK) I'm a paying customer of a service. I can't change provider without damaging my own business.

I believe the website is vulnerable to very basic vulnerabilities (url tampering (IDOR)) that would disclose my personal information and potentially worse.

The admin denies the site is vulnerable and will not allow me to test nor will he have the site checked by professionals.

All I can think is to report my concern to https://ico.org.uk/concerns/ but without any concrete evidence beyond passwords being stored in plain-text.

How can I ensure the site fixes basic security issues if they exist?

If you cannot (at least easily) switch providers (I assume that you are locked in to a service which cannot be moved) then you have to have a few things covered. For you, your business and your customers (if they make use of the service).

To start with, I am not a lawyer so you will be better off discussing this with a lawyer.

First read your service contract: is there anything about "reasonable efforts" the provider is supposed to make, from a security standpoint? If so, there are industrial best practices about how an application should be secured. You could point out to your provider that he is possibly in a breach of agreement.

Now - he may not care, knowing that you are locked in with him and resolving the issue in court is too long/complicated/whatever to you.

In that case you need to do some due diligence. The idea is that, in case of bad things happening (the service is breached, your and your customers' data is in the wild) you can prove that you have done all reasonable steps to alert about possible issues. Keep a copy of the exchanges. Then warn your admin that in case there is an issue, he will be responsible for all costs.

What you can do and the true value of your actions will considerably vary with the exact circumstances of your case. Again - consult a lawyer.

I would also strongly recommend planning for a provider switch. I am very much aware that this is not an easy option but it usually boils down to resources (time, money).

Finally, do not make any attempts to hack his site for demonstration purposes. This is not only possibly illegal (and subject to appreciation of a jury) but you may also harm his service with all the consequences (interruption for other customers for instance).


New SSL cert implementation showing errors on Android only When testing a HTTPS URL it loads successfully from all browsers on mulitple desktop operating system.  However when we test specifically from Android mobile phone we get the following results:

Android using Dolphin browser:

Security warning

The name of the site does not match the name on the certificate.  Do you want to continue? (Cancel / Continue)

Android using Chrome:

It displays the message:

No Certificates found

Chrome has requested a certificate.  Agreeing to this request will allow the application to use this certificate with servers from now on.  The requesting server has been recognized as :443.  Only agree to this request if you trust the application.

You can install certificates from a PKCS#12 file with a .pfx or .p12 file extension.

With "Install" or "Cancel" buttons at the bottom of the error message dialog.

The really interesting thing is when testing on the same Android phone using Firefox and UCbrowser the URL loads successfully without these error messages.

When loading the same URL using an iPhone with either Chrome or Safari both also load successfully.

Would anyone have any pointers on what we should check regarding the setup?

Regards,
Leigh.

We managed to solve this issue.  Our webserver is Tomcat and the fix was to follow the steps below:

Backup \repository\conf\tomcat\catalina-server.xml
Shutdown the Tomcat Server
Modify the catalina-server.xml file by changing the setting
clientAuth=want to clientAuth=false
Start the Tomcat Server.
Ensure the Tomcat server is started correctly.


How to encode a CMS or S/MIME PEM file with OpenSSL not encrypted or digitally signed? We developed an application that reads a CMS encoded PEM file with this command:

$ openssl cms -verify -in filepath -inform PEM -noverify

The file is digitally signed, but we don't care about it, as we only want to extract the contents inside (it starts with: -----BEGIN CMS----- and has a ".pem" extension). That is working like a charm.

Now, we need to write an acceptance tests for this app.. but we cannot use the production handled CMS files so we want to encode a custom file to use as "test input".

As far as my understanding is, we simply need to genearate a CMS encoded file from an input file that 1) is not encrypted and 2) it could or not be digitally signed (but as far as I understand is not a must of CMS).

No matter wich parameters we call openssl with, we cannot get it this work. This is more or less what we are trying (with all the -nosigs -noverify -nocerts -noattr -nodetach combinations):

$ openssl cms -in input.xml -outform PEM -cmsout -out output.pem

Any ideas? Thanks

CMS has options for several types of messages including both signed and unsigned ones (and so does SMIME which is based on CMS) but the openssl cms -verify subcommand can only handle a signed message; -inform PEM and no -content further requires CMS (not SMIME) and 'embedded' (not 'detached') format. Even though the purpose of your command is to discard the signature, your command requires the signature be there before it can be discarded.

To create such a signed message, you must have a keypair and certificate, but since the receiving command uses the seemingly contradictory combination -verify -noverify this certificate doesn't need to be official, it can be a selfsigned (dummy) cert you create yourself, which with openssl is easy:

# to create an RSA keypair and selfsigned cert for test
openssl req -newkey rsa:2048 -keyout testkey.pem -x509 [-days N] [-subj name] -out testcert.pem
# -subj name has the form /attr=value/attr=value/... where common attrs are
# C (Country) ST (State/Province) L (Locality) O (Organization) OU (Org. Unit) CN (CommonName);
# if you don't specify -subj you will be prompted for these fields
# (unless you or someone has modified the config file on your system).
# -days N defaults to 30; for testing longer times like 10 or 20 years are popular.
# By default the keyfile is password-encrypted, and you must re-enter the password
# to use it. For test this isn't needed; to avoid it add -nodes .

Then do:

openssl cms -sign -in $datafile -signer testcert.pem -inkey testkey.pem -nodetach -outform PEM -out $outfile
# possibly add -noattr; the command you posted works for SignedData
# either with or without signedAttributes, or even a mixture,
# so I can't say whether you should test with, without, or both

(Change the filenames if needed to fit your environment or procedure(s).)


FB Oauth CSRF security, PHP website I am experimenting with third party login, using Twitter and Facebook.

After getting access token from these parties, and confirming its validity, I then issue my own JWT token that's used within my application cluster. The only thing I use the 3rd party token for is getting an email address and user id, I don't interact with the social network in any other way, except for revalidation. Basically it is just so that users don't have to fill in new password.

I have several services, each on a different subdomain. These services somewhat adhere to the philosophy of microservices, and each is responsible for the narrow scope of functionality (e.g. UAC, business entity repo, etc. )

The sole purpose of the JWT token is to decrease auth check complexity among the other services, which shouldn't be Oauth provider aware. I also don't want to identify which provider they chose in the publicly visible JWT.

I installed a third party (officially approved) SDK on the UAC microservice, with which I'm interacting through AJAX request.

EDIT: Updated flow, for better clarity

From the presentation layer: require authorization URL from the UAC module. On the UAC module side, the SDK handles CSRF token creating, and sadly, storing as well (at least the FB SDK does). The CSRF token is set into the session.
Redirect the user to FB auth page, the user authorizes, gets sent back to my presentation layer with a CSRF token to compare
This is where the CSRF check SHOULD happen, but the original token is not set in the current session, instead is in the UAC module
From the presentation layer - server-side: grab Oauth token and CSRF token, send it to UAC module
This is where the CSRF check COULD happen, but server-server communication doesn't have the session. This is where I skip the CSRF check by tricking the SDK to accept whatever CSRF token just came in
Validate the Oauth token, exchange for long-lived one, fetch users data, create user entity in my database, issue JWT, done.
JWT is set from the Presentation layer - server-side with SetCookie. This cookie users HttpOnly and Secure ( but that's not really the issue here )

In simplest terms: I want to achieve the same functionality as regular Oauth with these providers, but I need to split the process among two subdomains. Neither of these should have a PHP session if possible, except for the brief moment of FB SDK forcing me to use one.

What I have tried so far: I changed the architecture a little, and instead of directly talking to the UAC module from javascript, I bounce the request through the server-side on the presentation layer, and in that session, I store the original CSRF token. When later the user comes back from the FB auth page, I can perform the check. I still have to trick the SDK on the UAC side, but that is after I verified the CSRF ( albeit not through the SDK itself ) Can I go ahead with this approach? Is this risky in any way, because I send the CSRF token between servers?

Its not entirely clear what the actual question is here, but it seems related to CSRF, I will answer the question assuming its related to how best protect against CSRF.

I would recommend implementing the cookie attribute "sameSite" in strict mode [1][2].

SameSite is a 'newer' cookie attribute that's primarily designed to protect against CSRF style attacks. Setting the value to 'STRICT' ensures all of the HTTP methods are protected, i.e., if you set the value to 'LAX', GET requests will send the cookie, while 'POST' requests wont etc. It is suggested that 'LAX' is a balance, but this is somewhat subjective and requires context. Setting to 'STRICT' ensures the browser will never send a cookie other than from the origin.

[1] MDN Cookie Attributes:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

[2] OWASP sameSite
https://www.owasp.org/index.php/SameSite


Should operating system passwords be complex if full disk encryption is used that has a complex passphrase? If a device uses full disk encryption such as LUKS, BitLocker (with a pin), Veracrypt and others and boots using a complex password, what is the need for complex passwords to log into the operating system thereafter and why?

There are a few reasons why you'd still want complex passwords, though, they're all a little situational.

Local access or theft of your machine while it's on (or in sleep mode) but locked. A bigger problem for laptops or workstations in open offices/public areas, especially if you don't disable normal sleep and go straight to hibernate.
Remote access via password (RDP, SMB, various RPC / remoting systems on Windows; SSH or VNC / Screen Share or similar on others). Obviously not an issue if remote access is disabled, public-key only, or enabled only for specific accounts that do have strong passwords.
Combined with a TPM for defense-in-depth if your FDE key/password is compromised; the thief still wouldn't be able to mount offline attacks without the TPM, and still wouldn't be able to mount online attacks (aside from things like freezing the RAM to extract the master key) without running into the OS anti-brute-forcing protection.
Defense in depth (in the case the FDE is either bypassed via an online attack or similar, or totally compromised) for data encrypted with EFS or DPAPI (including Credential Vault and saved private keys) on Windows, for Keychain on Mac (assuming your Keychain password is different from your FileVault password; by default they're both the same as your login password), and of course for SSH, GPG, and KWallet/Gnome Wallet/etc. keys on Linux (which aren't tied to your login password but should still be secure).


Why is security through obscurity not a good option for encryption? I feel like there must be a simple explanation, but I've been looking around haven't found any wholesome answers.

Take for example my name is Alice and my best friend Bob and we want to communicate securely.

If I write a program that takes my text and obscures it through several dozen filters and can successfully reverse the process, assuming I then wrote the program on a piece of paper and gave Bob my paper in the middle of the desert where he then memorized it and burned it, how would anyone ever possibly crack our code?

To elaborate on obscurity take for example I do the following:

Take my original string and convert it to binary
From there I add the last digit of the year to each number
Then I reversed the text
Then I added a randomly generated character once every 3 characters
And so forth, on and on, until I had several dozens obscurities filtered through.

Why wouldn't it be more-or-less impossible to decrypt our message without the program or formula itself (or at least for several years)?

Side note: I would understand completely why security through obscurity wouldn't work for people saying things like "I'll just use weird OS and I'll be safe because who the hell understands weird OS!" I am asking purely asking about sending an encrypted message back and forth, that if intercepted by a third party would not be able to realistically crack due to its obscurity.

The reason that relying on security through obscurity is frowned upon, is that once the algorithm is leaked or broken, you've totally lost all the security gained by obscurity.  So if any actor with access to the algorithm ever leaves your organization, or you are hacked, or source code (or an executable) of a encryption/decryption program is somehow leaked/stolen, then you've completely lost all the security from your algorithm being obscure.

To regain the security through obscurity, you have to come up with a totally new cryptographic algorithm, get cryptographic experts to securely analyze the new algorithm, and secretly exchange the algorithm with all parties that need to communicate.

Meanwhile, while using standard well-vetted cryptographic algorithms, we separate the algorithm (where you don't mind if someone steals it) from the key that is computationally unfeasible to brute-force (e.g., to brute-force a 256-bit symmetric key if every proton/neutron on Earth (all 10^51 of them) each tried a billion keys a second, in a million years of brute forcing it, you'd only have a 1 in 1000 chance of breaking it).

Only the key needs to be kept secret.  If you lose a key through an attack or need to securely send messages with a new party, you don't need to invent a totally new algorithm.  You just need to generate a new key.

With a well-vetted public algorithm anyone can come along and try to analyze it and see if there are any serious vulnerabilities.  That can't be done with your private algorithm which often are much weaker than the implementer may think.  (E.g., as Daniel mentioned the algorithm you described would be vulnerable to many standard attacks like letter frequency analysis, analyzing periods in the text, exploiting patterns in underlying plaintext, etc.)

Additionally, using secret algorithms is significantly more difficult from a usability standpoint.  There's much more the user has to remember for every exchange with every other user.  When you find some file you encrypted 5 years ago or someone sends you a file, even if you still have the key/password it will be much easier to decrypt if you know it was encrypted with AES256 in CBC-mode, as there file meta-data stating that information, versus trying to remember what type of secret custom encryption algorithm you may have been using with this particular individual.  If users work on a variety of platforms, it becomes troublesome to get your custom secret encryption algorithm working perfectly on all of them.


Help with SSL teaching material I am taking a course on security next month. As the concepts of SSL/TSL are bit hard. I am looking for a nice way of presenting it to my students. They are Compsci undergrads.

It would be nice to have a reaal life one on its working. I think people here could help me in this

SSL is a very cool protocol.  Refined,  very secure and its no accident that its so widely used.

I liked reading The First Few Milliseconds of an HTTPS connection,  and I recommend it to others.   The best part is that you can follow along with wireshark and a browser.

On a side note I can't believe OpenSSL library is now 1.0.0!  I thought that would never happen.  The latest version introduced negotiation for SPDY (Which is exciting even if its only currently used by chrome when connecting to gmail XD).  Check out chrome://net-internals/#spdy in chrome.


Ongoing effort to detect MitM attack on TLS? Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.
State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.
Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop M from having their router perform a MitM attack, where the router holds a rogue certificate for A's FQDN, uses it to impersonate A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.
However, in practice, that could be detected

Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
It's enough to pass that same info on top of the TLS link using a protocol against which M has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attack on TLS? What method(s) does it use?

Certificate transparency is a system that indexes all certificates. Domain owners can watch the certificate transparency logs to see if any certificate has been issued that they did not request. Browsers may check the certificate log, to make sure that every certificate they encounter is added to the log.
So M can create a certificate and:

not add it to the log. B's browser can detect that the certificate has not been added, and is thus likely a fraudulent certificate.
add it to the log. A can detect that a unauthorized certificate has been issued.


Would it be possible for a malicious user to change the LAN IP address of an uncompromised device? I have a local network and an IPCam (with its own storage) in it. Due to some practical limitations, I cannot use technologies such as AP isolation or VLAN to isolate low-integrity and high-integrity devices.

There could be some malicious users in the Wifi network (let's assume there are some) and I am concerned with the security of my IPCam.

The goal I am aiming for is the following

Fix the IP address of the IPCam.
Block all the inbound traffic to the IPCam's IP (when management is needed,
I am going to disable the rule temporarily).

For the first step, as I understand, there are two ways of doing it:

Set a static IP address in the dashboard of the IPCam;
Use the DHCP service of the router and statically assign an IP
to the IPCam (by its MAC address).

Personally, I would prefer method two since the management would be centralized (given that I have many IPCams). However, for method two I think it would be possible for a malicious client to spoof the IPCam (or the whole LAN) to "change" the IP of the IPCam (something related to ARP?).

Would it be possible to do that under method two? How about method one? Would method one be more secure?

If the whole plan is not a good one, would there be any better solutions apart from purchasing new routers/firewalls which support AP isolation/VLAN?

If you don't trust devices on your local network the second method wouldn't work, since someone could host a rogue DHCP server (unless you have some nifty switches which can do layer 2 ACLs to prevent this). If that DHCP server would respond faster than your own DHCP server, the attacker would be able to tell your camera to start using another IP address.

If you're worried about the IP address of a device getting changed, setting a static IP (method 1) would be the best way to do so.

I think there's another issue with the second action you're mentioning though: I assume you want to block traffic to the camera's IP on a router/firewall. However, devices in your local network will not use that device to reach the camera. So unless you can configure that ACL on the camera itself, this won't help you against attackers coming from your local network.

The bottomline here is that you probably should isolate the camera to another network not shared with untrusted devices where you can implement stricter security measures, but you mentioned that that was not possible.


Should I shred documents with only name and address details? I routinely shred documents with any personal information on them to protect myself and others against identity theft. I have no doubts that shredding any documents with ID numbers, account details and the like is a good idea, however I am wondering whether there is any protection to be gained when documents just have my name and address details on them.

My name does not instantly pop up on a google search of my street address, however I have no doubt that someone with a real interest could use internet resources or social engineering to discover it without leaving their seat. It seems unlikely that anyone would go to the trouble of recycle bin diving (dumpster diving is so 20th century) just to learn who lives in my house.

Will shredding documents that only have my name and address details on them protect me against identity theft, or offer any other information security benefit?

You asked: Will shredding documents that only have my name and address details on them protect me against identity theft, or offer any other information security benefit? The bigger question which cannot be truly answered is: "If in the event of identity theft, was it due to you not shredding documents?"

Most of the times when it's time for me to dispose of personal documents, I have not gone as far as shredding, but instead either ripping out that portion of data (names, account #'s, etc) ripping that into little pieces, and disposing of it in entirely different trash bags/bins.

When it comes to dumpster diving, this has mainly been an issue of attackers targeting companies moreso than individuals, however many private investigators do perform dumpster diving, and I am sure there are individuals with malicious intent, doing the same thing. The initial question is: "What can someone do with this information!?" A lot.

Consider the American Postal System. There is a form one can fill out to notify the postman that they have moved to another address. The USPS usually begins sending mail to this location after about 10 days. This is a blessing when one is moving, but a curse to ALL AMERICANS. Fact: If you submit the form in person, you need to show ID (Good). Fact: If you fill out the form and mail it in, the USPS automatically starts forwarding your mail without validating you requested the change of address. (Try it if you'd like, complete a change of address to say your parents home, and mail it)

So, as an attacker, if I targeted you, I don't necessarily need to dumpster dive. Why would I when I can forward all of your mail. Imagine doing something like this to coincide with the last week, and first week of the month (usually when bills arrive). I'd receive your mail, to which I can gather data to escalate an attack without ever touching your garbage can.

There are other methods to obtain your data, it all depends on the skill of the person targeting you, and the level of data they want to get, and why. Think about it, you would have to be targeted for someone to pull this off otherwise, if I am random attacker going this route (dumpster diving), I am going to target big money. Dumpster diving in Alpine NJ, or Beverly Hills.


What would be a good way to create a security testing schedule? I've been tasked with creating a formal security testing schedule / calendar for our organisation's applications, as most of our current testing (scans, pentesting, etc) is done ad hoc.

I'm wondering if anyone has created something similar for their organisation, and what process was used in order to build this schedule.

My current thoughts are the following:

Create a list of applications arranged into criticality categories based on the function they provide / consequences of successful attack (e.g. mission critical, critical, non-critical)
Determine what needs to be determined for each criticality level through testing, and determine which tests will be done for each (e.g. Red-team testing only done on mission critical).
Determine the regularity of tests and types of tests for each criticality category.
Create a testing schedule.

I've not had much opportunity to think about how often tests / types of tests should be done, so I'm very open to referrals to material I could review to get a better understanding.

"Testing" only won't do it.

Risk Assessment

Frequency: Bi-annually

Document information assets (systems, networks, infrastructure components, etc.)
Identify threats to those assets (vulnerabilities, attack vectors, etc.)
Examine and review how security controls and measures that are in place mitigate or eliminate the risk of those attacks (access controls, processes, policies, security standards, etc.)
Identify security needs, remedies or areas for improvement

When categorizing assets, don't simply look at the importance of the service it provides to the organization (e.g. mission critical), but look at the risks that are associated with potential compromise, the value of the information, the impact of potential compromise. A system could be totally unimportant to the organization's daily business, but it might be of great importance in terms of the information it can provide to an attacker, if compromised. We had a running joke at the office - one of our pentest engagements wasn't going anywhere, the web servers and public infrastructure of the client were all rock solid, but we managed to compromise the CFO secretary's laptop. Interestingly, it had a copy of the company's financial statement - days before it was going to be officially released. Since the client was a publicly listed company... you know where this goes.

Security Audit

Frequency: Quarterly

Unfortunately, many forget that most issues can be identified by looking at things from the inside, rather than testing from the outside. A properly done audit may reveal issues that you might not be easily revealed during a pentest (let's have a look at the accounts defined for that Tomcat manager). Here are some basic points:

Review configurations (servers, routers, switches, firewalls)
Verify policies are enforced (e.g. make sure accounts of ex-employees have been removed, look at passwords and when were they last changed)
Look at how backups are configured and done, encryption of sensitive data, how access control is implemented (including physical - badges and other seemingly unimportant items)

_

Systems Lifecycle

Frequency: On-going

Every time IT bring up a new system, add a network, or provide a new service, or decommission an old one, the infosec team must be involved to review, analyze and implement security measures. Make it a part of the process.

Vulnerability and Patch Review

Frequency: Weekly

When you receive those security bulletins, if they contain items that are directly related to products/systems you've got installed, pay attention.
Also, don't "assume" all is patched on Tuesday - WSUS may work fine, but you've got to run some basic checks and look at the logs.

There are more items, but this is already too long, and I'm not writing a book. Additional things to look at:

Security events, incident reports and incident response
Security awareness days
Security round-table (involving the CEO)
...


What information can be seen from HTTPS to HTTP? Assuming a secured page https://google.com/redirect.php?keyword=apple which redirects the visitor to a non-secured website http://apple.com, would an eavesdropper (anyone watching over the network) be able to see the keyword "apple" from the referer URL?

No. Browsers specifically block the Referer header when the transition is from HTTPS to HTTP.

(HTTPS to HTTPS is fine, though following results from Google is a special case: depending on browser, interface type and wind direction, Google may be fiddling with the displayed URL and doing a search without a re-navigation, in which case you may only see https://www.google.com/ and no search term even from an HTTPS site.)


On what basis to create Data Keys For PII, we have to encrypt some columns in our DB(All of our infra resides on our own DC, not using any cloud provider).
Now roughly what we are doing is

Created a CMK at AWS.
Generate Data Key using CMK
Store the encrypted key in DB
For every request, we decrypt the encrypted data key via AWS and got the plaintext data key.(We basically do not do it for every request, we cache it for some time in memory due to costing/performance issues)
We have created our own encryption library(Using AES-256 with CBC with random IV / random salt for every request)
Then using the plaintext data key, we call the AES library to encrypt/decrypt.

Now I have few questions

a) How many different data keys we need to create? I mean whether it should be different for every column / different for every calling service / team?

Is AES-256 with CBC (Random SALT/Random IV for every request) fine for our use case
or do I need to use AES with GCM?

Do I need to rotate Data keys?

We cannot know the answers. It depends completely on your use case, of which you have explained very little.
Some considerations:

How many data key do you need to create?
As many as you have different access permissions. For example: if group1 has access to col1, col2, col3 and group2 has access to col1,col4,col5 you would need 3 data keys (one for col1, one for col2/3 and one for col4/5). If you want to be real flexible, for example because your organisation frequently reorganizes, you may choose to use more keys, for example one per column.

I'd go for GCM, for the following reasons:

performance
CBC is less secure (f.e. padding attacks)
I've always liked Evariste Galois

That depends too much on your application. For very large databases that contain many years of historical data, key rotation is often impractical. For small databases were the data value is limited in time, you could.


Frameworks for collecting all activities in a pentest? I work as a penetration tester for a company, and one thing we're regularly asked to do is to provide a forensic log of all of the activities we perform during the course of an assessment.  I'm wondering if there's a framework that supports logging of all shell activities as well as all tools relevant to the assessment (e.g. traceroute, metasploit, hping3, etc.)

Does such a shell exist?

You could write a script (in bash or python) to replay your commands and act as a local proxy for your commands execution. This way, you could split the results of the log into each commands.

This script should not be too long to write for the gain you will get. That would be my solution :)


file-integrity monitoring tools for PCI compliance A former employer of mine has reached out to me to assist them with PCI certification (I guess I'll be getting a 1099-NEC from them next year as a result). Here's the point I'm at in the questionnaire:

File-integrity monitoring tools are deployed within the cardholder data environment to detect unauthorized modification of critical system files, configuration files, or content files.

This is a Yes / No / Not Applicable question.
The next question is as follows:

The file-integrity monitoring tools are configured to alert personnel to unauthorized modification of critical system files, configuration files or content files, and the tools perform critical file comparisons at least weekly.

This is another Yes / No / Not Applicable question.
I'm not sure how to answer this or what could be done to put this company into compliance.
Credit card info is stored in the DB, encrypted with AES-128-CBC. Customers are charged monthly and every day an employee goes to a website that was built in-house by this company where the charges can be reviewed and then processed. The website is hosted on a Docker container that's managed through Amazon ECS. Git is used to manage the source code. When a deployment through Bamboo is made the Docker container gets destroyed and relaunched.
Between deployments I suppose some third party tool could be utilized to check the Docker containers for "unauthorized modification of critical system files" but idk what third party tools could be used to do that.
I guess the Git repo could be compromised, as well. If someone got my credentials they could make a commit to the repo and make an "unauthorized modification". idk how I'm supposed to protect against that...
Anyway, like I said, idk how to answer these questions. Any ideas?
(and yes, I'm aware that having a recurring payment through stripe.com or authorize.net would probably be better as it wouldn't require payment information be stored but I'm not being paid to do a complete rewrite of their system either;  if a rewrite is the only way to for sure do this then I'll propose that but I'll have to make a very strong case that there exists no other viable option)

An important part of the considerations for this, will be whether the Docker container is running in ECS "classic" or in Fargate. If you're using Fargate then there's no possibility (AFAIK) of deploying file monitoring tools outside the container itself, as you have no access to the underlying VM.
With ECS Classic, you could use something like falco on the host and it would provide alerts on events on the host. I'm not sure if there's pre-built rules for this but it would be possible to write them.
Another option (which may allow you to check the "not applicable" piece) would be to set the container root filesystem as read-only. At that point it wouldn't be possible for the attacker to change files in the container, and you could just do VM level FIM for the underlying EC2 instances (assuming you're not doing Fargate)
For the git piece, if that's in-scope, you could perhaps look at using signed commits which would essentially stop someone from modifying the contents of the repository, unless they've also compromised the signing keys.


Is there a point to Dnscrypt when using VPN? If a computer is already connected to the internet through VPN, is there point in encrypting DNS queries? From DNScrypt:

  DNSCrypt is a protocol that authenticates communications between a DNS
  client and a DNS resolver. It prevents DNS spoofing. It uses
  cryptographic signatures to verify that responses originate from the
  chosen DNS resolver and haven't been tampered with.

  Implementations are available for most operating systems, including
  Linux, OSX, Android, iOS, BSD and Windows.

  DNSCrypt is not affiliated with any company or organization, is a
  documented protocol using highly secure, non-NIST cryptography, and
  its reference implementations are open source and released under a
  very liberal license.

  Please note that DNSCrypt is not a replacement for a VPN, as it only
  authenticates DNS traffic, and doesn't prevent "DNS leaks", or
  third-party DNS resolvers from logging your activity.

I'm thinking a VPN must be rather useless in the first place if it leaks DNS...which is a lot.

It depends on what you are trying to achieve.

If you are trying to prevent DNS leaks, DNSCrypt isn't what you need. DNSCrypt is intended to prevent DNS spoofing, which is quite different. You could think of it as Privacy vs Man-in-the-Middle.

  DNSCrypt is a protocol that authenticates communications between a DNS client and a DNS resolver. It prevents DNS spoofing. [...] and doesn't prevent "DNS leaks", or third-party DNS resolvers from
  logging your activity.

If you want to verify your VPN doesn't leak DNS, you should look into its configuration. there is usually an option which might not be checked by default.
You can test it here for example https://www.dnsleaktest.com/

For DNSCrypt, it's up to you to decide if it's suited to you. If you don't think it's overkill, go for it.

In the end, it all depends on your VPN Server/Provider and the level of trust you have in its configuration.


Is the idea of Single Sign-On (SSO) a flawed concept without Two-Factor Authentication (2FA)? Before this gets flagged as a duplicate, I'm not asking a question about the disadvantages of single sign-on, I'm asking if the initial concept is flawed to begin with without enforcing two-factor authentication.

Let me explain what I mean:

1. The purpose of a password is to stop unauthorized people from accessing protected data.

2. We do not use the same password for every account because that potentially exposes all accounts when one is hacked.

Now enters Single Sing-On. Now millions of people put all their eggs (passwords) in one basket. This violates #2 because if the SSO provider gets hacked, then all the accounts are potentially exposed. Just look at the most recent (of several) hack on LastPass in 2015, and the even more recent hack of OneLogin in 2017, even having the ability to decrypt data.

Now with two-factor authentication, specifically using "something you have" as the second factor, you most likely prevent yourself from being the target of an SSO provider hack, unless the tokens were stolen too (but 2FA vulnerabilities are a whole other discussion.)

So how is SSO (without 2FA) much better than just using the same (lengthy) password all over, or maybe better, 3 passwords, so you have 3 chances to get it right (which shouldn't exceed password try limits) and you split any comprised password into 1/3 of all your accounts.

NOTE: I do not endorse using the same password over again. I personally have a unique password for every one of my 100 or so logins with a system that allows me to remember them, but I want to entertain the contrasts for the purpose of conversation.

Is there really a huge difference between using SSO (without 2FA) versus using 1 (or more) password (following the Password Do's and Don'ts) besides just shifting the job of password protection from 100 companies to just 1?

Now you could argue that you decrease your chances of getting hacked by shifting the security responsibility from 100 companies to just 1, but then I would ask if you would do better to have 100 unique passwords stored in 100 different companies than to have 100 passwords in 1 company.

All this just so raise the issue...

Does single sign-on make sense (from a security point of view) if we are not using Two-Factor Authentication?
Should we enforce Two-Factor Authentication when using Single Sign-On?
Without Two-Factor Authentication are we potentially giving people a false sense of security?

Please let me know if there is there something that I'm not taking into account.

Yes, SSO with-or-without 2FA makes sense from a security perspective, but not in the direction you've considered.  SSO provides a way to instantly deny access to compromised credentials across all the systems that subscribe to it.  So if my account is compromised on site A, the security provider can force a single password change that will impact my SSO account on all other protected sites.  2FA does not impact this one way or another.

Consider that SSO can initially be deployed without 2FA, but it can be converted by the security provider to use 2FA at a later time.  This will deliver 2FA benefits to every site without those hundreds of sites having to change their codebases at all.  That's a compelling argument not just in favor of 2FA, it's a benefit of outsourcing your security to a service dedicated to handling user authentication.  They can make improvements to your clients' security without you needing to expend any resources.

If 2FA is even remotely an option, yes, of course you will improve security by choosing it.  The only reason not to choose it today would be legacy system compatibility, and you shouldn't let that stop you from deploying it on a new system.
2FA is not a magic bullet.  It's a great improvement in security, but it's not invulnerable.  Nor is single factor authentication a complete failure.  Many sites that don't employ 2FA haven't had a breach.  :-)  All that said, Account Take Overs are pretty much shut down by 2FA, so you can actively help your users protect themselves by deploying it.

Finally, circling back to your anecdotal story of "I personally have a unique password for every one of my 100 or so logins with a system that allows me to remember them", this has two significant problems that you haven't acknowledged.  First, you are much better trained and far more skilled than 99% of common users - skills and techniques you may think are easy are far beyond the reach of virtually half the population of the planet. This solution does not and cannot scale to benefit all users.  SSO may be a compromise that introduces additional (and significant) risks, but it's a compromise that will benefit the full spectrum of the public.

Next, be aware that if a threat actor is targeting you specifically (different than someone driftnet trawling with passwords stolen from a large breach), and compromises your password on three different low-value sites, he may acquire enough data points to recognize the pattern underlying your password generating algorithm.  From there, he can try logging on following the same algorithm to derive potential passwords for you at high value sites, such as mybank.com, firstbank.com, lastbank.com, myretirementaccount.com, etc.


Best way to secure javascript front end/REST back end architecture web site? I would like to build the following project:

public REST API back end which can be accessed by any authenticated client.
front end with static files in HTML/CSS/Javascript with Backbone.js jQuery calls to the REST back end.

In fact, there are three parties in my architecture : the front end, which is a client of the back end, the back end and the user which wants to authenticate on the front end login page.

What is the best way to secure the three parties involved in this architecture?

In fact, I believe it is just impossible to do a secure app on the front end if I do everything in javascript, so I intend to delegate the authentication/authorization to a proxy layer on my server front end.

My problem is I don't know how to perform this workflow with OAuth :

a user wants to create an account on the Front end.
the Front end delegate the account creation to the REST back end.
the back end create the account and send an ack to the front.
then the user can perform calls which require authorization.

And I also want my REST back end be accessible to any other third party application whith OAuth.

Will I have to use 2-legged or 3-legged OAuth on the REST back end?

Can I consider my Front end just like a special third party application which has the ability to create user account ?

What security protocol may I have to use on Front end ?

Well, since you state that the REST API can be accessed only by authenticated clients you will firstly require a form of sessions to remember the authentication state of the client. Depending on whether you can alter the server code of the REST API you could implement this on the API providing server itself.

This could use any of the well known user authentication means like a username/password combination or using a (self-signed) certificate.

However just like with HTTP you will have to make sure that passwords don't travel the line in plaintext and once the session is authenticated the connection should not leak the session identifier allowing for it to be hijacked. This basically means you have to mimic SSL-like behaviour or implement SSL support for your front-end. An example can be found here: http://assl.sullof.com/assl/

Your questions related to OAuth are a different question and I would suggest you ask that in a separate question if it still remains something you want to know.

With regards to a proxy layer, this is a viable option only as long as the API is not publicly accessible other than through such a proxy. This proxy layer would have to implement the same SSL-like properties but this setup gives you the added feature of being able to keep the authentication logic and the API provider separated. However I would not recommend it if you are able to alter the API, because if any part of your server accidentally provides access to the private API you can circumvent your authentication requirements.


Isn't Facebook Apptoken Oauth2 client credential unsecure since it sends login credentials request in GET URL? Facebook Apptoken uses OAuth2 client credential code. But the client_id and client_secret are sent to the servier via HTTP GET method. Isn't this unsecure ?

For instance, any node that has logging enabled between the client and the Facebook server will log the GET URL. Thus exposing login credentials in their logs in clear text.

I think it's unsecured. Or am I missing something ?
Are there other more secure ways to implement client credential that you know ?

You are correct, that sending any credentials as GET parameter isn't best practice. OWASP ASVS (currently version 4.0.1) states this explicitly in requirement 3.1.1:

Verify the application never reveals session tokens in URL parameters or error messages.

In addition, RFC6749 gives an actual example for the client credentials grant, where the token is sent as POST request with an Authorization header.

While using GET parameters for tokens is not best practice for several good reasons, the risk is not that severe, as you are using TLS and communication (including URL parameter) is encrypted between the client and the server. In addition, we are talking about back-end to server communication, where the URL isn't even exposed in the client, so it isn't stored in a browser history and the URL isn't directly exposed to a potentially irresponsible user.

Nevertheless, if you have the option, you should go with the token as POST parameter or as HEADER value.


Why is the victim a server instead of a client? I just finished creating my own remote administration tool "a server to multiple client one" using System.Net.Socket, - "Watch Dogs fan :P"

then I try to search on google how they make or design their remote administration tool process and I found this Blog by Joseph Bisaillon, In his Basic RAT Design and other RAT Design they used "a multiple server to client",

I'm just curious why the victim use the server instead of the client in their Design?
Its better to use the client as the controller? or its the same to server?

This is all about the roles of everyone involved. Whether you are browsing a website, or buying a muffin from that cafe you know, the result is the same.

The server isn't the more powerful device, it's the one "serving" requests. The client is just that, the one that makes the requests that need to be served. You are the client when you request a muffin, or a website, or in this case remote access.

As a client you ask "move the mouse here", "open this for me", and "what do you see right now?". Then the server serves you by sending what you asked for. This is the relationship in all RAT applications.


Can my school look at my search history through Google Chrome if I am logged in through my school account? I am doing online school at the moment and I am wondering if my school tracks and looks at everything I search just through my school Gmail account. I am on my own network and pc which has never been connected to the school network in any way except through the school Gmail account.

The searches are logged under your Google Account and could be seen by your school admins.  You can disable search and other activities from being logged via your Google Account's Activity Controls. You can also delete previously logged activity - see Privacy & Personalization panel in your Google Account.


Inbound Ip Visited "localhost" wordpress stack on AWS i'm testing a webserver on an aws EC2 instance, it has a wordpress stack on it. The domain is configured properly, public static(elastic ip) redirected to main domain as well as the aws public dns. So the website can only be visited by the domain.

While monitoring inbound connections with wordfence i noticed someone visited http://localhost ... How is this possible?? The ip adress refers to a random company in the uk. Do you think its an attempted hack and someone has actually obtained the ssh keypairs to access the localhost or its a false positive by word fence. Bare in mind that the site is only running for about 3 days...

While monitoring inbound connections with wordfence i noticed someone visited http://localhost ...

It is not fully clear for me what you really saw but I guess that somebody checked if your web server could be used as a proxy to access an internal host. A properly configured web server will not allow this and in this case you could ignore this message as the usual "noise" you get if you connect a system to the internet.

If instead your server would allow such a request then it could be used to bypass existing boundaries: a web server at localhost (or in some internal network) is often considered protected from outside access or authentication is omitted if the access comes from an internal IP address. If the attacker manages to use your web server as a proxy to access internal systems or localhost then the request to the internal server will come from the internal address of your machine (or from localhost when accessing localhost) - and thus from a trusted system. This way the attacker can access internal sites which should not be reachable from outside.

For more information see for example Server Technologies - Reverse Proxy Bypass.


Cross-domain tracking techniques I have read several articles about user tracking through web trackers (e.g. doubleclick) across domains. Many articles write about cookies, web storage, flash cookies, ETags or image caching techniques.

After studying all the listed techniques, I came to the conclusion that only cookies and ETags can be used to track users across domains because they are sent in the HTTP request. The other ones can, of course, be used to track users on the same website.

Is it correct that (third-party) cookies and ETags provide the only way to track users across domains and that I only have to take care of them in order to ensure that I am not tracked in the web (besides fingerprinting which is not considered here)?

(besides fingerprinting which is not considered here)

I don't think it's very helpful to distinguish fingerprinting from tracking.

  Is it correct that (third-party) cookies and ETags provide the only way to track users across domains

No.

All tracking methods work by assigning a unique ID to you and making sure that you (or your browser) send that ID back when you visit a domain.

You're assuming that only cookies and ETags get sent back automatically (thanks to the HTTP protocol), but a website can pretty much run any code it wants on your computer by embedding Javascript.

Whether the javascript code calculates a browser fingerprint or phones home a tracking ID doesn't really matter. Javascript has to jump through some hoops because of cross domain attack prevention schemes such same origin policies, but thanks to CORS, if the domains in question cooperate, javascript will happily follow along. This isn't really a limitation to tracking compared to the cookie method because in order for cookie cross-domain tracking to work, the domains in question must also cooperate (e.g. embed a doubleclick resource).

Leaving javascript out of the picture, ETags and Cookies aren't the only cross-domain tracking possibilities by far.

For example, you could also use the other cache control HTTP headers to send unique ids, for example an id that was encoded as a specific point in time (via Last-Modified headers).

Or you could have a tailored stylesheet that gets cached by your browser and requests a unique resource, for example a background image with a name that encodes a unique id. As long as that image doesn't get cached (it may be sent with the caching headers set accordingly), your browser will keep requesting it whenever it encounters a page that uses the cached stylesheet...


Is there a replay cache in Kerberos 4? Does Kerberos version 4 support replay cache like in V5 - a cache that prevents replay attacks which occur within the clock skew, so the TGS knows a duplicate packet has arrived ?

The replay cache was introduced in V5 and is new in V5.


Prevent CSRF using ViewState? According to OWASP you can prevent CSRF in a ASP.NET application if you include the SessionID in the ViewState.  From the article:

  Viewstate can be used as a CSRF defense, as it is difficult for an
  attacker to forge a valid Viewstate. It is not impossible to forge a
  valid Viewstate since it is feasible that parameter values could be
  obtained or guessed by the attacker. However, if the current session
  ID is added to the ViewState, it then makes each Viewstate unique, and
  thus immune to CSRF.

Is including the SessionID even necessary if you are using encrypted ViewState?  How could a malicious user generate a valid encrypted ViewState?

Is including the SessionID even necessary if you are using encrypted ViewState? How could a malicious user generate a valid encrypted ViewState?

A malicious user could generate a valid, encrypted ViewState by visiting the page in question themselves and extracting the value. If the Session ID is not part of the ViewState value then this value will be valid for all sessions.

This is also mentioned on the Microsoft page Securing View State:-

  Per-user View State Encoding

  If your Web site authenticates users, you can set the ViewStateUserKey property in the Page_Init event handler to associate the page's view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.

  When the ViewStateUserKey property is set, the attacker's identity is used to create the hash of the view state of the original page. When the victim is lured into resending the page, the hash values will be different because the user keys are different. The page will fail verification and an exception will be thrown.

  You must the ViewStateUserKey property to a unique value for each user, such as the user name or identifier.