Does having non-ECC SDRAM affect security of the system?

It is possible.  It is stupendously, fantastically, indescribably improbable.

It will never happen.  It is not realistic.  Monkeys will type Shakespeare before it happens.  Daenerys Targaryen will bear a living child before it happens.  If two Wednesdays come together in a week... it'll happen long, long, long after that.

And as @Forest points out... It happened anyway, with Rowhammer (and even to ECC with the ECCploit variant).  Say Hello to the Wednesdays!


I'm getting lots of unfamiliar connection attempts, what do I do?

Yes, it is normal background noise. Those addresses are most likely belonging to infected computers that are trying to infect more computers.

If you have too much time you can do a whois query (web frontend) and contact the service providers telling them about the infected machines.

But the best approach is to disable logging of rejected connection attempts and ignore them. They are just burying the important messages.


What are good, safe, not necessarily anonymous ways to disclose vulnerabilities?

I would say that if you are withholding this information to receive recognition you are in this for the wrong reasons

Contact your local CERT and have them help you would through the disclosure process. This way you should be shielded from the company and the CERT should have a process for handling responsible disclosure between the two parties.

If you want recognition you will need to talk to the company directly or check if they have a security.txt located on their site with relevant information.

You will not get a CVE issued for a single website I'm afraid.


Crack 8-char password with known number of set bits

I think your idea about prejudging candidate passwords based on whether they meet the expected 42 'on' bit count is correct, but it should be easier to go about it the opposite way: generate a list of only the passwords that meet that requirement.  The pool of candidates matching the bit count requirement is relatively small in comparison to the overall number of possible 8 character passwords, which should save you a lot of time.

Based on my quick estimate, there are only 1,708 arrangements of 8 byte values within the appropriate character range that equal 42 bits.  But that count treats all bytes with 4 'on' bits as the same, when in reality there are 30 different character possibilities represented by a byte with 4 'on' bits.  So the total number of matching candidate passwords (again, based on my estimates) is 1,173,326,943,180, or roughly 0.00018% of the possible 6,634,204,312,890,625 entry search space for 8 character passwords.

One challenge is that it will take around 1,467 Gigabytes of disk space to write all these possible passwords to a file, which poses some logistical problems.  You could try to break each of the 1,708 bit arrangement password candidates into their own file, but those are still large text files to work with.  So I'd recommend either generating and piping your candidate passwords directly into a program to compare the SHA-256 hashes, or just comparing the hashes within the candidate generation program you develop.

Depending on the speed of your program conducting this comparison (likely on CPU) it is possible it might still be faster to just brute force the SHA-256 hash using a cracking program like Hashcat and a good GPU.  Looks like that approach should enable you to reach speeds of around 2,876,000,000 - 4,330,000,000 hashes/sec, or better, which would mean about 18 - 27 days to crack all password possibilities.  I doubt your program would be slower than this, since you have so many fewer candidates to test, but it's something to watch for if you can estimate your candidates compared per second.

Edit: To come up with the 1,708 arrangements I created a simple program with eight nested For Loops to represent each of the eight byte values.  Each loop incremented a counter between 1 and 6, with the final inner loop also adding up the respective byte counters and evaluating if they equaled 42.

When a match is found you should record the order of the individual counters to see the viable 'on' bit options.  I also created an index of which acceptable characters were associated with which 1-6 'on' bit values.  At some point you have to take this record as a template and iterate through all the different bytes with that number of 'on' bits swapped with acceptable password characters.  This is going to generate millions of candidate passwords per arrangement that you then need to hash and compare to the target hash.


What kinds of web applications need dynamic packet filtering or deep packet inspection

I'd ask your customers about what are they looking for in network packets and how deep they want to inspect them.

If they want inspection at 4-th level - you can setup free snort/suricata.
If they want it at level 7 - there are plenty of choices from free mod_security to cloud-based WAFs.

DPI as it meant to be is very resource-intencive, and mostly used by ISPs or large enterprises.


It sounds like you aren't clear on what how these tokens are used.

A JWT is a type of "Bearer token": this is a token created by a particular server and given to a user to keep secret.  The user can later show this token to the server to prove their identity.

It is very similar to a password - you send your password to a website, and the server thinks "this person knows the password, so it must be the correct user".  However, sending your StackExchange password to Yahoo Mail won't let you log in, because Yahoo won't recognise the password for an unrelated website.  However, if you take your password/token and use it in a different browser for StackExchange, then it will still let you in - which makes sense, because it is your password/token.

A CSRF token is a different type of token, used to prevent a different attack, but it will still only work for the servers that recognise it, much like a password or a JWT / Bearer token.


MasterCard wants to replace passwords with selfies; how does this improve security?

As I made clear in my answer to the linked question, I am not a fan of biometrics, and I think that current research agrees with me that especially face recognition is a poor authentication mechanism.

That being said, passwords have their problems too. Users are quite bad at choosing good passwords, users reuse passwords, and users write passwords on paper or in textfiles. The first problem may be mitigated with password rules, but password rules may also make it worse. The other problems can only be mitigated by educating users, which is expensive and error-prone.

These problems do not exist with biometrics. The security is completely in your hands, there is no way for the user to screw up.

As stated in the press release, the new feature is linked to an app, so it is fair to assume that the authentication mechanism is based on two factors (what you have - your phone - and what you are - your face - ).

Because the process uses 2FA, using biometrics may be secure enough. While it may seem that banking should be more secure than other transactions, historically, they were rather weak (4 digit pins for cards, passwords limited to 8 chars or less, and so on). Any security breaches were handled differently (transactions reversed, etc). The talk about "improving security" is likely just marketing.


How do large corporations manage accesses guarding?

Use a 3rd party system to handle access. Users authenticate to the 3rd party system, then it grants the user access to the target system. There is auditing and other useful controls by implementing this extra layer.

In some tools, the access system changes the password once the user is finished connecting.

The term you are looking for is "Privileged Access Management"


There is a paper describing how to use Microsoft Lync (formerly Office Communications Server) to mitigate brute force attacks:

http://blogs.technet.com/b/drrez/archive/2010/05/26/protecting-the-edge-server-against-dos-and-password-brute-force-attacks-in-office-communications-server.aspx

snippets:

  "DoS attacks are indistinguishable from legitimate sign-in requests. The only differentiation is in the frequency of sign-in attempts and origin. A large number of sign-in attempts in rapid succession can be indicative of a DoS attack. DoS attacks attempt to guess the user's password to gain unauthorized access, and often result in locking out the user account if security policy is enabled in Active Directory."

  "By enforcing account lockout at the Edge Server, the security filter prevents DoS attacks at the edge of the network perimeter, and as a result, protects internal Office Communications Server resources"

Microsoft has another white paper titled:  Account Lockout Best Practices White Paper
search for "Protecting from External Account Lockout Denial of Service Attacks"

key snippets (copied verbatim):

  Protecting from External Account Lockout Denial of Service Attacks
  It is possible for a malicious user to launch a denial-of-service attack against your enterprise from outside of your network. Because most networks are interconnected, this can be a difficult attack to mitigate. The following techniques technologies are common techniques and technologies that you can use to help mitigate or prevent such attacks:

  •  Require complex passwords: All accounts should have a complex password. All administrator accounts (local and domain) should have a long, complex password and you should change the password regularly.

  •  Rename the administrator account: Because the administrator account cannot be locked out, it is recommended that you rename the account. Although this does not mitigate all of the attacks against the administrator account, it does help mitigate these attacks most of the time. For more information, see "HOW TO: Rename the Administrator and Guest Account in Windows 2000" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=320053.

  •  Protect your environment with firewalls: To avoid an account lockout denial of service attack, block the TCP and UDP ports 135 through 139 and port 445 on your routers and firewalls. When you do this, you prevent logon attempts that occur outside of your network.

  •  Prevent anonymous access: Set the RestrictAnonymous value to 2 on all computers that are exposed to the internet and to the entire domain if all of the computers are running versions of Windows 2000 or later. This stops malicious users from making anonymous connections to resources and may help defeat some types of attacks. Note that some operating systems have limited support for computers that have this setting. Some programs may also have issues with this setting if the programs use an anonymous connection to gain access to resources. For more information, see "How to Use the RestrictAnonymous Registry Value in Windows 2000" on the Microsoft Knowledge Basehttp://support.microsoft.com/?id=246261.

  •  Protect site-to-site traffic by using a VPN tunnel: If communication between domain members in two sites is required, use a site-to-site VPN tunnel to securely connect site networks together. Do not open all NetBIOS ports on the firewall. You can use the Windows 2000 Server Routing and Remote Access service to create site-to-site VPN tunnels. If no VPN devices are available, you should configure the edge firewall or router filters to limit the traffic that is permitted to flow between the Internet Protocol (IP) address ranges that are used by each site. If sites need to use Active Directory replication only across the Internet, then use Internet Protocol security (IPSec) transport mode through the firewalls to secure all traffic between Active Directory servers. For more information about Active Directory replication through firewalls, see the "Active Directory Replication over Firewalls" white paper on the Microsoft Web site|http://www.microsoft.com/serviceproviders/columns/config_ipsec_p63623.asp.

  •  Protecting authentication and NetBIOS ports from Internet attack: On either the firewall or the router that connects your internal network to the Internet, block access to TCP and UDP ports 135 through 139 and port 445. If no edge filtering device is available, you can use IPSec filters to block these ports. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878.

  •  In the same IPSec policy, you must create an additional rule that adds filters to permit traffic to these ports when the source address is in a subnet that is used by the internal network. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878.

  •  Protecting authentication and NetBIOS ports from internal attack: If you must protect access to both authentication and NetBIOS ports from internal malicious users, you can restrict the computers that are permitted to gain access to these ports to only domain member computers by using the feature in IPSec that allows you to negotiate security. By allowing only trusted computers (domain member computers) to gain access to both authentication and NetBIOS ports, you reduce the number of computers that can perform the attack. This extra protection provides a defense against any breaches in your security perimeter and against malicious users who can connect to the internal network. For information about how to create a custom IPSec policy to use Kerberos authentication when negotiating IPSec security for access to TCP and UDP ports 135 through 139 and port 445 see the "Step-by-Step Guide to Internet Protocol Security (IPSec)" on the Microsoft Web site|http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp.

  •  Update the server: Keep all of your servers up-to-date with current versions of antivirus software, firewall software, and Windows security patches. This helps prevent trojan horse programs and viruses from attacking your resources if the malicious user can launch an attack from your internal network instead of from the Internet. These updates are an important part of an in-depth and defensive security strategy.


Authentication between multiple systems/platforms within the same web application context

Generate a session token upon login.
Store that session token in the database.
Check for valid session tokens when authenticating.

Pretty much what you have. Just consider if you want to have more than one valid session at once and how you'll go about expiring sessions.

EDIT for crazy comment thread below

While one can provide tokens to the client that are verified by the 2nd server without communicating with the 1st server, that's ugly and involves a lot of work. Such a scenario does not permit one to invalidate sessions unless the client takes care of it. It also requires a certain time window when tokens are passed, timestamping of tokens, tracking of tokens by the 2nd system, signing or HMACs in the token passing, etc. Unless these two systems can't see each other on the Internet, just avoid that mess entirely.

I gather that both systems can access the same database, but if for some reason they couldn't, having a API exposed to the second system that can remotely verify would be appropriate as well (secret.page?checkUser=token... or such).

Without SSL, there is nothing you can do to prevent session hijacking by means Firesheep / MITM attacks.


Can VPNs prevent information from being stolen by keyloggers screen readers?

VPNs are not going to provide you any protection against keylogging/screen grabbing malware, all a VPN does is encrypt traffic between one point and another. Once the traffic exits the VPN it will then continue onto its destination whether that is a legitimate system or a hackers command and control system. It will not prevent you from getting malware in the first place or prevent malware from being able to send your data out.


Does MEGA store my password or decryption key? How do they check the login information I entered is correct or not?

Have a look at this, it's actually quite descriptive: https://mega.nz/SecurityWhitepaper.pdf
Also mind you the link you mentioned is over 7 years old, things will have changed since then.

  How do they verify that the user enters the email / password correctly? While login information is sent to the server only email address.

When you create your account, you send information to the server that can be re-calculated using your password. As far as I understood from the documentation, when you login, a string is calculated from your password that is sent to the server as form of authentication token to be matched on their side. Something akin to sending the password for them to compare the hash, except the hash would have been calculated on the client side (this is not accurate, just a simplified example).
If you don't always have to enter your password, that's because you're caching this authentication token.

  I think they store the encrypted password or the key to decrypt the password as plain text or vice versa to check if the user information is entered correctly or not? And I noticed that every time I log in successfully, the server sends me the same decryption key, if both the password and the decryption key are encrypted on the server, how do they send the decrypt key has been decoded for me?

Your question is a bit confusing. And I am not aware of the implementation details of mega, so I may be off the mark here.
* It is possible that the service sends you AES keys for handling your files, although I find this simplistic and unlikely. Moreover it is also unlikely (and unnecessary) that they would hold this key in plain text;
* They almost certainly do not hold a cleartext version of your password. There's no reason to do that;
* It is possible that they hold copies of encryption keys in such a way that they can't be used to decrypt your files. Using asymmetric cryptography you are able to pull in the encrypted AES key and decrypted with key material that only you possess (calculated at the time of registration). Also notice that you would be dealing with multiple AES keys, not just one;
  * It is possible to have the system built in such a way that they are physically unable to decrypt your files simply because they do not have enough key material to do so. Ever. This is called zero-knowledge encryption and is incredibly rare and tricky to implement correctly; Boxcryptor and Spideroak aim to do exactly this and as far as I understand have got the right concepts in place. Check out their documentation.

  As far as I "understand", they use AES to encrypt most of the data, RSA just to create shared links (to people, emails, ...) and encrypt messages.

AES to encrypt information. RSA to securely exchange keys. Shared links are probably generated out of random data, it does not need to be decoded or decrypted, just very difficult to guess.

  In particular, the user password will act as the key to decrypt the user data (files, folders, ...) encrypted AES so the user password will be saved as plain text on the client or server can be used to decode their data?

Generally user passwords are used to calculate "data" using algorithms like PBKDF2, etc. But rarely is this material used as keys directly, since otherwise you would not be able to change passwords or else the keys would change and you'd loose the ability to decrypt your information. There is never a requirement to store passwords in plain text anywhere.

  If user passwords are used to decrypt their data, what is the key to decrypt their passwords? Created when? Where to be stored? And is it encrypted?

In order to securely share encrypted data, you need to use unique AES keys that are then shared to the list of recipients you assign. To distribute this key securely, you'd need to use their RSA asymmetric keys.

For example Data1 to be shared with users 1, 7 and 9 is encrypted with key AES1 [let's call it AES1(Data1)] and sent to each recipient respectively encrypted with their RSA public keys [RSA_P1(AES1), RSA_P7(AES1), RSA_P9(AES1)]. Each recipient is able to decrypt the AES1 key by applying their private keys [AES1=RSA_p9(RSA_P9(AES1))] thus being able to decrypt AES1(Data1) since Data1=AES1(AES1(Data1)).


Does PKI signature verification require secure distribution of public keys?

No. The keys does not need to be transmitted securely, but of course you must transmit them in a such way so they can't be replaced or tampered with, if you want to protect against someone distributing malicious data.

So lets say you are hosting a software repository. Even if you sign a software with your key, if a hacker gains access to the repository, he could upload malicious software AND also replace the "correct" signing keys with her own public keys, so if a end user validates the software, it will come out as valid. That is what the OP is asking.

In the same way, a attacker could replace keys during transmission (MITM attack), so if a user does http://www.example.org/signing_key.asc the MITM can replace the response with his own public key.

So simple signing of software and publishing the key on the software vendor's site, is more aimed to protect against mirrors getting hacked and starting to distribute malicious data.
Thats why some vendors just publish the SHA/MD5 hash of the software, thus the vendor does not need to completely rely on the security of the third-party mirror's.

Thats why its a good idea to transmit the keys using SSL, or have the key signed by a reputable origin (then it becomes a certificate, could be either a x509 one or a PGP one) if you also want to protect against malicious public key replacement.

Another way to protect against this, is that the end user does download and save the key during first interaction. Thus, if the repository later become compromised, the end user will have a saved "correct key", thus it does not matter if the key later become replaced, either during a MITM or hack attack.


Difference between Disk Encryption and Volume Encryption?

In practice, "disk encryption" and "volume encryption" (often prefixed with "full") are two terms for the same thing. It is almost always more correct to say volume encryption - I can imagine a disk encryption system, but as far as I know none actually are in use - but the terms are used interchangeably.
Now, with that said, I'm not familiar with SAP HANA, and it looks like it's doing something perhaps better termed "file encryption" or "data encryption". User-mode software approximately never interacts with volumes directly (except for operations like formatting or imaging), and a "volume" - especially in the sense of computer data storage - typically refers to a logical range of bytes suitable for e.g. formatting with a file system. (A volume is often, but not always, the same as a partition - which is a physical, rather than logical, range of bytes - but if you have e.g. two partitions which are spanned, they will form one volume.) Getting back to SAP HANA, the page you linked talks about securing against data access "at the operating system level". It's unclear whether this is supposed to be the OS that the software runs on (in which case true security is impossible, as the OS can always read the encryption key out of process memory, or indeed read the decrypted data out of process memory), or protection against the data being read by a different OS (i.e. after a disk was stolen and put in another computer).
It is possible SAP HANA writes to a a disk volume directly, bypassing the file system driver stack, but this is very unlikely. It's more likely that the "data volume" it refers to is contained in one or more files on a file system, and simply means the place where database data is persisted rather than anything an OS would recognize as a "volume". In that case, SAP HANA's "Data volume encryption" is simply a matter of encrypting that data (in userspace, with a key known to the process) before the data is sent to the disk. The degree to which this is a meaningful security measure depends on how secure the key is; it appears the key is stored in the file system, so an attacker with full access to the disk (either offline, or through an OS they control) can probably extract the key and decrypt all the data. However, an attacker that can only access specific files (potentially backups?) that do not include the key wouldn't be able to decrypt the data.
In this case, the difference between [full] disk encryption / [full] volume encryption and SAP HANA's data volume encryption comes down to two things: where the key is stored (must be re-derived or unsealed at boot e.g. from some hardware security device or a password, or just in the file system), and where the transparent encryption/decryption occurs (in the OS storage stack, or in the HANA process). Full volume encryption is meaningless against an attacker whose code is already running on the (virtual or physical) machine but is secure against somebody stealing the hard disk. Process-level data encryption is secure against an unprivileged attacker on the local machine who can't read the key, but is a trivial speed bump against anybody who has unrestricted access to either the file system or the running process.


What is this spam bot trying to do by filling in my PHP forms randomly?

I'm violating this site's guidelines by merely speculating, but my guess is that Attacking Host A tries to insert [some string] onto your site through a form and Attacking Host B tries to read [some string] from your site. You may notice the attempt and may blacklist the IP address of the form spammer, but if you are vulnerable the real attack won't come from that IP address. The form spammer is a disposable scout; it simply "tags" sites as vulnerable and moves on.


what security impact can be caused by injection of meta tags

Some meta tags like property og:image can have JavaScript in the property so you can steal cookies or redirect a user or many other Xss attacks

Meta refresh tags can also take a victim to a phishing page that spoofs the real one


It's not uncommon, but it may not be required. A lot of developers seem to forget that HTTPS traffic is already encrypted - just look at the number of questions about implementing client side encryption on this website - or feel that it can't be trusted due to well-publicised issues such as the Lenovo SSL MitM mess.

However, most people weren't affected by this, and there aren't any particularly viable attacks against TLSv1.2 around at the moment, so it doesn't really add much.

On the other hand, there are legitimate reasons for encrypting data before transmission in some cases. For example, if you're developing a storage application, you might want to encrypt using an app on the client side with a key known only to the user - this would mean that the server would not be able to decrypt the data at all, but it could still store it. Sending over HTTPS would mean that an attacker also shouldn't be able to grab the client-encrypted data, but even if they did, it wouldn't matter. This pattern is often used by cloud based password managers.

Essentially, it depends on what you're defending against - if you don't trust SSL/TLS, though, you probably can't trust the encryption code you're sending (in the web application case) either!


How can I protect myself from the VPN operator when using a VPN to gain free access to the Internet?

Once you connect to a VPN service, they can record what they wish. A potential way around this is to VPN the VPN, if the service allows it (most do not). An alternate method is to connect to Tor from within the VPN connection, if the service allows it.

Secure connections, like https, should be encrypted, so passwords transmitted in that way would be recorded, but not in the clear. The goal is to keep as much control as you can so that you can make it difficult for your VPN provider to understand what is being passed through their network.


In MySQL, # represents the start of a comment. This means the rest of the line will not be parsed as SQL. This is a common technique in SQL injection to force the trailing SQL after the injected SQL to be ignored.

In this case, by putting ' UNION SELECT '123' AS password# in the username field, it makes the command that's executed:

SELECT password FROM admins WHERE username='' UNION SELECT '123' AS password

This returns a row with '123' as the password column (regardless of the username provided), allowing you to log in with any username and the password '123'.


Are grsecurity kernels available through Arch and Gentoo repos suitable for production?

I think grsecurity is fairly clear as to whether they think they are suitable for production in the paragraph you quoted: they're not.
They are well tested and potentially patched by the Arch and Gentoo communities that use them and mark them stable but if you mean to advertise that you are using grsecurity to clients, you'll have a hard time saying that you're using versions grsecurity themselves deem unsuitable for production.
That was actually the whole point of restricting access to the stable versions of grsecurity after Intel continuously used their name without consent, even for unsupported kernel versions.
Overall, you're generally safe using them in a production environment, you just can't brag about it since officially, grsecurity doesn't consider the patches you're using.


What security does nginx provide between server blocks?

There's no isolation (from a security perspective) between server blocks -- server blocks only exist as a namespace for related directives.  Nginx can only have a single user configured, as it becomes that user just after binding to network sockets (which requires root to bind to ports < 1024).

What you can do, and what I have done in the past, is run the applications as different users.  You don't specify what language you're using, but for example, I run uwsgi workers, and run them under per-application users to isolate my applications.  The sockets need to be read/write www-data (I usually do this via group, so the unix socket for the app server ends up as appname:www-data, mode 0660) and static files need to be readable by nginx (if you want to serve static files directly).


How to defend against homograph attacks?

Browser vendors already try to protect you from homograph attacks by enforcing  policies how IDNs (Internationalized Domain Names) should be displayed in the URL bar.

Their measures include blacklisting potentially confusable symbols (e.g. ֊, the "Armenian hyphen" U+058A) and displaying URLs with characters from non-latin alphabets as Punycode under certain conditions. So, if you visit

https://wikipediа.org

the URL will be displayed in your URL bar as

https://xn--wikipedi-86g.org/

following the Punycode conversion rules, which you can easily distinguish from wikipedia.org.

If you're interested in the specific algorithm your browser uses to display IDNs, see:

Mozilla's IDN Display Algorithm
Google Chrome's IDN policy

However, converting bad IDNs while maintaining usability (e.g. you'd still want to display a literal ä to someone in Germany) has turned out to be somewhat elusive which is why even in 2018 new attacks have come up.

If you don't trust your browser's built-in protection, there is also a browser extension available which warns you about IDN domains (as @defalt points out). Or you can choose a manual way of detection, as @wchargin describes in his answer.


Is this a safe way to identify users connecting to a chat server?

You should ensure that your session token is random and at least 128 bits. Aside from that you just basically send a session token and a user id. To be fair, only your session token should be needed to identify a user since it is unique. Ensure also that you destroy the session token after the user logs out. Aside from that it seems similar to any other login scheme.


If someone hacks my wi-fi password, what can they see and how?

If someone knows my wifi password (be it WEP or WPA) what can they see on my screen? Do they just see URLs I visit, or can they see everything in my browser,....or can they see everything I do on my computer? Does using HTTPS make any difference?

They can't see anything on your screen (unless you've enabled some sort of unencrypted remote desktop screen sharing program).

They can, however, observe all the data being sent to and from your computer (I'm assuming for WPA/WPA2 they observed the 4-way handshake at the beginning of each session; or trivially forced your computer to start another handshake), unless you encrypted that data using a protocol like HTTPS.  They would typically run a packet capture program like wireshark to decrypt the wifi encryption.

Again, they'd be able to see what HTTP webpages you requested, what links you click, the HTML content of the webpages you requested, any information you post to a web site, as well as all data (e.g., any images/movies) sent to you or by you.  They can also interfere with the traffic being sent to you (e.g., alter the content you see).  Granted anyone nearby can always interfere and cause denial of wifi service without knowing your password (e.g., often turning on a microwave oven will interfere with all wifi traffic being sent to you).  Or have their own computer/router that they fully control that sends impersonated messages as you or your router.

If you visit HTTPS sites only, they can't decrypt the data (unless they have somehow additionally compromised your computer).  However, even with HTTPS they can see what IP addresses you are sending/getting data from (which usually will let them tell what domain e.g. if you went to 69.59.197.21 it's stackexchange.com).  They also will know when and how much encrypted data is being sent.  This is possibly enough to give away private information.  Imagine you went to a webpage via HTTPS that had results of your HIV test, and an eavesdropper was listening.  If the web page for a negative result showed 3 images (of specific sizes) and a 10 MB PDF file on safe sex, while the page for positive results had 15 images and three PDF files that were 8MB, 15MB, and 25 MB respectively you may be able to figure out what their results were by observing how much data was sent and when.  This style of attack has been used to figure out what people were searching for on a popular search engine (from the instant results provided for different queries) or roughly estimate what kind of income someone had at an https tax site.  See Side-Channel Leaks in Web Applications (pdf).

Granted all this information is also available to your ISP as well and to every intermediary router between your computer and the server you are trying to visit.

  Secondly, if the attacker does NOT live nearby, is it possible for them to set up a laptop in my neighbours house for example, and programatically record all my traffic...or alternatively can they relay the data from the laptop to their own computer elsewhere, via the web?

Either is trivial to program up assuming your neighbor doesn't mind them putting a laptop in their house (or they found a power source and place to hide their computer).


Got "Security alert" e-mail from Google about a sign-in from an unknown device I'd like to track down

I found out later that in fact the perpetrator was me and that Google had incorrectly identified a Samsung Galaxy Note 4 device of mine as an LG Nexus 5. To confirm this, in the "Security alert" e-mail from no-reply@accounts.google.com, I clicked "CHECK ACTIVITY", which brought up a webpage (the one titled, "New sign-in on LG Nexus 5") where I saw the alleged perpetrator's IPv6 address and the approximate time of the alleged breach. This perfectly matched my own login activity timeframe and my Note 4's IPv6 address as found in Settings | About phone | Status, under the heading, "IP address".

So it appears Google does in fact misidentify certain hardware models when informing you about potential security breaches, and that it's worth investigating the source of each security alert in case it's actually a false alarm like this.

I also found the following post relevant and useful: Google Account Compromised - Possible Investigation?


Based on your description and the link you've provided you've likely installed a CA certificate for SSL interception.

  ... how do I know the certificate I have is legit? That is, actually comes from Google and not from a man in the middle?

It does not come from Google. It comes from a man in the middle. It might be a legit man in the middle or not. It is usually not legit if you are using some public WLAN. It is usually legit if you are in a company which does SSL interception. But in this case ask your network administrator if you've got the correct certificate.

In any case: don't just install some certificate you've got from somewhere. In case of legal SSL interception these certificates get usually automatically installed at company equipment but you might need to install it on your own equipment (if you are even allowed to use this inside the company network). But in general you should only install such a certificate after someone you trust explicitly told you that this is legal SSL interception and not just because you've got some annoying certificate warning and just want to somehow continue with what you were doing.

For more details see Is it common practice for companies to MITM HTTPS traffic? and Is visiting HTTPS websites on a public hotspot secure?.


How to Best Minimize Damage After Loss of Computer

Welcome to Information Security!

Sorry to hear about the surprise layoff. That's quite unfortunate. From what I can tell you already took great security steps to change your passwords for your accounts and you enabled 2FA before this happened. Some other steps you can take is to revoke your Apple certs and privates keys and generate new ones. This will prevent anyone else from using the old one. It may be troublesome depending on what apps are currently using this cert but I don't see what else you can do here accept take the hit and do the extra work to change the certificate.

Also, a lot of sites now have the ability for you to see your "active sessions"  from your account. You can see where you are logged into your account and can end those sessions. Facebook, apple, google does this and I think...Dropbox, Onedrive and Box do this too. These settings should be under any Security/Privacy settings.

Depending on what type of information you lost I would also suggest you get yourself some sort of identity theft + credit monitoring solution so you can keep track of any suspicious activity. Nowadays most will monitor changes on your credit and provide Dark Web monitoring so you will be alerted when your information is being sold on the internet somewhere. Some good ones are USAA(if you have a military family member), Complete ID (if you have a Costco membership), LifeLock...for anyone. Do some research, there a lot of good companies out there to help you monitor your private information. The cost is well worth the peace of mind.

Last suggestion I can think of is to Freeze your Credit. Since the Equifax breach Congress passed a law last September to make is easier for customers to freeze and unfreeze your credit. Why freeze your credit?....To prevent anyone else pretending to be you from taking out loans in your name. By law the bureaus have to unfreeze your credit within 1 hour of your request and freezing and unfreezing are now free; before they charged you.

It's impossible to be 100% risk free with your information, the best thing you can do is try and mitigate the risks as much as possible. I hope some of these suggestions help you.

April


removing SSLv3 does not seem to fix POODLE problem

You must first look at all configuration files if SSLv3 is enabled on some vhost:

grep -i -r "SSLProtocol" /etc/apache

Take the list of files grep found, and edit the configuration as bellow:

SSLEngine on
SSLProtocol TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH

Restart Apache afterwards and it must work.


I then used chmod 755 for all directories and changed the password for root. Is it solved?

No, it's not. If your box is compromised, this will likely not help at all. The first action any attacker will do is to install tools to ensure access.
You have to reinstall it from scratch, and secure it better this time. How to secure it depends on what software you have.


How to set up a Virtual Machine for a Honeypot?

When considering advice, such as it is better to use a VM to host a honeypot, I think it important to also consider what conditions may have changed since that advice became 'popular'. In this case for example, it would be important to be familiar with new threats, such as 'Crisis' see http://arstechnica.com/security/2012/08/crisis-espionage-malware-targets-virtual-machines/ , as this malware has the potential to undermine your analysis because it can even infect a non-running VM image, thereby compromising your 'known' good/clean base.

Tim


Offloading private key operations to a trusted device

These days, Java Cards have competition: .NET Cards. The main principle is the same: user-provided code runs in a virtual machine hosted by the card itself. Your main problem will be of performance.

An important part of why such programmable cards are believed to be "secure" relies on this VM: the applicative code cannot escape the VM boundaries; for instance, it won't have a buffer overflow or be able to read or write arbitrary bytes in RAM. This feature comes at a heavy price: all the applicative code is interpreted. A smart card is already quite underpowered (a good smart card may feature, say, a 50 MHz ARM-like CPU) but the interpretation implies an additional slowdown factor of 10x or 20x, meaning that any cryptography you would like to perform on such a system will be slow as Hell.

To cope with that, these smart cards include hardware accelerators, i.e. native code and dedicated circuitry to do some specific operations, usually RSA. So such a card can still compute a 2048-bit RSA signature in less than a second, a performance which is quite a feat, given the hardware. But you won't have an accelerator for a not-yet-mainstream curves like the ones in NaCl -- you usually don't have accelerator for any curve at all.

Smart cards try to achieve tamper resistance: a secret stored in such a card should remain secret, even if it is stolen and the thief tries to pry it open. This kind of security tends to come at a heavy price. It may also be quite overkill in your case.


Why do CPUs operate speculatively with results of forbidden memory fetches?

Consider the following code:

mprotect(arr3, sizeof(arr3), PROT_NONE);
...
mprotect(arr3, sizeof(arr3), PROT_READ);
z = arr2[arr3[x]*256];

At some point, arr3 becomes readable by the process.  If the assignment (well, actually the dereference of arr3) has already been loaded before the mprotect completes, what behavior would you expect?  I would not expect a trap, since it's valid at the point.

Basically, you don't know what the state of the memory at arr3 is until the instruction before it has been retired, at which point the pipeline will have executed well past that point.

I suppose you could "speculatively trap" and re-execute if the memory permissions change in the mean time, but apparently that's not what is done today.  (Though I imagine it would be a much smaller performance hit than the KPTI software fixes.)


How to solve race condition in 2-factor authentication solutions like RSA Security tokens or Google Authenticator?

Not really, at that point you are dealing with a compromised client and pretty much all bets are off.  The best you can do is ensure the user is aware of the failure which will (hopefully) result in them asking questions or trying again.  When a user connects the old user should be booted.  This should make a legit user aware of the problem even if they don't understand it.

Also, if a client is so compromised, there is likely no need for a race condition, the attacker could simply use the compromised client that the user is legitimately using as the launch point for their nefarious deeds.  This wouldn't throw off any alarms since both the good and the bad are coming from the same client.


How can I detect the remote operating system?

Using nmap:

sudo nmap -O <target>

Or if they block your ping probes you can do:

sudo nmap -O <target> -Pn

Sometimes you still get fake results and you should try doing an aggressive scan (can be detected and blocked by the firewall).

sudo nmap -A <target>


How to encrypt using a private key file generated by OpenSSL?

Do not use the OpenSSL command line to encrypt or sign anything. The OpenSSL command line is a debugging tool. To encrypt or sign a message, use a tool designed for this purpose, such as GPG.

A private key file contains all the information needed to construct the public key. If you have a private key in a format that OpenSSL understands and you want to get the corresponding public key, you can use openssl pkey -pubout …. But that's not the format GPG needs. GPG generates its own keys.


Would it better to enforce more complex passwords or passphrases?

Length > Complexity in nearly all circumstances. It is easier for us to remember simple sentences, whereas complex passwords are more difficult.

"Abaconsandwich%ismyfavoritebreakfastitem!" is far, far, far FAR more difficult to guess by any method (bruteforce or dictionary) than something like "B@c0ntim3!?" This is because the number of elements is far more varied and long, and simple inclusions like a % sign inside the sentence can make password cracking all but unfeasible.

Good myths:
https://stormpath.com/blog/5-myths-password-security/

Everyone's Favorite:
http://xkcd.com/936/


Does using VPN on insecure host improve security?

As said in a comment, VPN grants the untrusted host access to the network. A quick VPN setup can allow that host to have complete access to all network resources. This is the part you must focus on: providing the access but only for the required service. That service can be seen in multiple ways: access to an IP, to some ports in the network or to even an IP and a single port. So the good practice is to filter this access and only allow the VPN system to access the least possible resources required to perform the job. If a host can only access a port on an IP address instead of a whole network, there's huge security difference.


What are the benefits and drawbacks of the HTML5 Keygen element?

Pros

It can improve security when authenticating (in addition to a multi-factor device)
If used as a "client certificate", it can make MITM attacks much more difficult
The Keygen tag is implemented across most non-IE browsers, making it very easy to implement
Works regardless of administrator permission.  With IE Active X controls can be disabled and IE and browser settings can make key generation impossible on tightly controlled systems.   In this situation the current Keygen in non-IE browsers is often the only error free method to generate and use Client certificates

Cons & Deficiencies

Certificates are not easily portable between systems  (to some, this is a "pro")
The private key is not stored in a standard location
The UI is confusing and difficult to understand
Requires the user to select the appropriate key length from a list. Most users are not equipped to make this decision.
Poor user experience when the user is prompted to download the certificate.  A better approach would have the key submission and certificate response integrated into the same control.  (possible solution also this on S.O. )
<keygen> does not provide a mechanism for managing certificate expiry
No standard key length or hash implemented across browsers
Algorithm support is missing (RSA, DSA, ECC, etc)
Keysize selection should come from the form, not user selectable.
The signature is based on MD5 (which can be mitigated by a time based challenge)
Non-Exportable keygen flag is missing
Hardware protected keygen flag is missing
Password protection required is missing
The certificate is limited to RSA based applications
The HTML form could be modified locally and key generation security reduced accordingly
If enrolling to a Microsoft Certificate Server, the only supported CertType is "server"
via DCOM API
The format used by  is not standard and only provides a subset of already established protocols like PKCS10 , CMC , and CRMF . This prevents  from supporting non-RSA based certificates, extensions for additional client information, and key escrow
Not supported in IE due to better support with CertEnroll and the issues described here


Internal IP's Probing to Unknown External IP's

I think the best way is to use NetFlow analysis for large scale monitoring. If you have a Cisco router they have NetFlow collection built in and you can combine it with the open source tool suite SiLK for analysis https://forensics.cert.org/

NetFlow was initially developed by Cisco for billing purposes and collects none of the payload, only summary information such as:

Source IP
Dest IP
Source Port
Dest Port
Packets
Bytes
Start time
End Time
Flags
etc...

With this you can quickly analyze large amounts of data, I have one installation of SiLK using the open source NetFlow replacement IPFix from the IETF that gets 150,000 events per second.

There is a free handbook to get you started: https://tools.netsa.cert.org/silk/analysis-handbook.pdf

This would do exactly what you want and provide long term security benefits such as trending and anomaly detection.

Another option if you want to do this just one time, configure a span port on the egress point and collect data using tcpdump for a short bit. Just be sure to delete the PCAP when you are done as it may contain PII.


What is the problem with multiple encryption and how do you know if you have decrypted a cipher?

For multiple encryption, there was a previous question:  Is multiple encryption a good idea?

As to how do you know if you decrypt it correctly -- usually you look at the output and decide if it makes sense.  E.g., does it have the file format of a gif/jpeg/zip file?  If it was plaintext does is it all ASCII or properly encoded UTF-8?  Ignoring non-ASCII code-points, only 96 of the 256 possible values of a byte are printable.  So if you decrypted garbage message with the wrong key and the message was 1000 characters long, the chance that all of them are printable ASCII letters by random chance will only be (96/256)1000 or about 1 in 10400.  Even allowing UTF-8 the characters have to be in certain combinations; e.g., if the first byte is of the form 1110xxxx (where each x could be either a 1 or 0), that means the next two characters both need to be the form 10xxxxxx to be proper unicode).  These sorts of things rarely happen by chance.

There's also often padding (that needs a certain form in the plaintext), checksums, or Message Authentication Codes that help distinguish garbage data from the wrong key, from actual data.

EDIT: If you encrypted a file twice with two different (symmetric) keys k1 and k2 and you tried decrypting c=E(k1, E'(k2, m)), there isn't a way you could just brute-force guess k1 by just examining the output of D(k1', c), which will appear random for any pattern.  You would have to brute force, k1 and k2 simultaneously to figure out properties of m.

However, its extremely infeasible to guess a high-entropy private-key by brute force.  The amount of work to brute-force a 128-bit AES key is about 2128, e.g., a billion (109) computers testing a trillion (1012) keys per second for a 1000 years would only have a 1 in 10 million chance in finding the right key.  So the gain from multiple encryption in this scenario doesn't seem to be much.

On the other hand, if you had asymmetric encryption with a known public-key, you can quickly check if the guessed private key is correct -- can you encrypt a message with the known public-key and then decrypt it with your guessed private key to recover the original message?


Is there any way to keep the request in intercepting proxy for atleast a min before application says check your connection?

The answer is almost certainly a solid: No.

The length of time that a client is willing to wait until it receives a response from the server is fully configurable by the client.  Either the HTTP library being used by this app has a short time set by default, or the app itself has configured the request to have a short timeout.  For an example, see this documentation for how you would set the maximum wait time for a request with CURL.  If an app has set a maximum timeout of, say, 2 seconds, then there is nothing you can do at the proxy level to make it wait longer.

If you were running the app in an emulator you would have more control (because you could effectively pause it while you did your thing), and if you rooted your phone you may have a way to trick it, but there isn't anything you can do purely at the proxy level.

Your only option will be to figure out how to modify the response quickly, either by pre-setting the response in your proxy, or by some sort of scripting option.

Also, as a general rule of thumb a minute is a long time in the modern network world.  In my experience even 2 seconds is a slow response.  I would expect most clients to have a default timeout measured in seconds, not minutes.  A mobile app that is built for high performance may use an even smaller timeout if the developers know that their API endpoints will return very quickly, and don't want the user to have to deal with a laggy experience.


Ubuntu supports Secure Boot. This requires UEFI-only mode. Please disable CSM. The TPM can be used by the Linux Integrity Measurement Architecture.

Back in the day, apparently IMA was very immature.
Progress is made.
It seems like IMA is compiled into Ubuntu since 14.04, according to this page.

From what i've been reading, still some works needs to be done.


Voting in a polling booth definitely has advantages as you can enforce that a voter is isolated. That makes internet voting difficult, but not impossible. In general we want some of five properties:

Ballot Secrecy - That each voter's choices remain secret.
Integrity - That each voter's choice is included unmodified in the final tally.
Untrustworthy Platform - A voter's ballot should be reliable and accurately transmitted from their personal computer.
Coercion Resistance - A voter should be able to cast the ballot of their choice even if they are voting in an unsupervised environment (and an adversary may be standing over their shoulder).
DOS-Prevention - The system should prevent small-scale and large-scale (D)DOS attacks.

For in-person voting, we want (1) and (2). For internet voting, we want (1) and (2) plus (3), (4), & (5).

Ballot Secrecy

Most current voting systems only achieve (1) ballot secrecy. For polling place voting, once you leave, you do not have (2) integrity and if you are using a computer (DRE) to cast your ballot, you do not have (2) even if you observe the entire day. It is possible that they even mess up (1): for example, if voters arrive and are timestamped when registered, and then ballots are timestamped when cast, you can correlate votes to voters.

Ballot Secrecy & Integrity

End-to-end verifiable (E2E) systems allow you to achieve (1) and (2). E2E systems have been used for in-person voting in governmental elections: Scantegrity in a municipal election in Maryland. For internet voting, E2E systems that achieve (1) and (2) only (not 3,4,5) include Helios, which has been used in student elections.

These systems work by throwing a bunch of cryptography at the problem. A voter essentially encrypts their vote (either explicitly if using a computer as in Helios, or through some human computable operation if using a paper ballot, like revealing a hidden code in Scantegrity). It is possible to use encryption functions that do not completely lock down the message: for example, you could take some encrypted messages and add them together under encryption and then just decrypt the sum (see homomorphic encryption), or you can take a list of encrypted ballots and shuffle them up under encryption so that you can't determine which ballot corresponds to which voter (see mix networks). Each step of the tally can be proved to be done correctly with zero-knowledge proofs.

Since the votes are encrypted, they can be posted publicly without breaking ballot secrecy, and voters can check to see that their votes are included unmodified for the final tally.

Ballot Secrecy & Integrity & Untrustworthy Platform

Systems that solve these three problems have not been used in an election yet, however there are two elections on the horizon that will use them: Remotegrity in Maryland (alondside Scantegrity for in-person voting) and the system in Norway.

These systems use two tricks: two-channels with the assumption that either one is trustworthy, and a technique called code voting. Over one channel (e.g., mail), voters receive a list of candidates with a serial number and unique codes (3 alphanumeric characters) beside their names. Over another channel (e.g., internet via their computer) they vote by submitting the serial number and code for the candidate they want. Assuming the computer is compromised, it can see the code but does not know (a) which candidate is being voted for and (b) what the valid code is for the candidate it would like to switch the vote to (or any candidate for that matter). It can guess, which will likely lead to an invalid code or it could just not let the voter submit anything: both have the equivalent effect.

Each vote that is received is posted publicly. Since only the person with the card knows which code belongs to which candidate, no one else knows how anyone voted. Voters can check the list to make sure their vote made it (and then there is some additional steps they can use to lock in their ballots).

Instead of assuming the codes are delivered by mail (which the malicious computer can't read), they could come through the computer but in the form of a CAPTCHA or something the computer can't read. One way of doing this is SpeakUp.

In any case, if someone showed their card to an attacker or the attacker was physically present with the voter, they could be coerced. This leads to...

Ballot Secrecy & Integrity & Coercion-Resistance

There are two approaches to addressing the coercion-resistance problem. One is to let voters cast as many ballot as they want, so they can overwrite previous ballots. It is possible to use cryptography to have hidden tags that can link votes from the same voter together, so that only one is kept. The problem with this approach is that an attacker just needs to wait until the end of the voting period (5 min before the polls close) to coerce a voter.

The second approach is to have real ballots and fake ballots. Voters who are being coerced or selling votes can use/sell a fake ballot, and the attacker cannot tell them apart. The tricky bit is to make sure only real ballots are counted and fake ballots are discarded without revealing if a voter submitted a real or fake ballot. Like above, we can solve this by throwing lots of crypto at the problem.

Systems like this are research-level only. None has been used or even planned to be used.

One way of doing this is called Selections. In Selections, voters use a panic password system. To vote, they submit a password. If they use their real password, the crypto ensures the vote is cast. If they use one of a large set of panic passwords, the crypto ensures the vote is discarded. The casting/discarding can be verified to have been done correctly for the set of all votes (not for each individual vote as that would defeat the purpose).

Therefore voters can just make up a panic password (it is easy to do in your head) on the spot if someone coerces them or offers to buy their vote. Later (or maybe they have already) they can cast their real ballot with their real password. No one can link the two together.

Aside: (D)DOS

This is considered a problem that is not completely solvable. An infected computer can always deny a voter from casting their ballot: what the untrustworthy platform property allows is for you to detect this, not prevent it. The DOS attack could also happen at the network level, taking down the server(s) receiving the votes. The integrity property can detect if any ballots are deleted or modified, but cannot prevent this.

The only solution is to use standard approaches for any web-service.

Ballot Secrecy & Integrity & Untrustworthy Platform & Coercion-Resistance

If we set aside the (D)DOS issue, this is the best system that we can achieve. To my knowledge, designing such a system is an open problem. It is non-trivial to compose the solutions for the untrustworthy platform issue with the coercion-resistance issue.

Disclosure

Scantegrity, Remotegrity and Selections are all systems I have worked on.


How safe is a PGP private key that has “escaped”, but without its password?

The point of a password is to prevent the key from immediately being compromised once it leaks.  It should be considered partially compromised though as the security is reduced from the keysize down to the password complexity.  If you have a high complexity password, it may still be an acceptable level of security for your needs, but generally it is advisable to work on replacing the key since security is reduced.

The urgency of the transition depends on your password though.  If your password was "password" then you should immediately stop using it and transition, but if it was something reasonably complex, then you should be able to keep using it for a bit and distribute your new public key to your contacts using it.  Don't use it for anything you need long term privacy on, but it should be fine for communicating out your new credentials with confidence that you still control the private key for the reasonable future.


Do digital camera perform steganography / watermarking?

Yes - well, sort of, albeit (as far as I know) unwittingly. I attended a conference where one of the relators was prof. Jessica Fridrich reporting on the identification of digital image sources. You can probably start your search on her page, here.

To be clear, this is nothing like intentional yellow-dotting performed by some printers, and cannot be used to trace a picture to a camera unless you also possess that camera and can take other pictures to compare.

What happens is that every CCD chip has subtle variations that can be recovered through frequency analysis from the original picture data, and these variations are manufacturer and chip specific. This allows, with a certain error margin, to:

given two pictures, determine whether certain areas of one picture are original or whether they come from a different source (the patterning in those areas is not consistent with the CCD)
given two pictures, or a picture and a camera, determine whether the picture came from that camera or not.

It would be extremely easy to make this system more reliable, by e.g. laser etching the CCD chips with a unique pattern. This would not be visible to the naked eye when inspecting the pictures, but the information could be recovered.


Ignoring the obfuscation, this is just a normal persistent XSS attack.

Your approach will not solve this. For one, the payload isn't actually in the src attribute, but the id attribute. An attacker could also simply skip the obfuscation (or use a different one):

<img src=x onerror=alert('do the thing')>

The reason for the obfuscation is likely to bypass any possible problems because of special characters or other filters.

The dangerous thing here isn't the value of the src or id attribute, but the existence of the onerror attribute, so sanitizing the former two wouldn't actually solve the problem.

To properly solve this, look into XSS prevention. If you don't need user-supplied HTML, you should HTML encode relevant characters in an HTML context (<, >, ', ").

If you do need user-supplied HTML, you should look into existing HTML filters for the language you are using (I wouldn't recommend to write your own, as it's notoriously difficult).


A protocol to authenticate users without login/password

Your idea is twofold:

Use an asymmetric key pair client-side for authentication.
Generate the private key deterministically from a password.

First part is standard issue in SSL; see the standard. Web browsers support it (but their GUI has long been ugly, confusing, or both).

Second part is not supported by widely deployed software, but it is not new, and it works, with the following caveat: it allows for offline dictionary attacks. Indeed, the client public key is public and is sent "as is" (within the client certificate) to any SSL server who asks for it. Also, by nature, the server must see it at some point. Since the private key is generated deterministically from the password, an attacker can then "try" passwords on his own machine, looking for a match with the observed public key.

This is actually very generic. Consider a system and protocol, where both client and server are "open": none of them stores any secret value, in the eyes of the attacker -- if the server can store secrets, then the proverbial list of (hashed) passwords in the server's database is enough. The only secret in the whole system is the user's password, which is stored in the user's head, and is unknown to the attacker. The attacker wants to recover that password.

Under these conditions, for any protocol you may come up with, offline dictionary attacks are possible. That's consubstantial to the openness of the systems: since the attacker is assumed to know everything about the whole setup except for the user's password, then he can emulate the whole thing on his own machines, for each potential password: the attacker runs both client and server in a virtual environment on his own cluster.

Throwing in RSA and hashing and whatsnot won't change anything to that. Once offline dictionary attacks are possible, you are back to the robustness of the password itself. There are ways to try to cope with offline dictionary attacks, but the situation is still, on the whole, uncomfortable.

To resist offline dictionary attacks, you must have a secret on either the client or the server. On the server, this is the usual model of hashed passwords in a database which the server tries to protect (with more or less success); the passwords are not stored "as is" but hashed, as a second line of defence. On the client, just store an asymmetric private key; possibly, encrypt it locally with a password, as a second line of defence. This is supported out-of-the-box by existing browsers (well, at least Firefox and its "master password").

Apart from the security concerns about dictionary attacks, there are practical issues with deterministic private key generation from the user password. In particular, what happens when the user changes his password ? His key pair mutates. Thus, all servers with which the private key is used must be contacted to acknowledge the new public key to accept. This brings to the dance the usual problem of public key distribution, then PKI, certificates and their ilk. This has long range ramifications.


CLI application running user defined command periodically

This boils down to a core question:

Is sh a valid command?

If so, then the user already has access; there is nothing further to contemplate in the question as-stated; a "malicious" user will have just as much access as a "non-malicious" and you should go to a regular threat model for potentially-malicious logged-in users, such as sandboxing.
If not, then you really ought to:

Set up a whitelist of permitted commands
Ensure you are sanitizing (or, better-yet, parameterizing) user input appropriately

example: if your toy CLI application is a Python program—
def handle_user_input(untrusted_string: str):
    user_command = shlex.split(untrusted_string) #: list
    if not user_command[0] in whitelist:
       raise ValueError("Non-whitelisted command.")
    store_command(user_command)

def event_callback(user_command: list):
    """Is called on the parameterized, whitelist-checked user_command list every interval"""
    assert isinstance(user_command, list)
    assert user_command[0] in whitelist
    subprocess.run(user_command)

Consider contingencies for when one of the whitelisted programs has a shell-execution vulnerability anyway, and this use-case reduces to what where sh is allowed (i.e.: sanbox the user.)

Your threat-model is poorly-defined in the question as-stated, but I hope this helps.

Also, check out this answer on another question — he expresses much better what I've tried to communicate here.
Allowing them to "run a command" is tantamount to letting them log in (after all, that's what "logging in" gates in the first place.)


Is there a way of achieving perfect forward security with one directional messages?

Not with only a long-term key pair to start with

If all the recipient needs to know to read the message is his long-term private key and the ciphertext, then that is also all any attacker will need to read the message in the future.  In order for the message to remain secure in the case his long-term private key is compromised, there will need to be some additional information known only to the recipient involved in the encryption (such as the short-term private key normally used in perfect forward secrecy).

However, there might still be a way to achieve perfect forward secrecy without requiring two-way communication at the time the message is sent.  One could imagine someone publishing a calendar of public keys for which he holds the private key, rather than a single public key - and then deleting all copies of each private key as its date passes.  This would effectively make all of the private keys into short-term keys, which would no longer be open to compromise once their date had passed.


Why does OpenSSL need the private key to revoke a certificate?

It is a bug of OpenSSL (at least in version 1.0.1c); precisely, a bug of the command-line "ca" option handling. If you look at the apps/ca.c source file in OpenSSL source code, you may see that the MAIN() function begins by parsing the command-line options, then reads the configuration file, then does this:

    /*****************************************************************/
    /* report status of cert with serial number given on command line */
    if (ser_status)
    {
         /* some stuff */
         goto err;
    }

    /*****************************************************************/
    /* we definitely need a private key, so let's get it */

    if ((keyfile == NULL) && ((keyfile=NCONF_get_string(conf,
            section,ENV_PRIVATE_KEY)) == NULL))
            {
            lookup_fail(section,ENV_PRIVATE_KEY);
            goto err;
            }
    if (!key)
            {
            free_key = 1;
            if (!app_passwd(bio_err, passargin, NULL, &key, NULL))
                    {
                    BIO_printf(bio_err,"Error getting password\n");
                    goto err;
                    }
            }
    pkey = load_key(bio_err, keyfile, keyform, 0, key, e,
            "CA private key");

Which means that the code will recognize the special case of checking on the revocation status of a certificate (command-line option -status), which of course does not need the CA private key, but will otherwise insist on loading the CA private key, whether it will be actually needed or not.

In particular, revoking a certificate, in the context of this tool, means marking it as revoked in the index.txt "database" of issued certificate, which does not use the CA private key. What uses the CA private key is signing the CRL (which informs the rest of the world that the certificate is really revoked), but the -revoke command-line option does not trigger that (it is the -gencrl option which implies issuance of a new CRL).

Summary: "openssl ca -revoke" implies reading the CA private key for no good reason at all. Feel free to patch the tool from its source code, and possibly submit the patch to the OpenSSL maintainers.


What does it mean to sign a public key and what's wrong with signing someone else's key?

As explained over at explain xkcd, key signing parties are a way to meet a lot of people and check their IDs easily in order to sign their (GPG) public keys.

Signing public keys is essentially vouching for the identity of the key holder, as not everyone can make sure it's actually the key of the real person they'd like to talk to.

Thus, the so called "web of trust" is a way to establish trust in otherwise unknown keys - if a lot of people signed the key, the idea is those can not all be fooled, identity-wise.

Hence, signing a strangers key without checking their ID (or somehow else establish trust in that this key belongs to that person) is a bad thing for the web of trust.

Additionally, there might be a word play regarding "key signing parties" and "key parties", the latter being a lifestyle party where men put keys in a bowl and women draw keys as random from that bowl, leaving the party with the key's owner.


Is forbiding the ; char enough to prevent SQL injection?

TL;DR No, your friend is not right. INSERT, UPDATE, DELETE and DROP TABLE aren't the be-all and end-all of SQL risks connected to SQL injection.

The very simplest thing I could do with that query is ask repeatedly for a user by the name of SLEEP(3600) (or john' OR SLEEP(3600)=') and, voila, denial of service (as soon as the available connection pool is exhausted - unless memory gets filled up first - while all extant connections are locked waiting for the 3600 second (1 hour) delay to expire).

I could use UNCOMPRESS(HEX2BIN(...)) with a suitable string to trigger a string expansion bomb.

Then I can explore other tables (and possibly even other tablespaces) by using the UNION keyword. If the permissions are set incorrectly and passwords are not properly secured, which happens waaaay more often than you might think, a JOIN against mysql.user can do a world of damage.

And if the user really has "all read privileges", then I could UNION SELECT a nifty variable called @@secure_file_priv and, if it was empty, I could replicate the SLEEP trick using a little-known function called LOAD_FILE(), which under the proper circumstances allows reading - for example - the access passwords to several Web applications that store them, MD5-hashed but not salted (and thus vulnerable to reverse hashing), in insufficiently protected PHP files for ease of recovery.

Finally, what version of MySQL are we talking about? Because this can be deadly important. The ability of using UNION with a known table equals to me being "able to run any SELECT query with the privileges of an authenticated user". In some cases - this is the first I found with a few seconds' googling - this might be a whole lot more than you bargained for.


Could bug bounty hunting accidentally cause real damage?

Can bounty hunting cause real damage?
Sure. As you pointed out, some SQL injection vectors may inadvertently cause data deletion. Similarly, a persistent XSS attack may trigger in the browser of a real user. Or unusual characters in a username may crash a web application backend due to an unhandled encoding error.
More generally, a large part of black box pentesting involves experimenting with unexpected/invalid input to the target application. Some level of fuzzing is usually unavoidable - and this always carries the risk of causing behavior that breaks the application or corrupts data. So, while blindly trying out DELETE queries may be reckless and avoidable, vendors have to face that even benign bug hunting occasionally impacts service integrity or availability.
Did a bounty hunter ever cause actual damage?
This report is an example of where the researcher caused a DOS by submitting invalid data. I'm entirely sure there are more severe examples, many of which simply weren't made public. Anecdotally, I remember several occasions where bug hunters were banned from programs because the tools they used were too disruptive.
How do bug bounty programs manage this risk?

A testing environment. While some bug bounties assume you're testing against production, many provide a separate sandbox and only allow you to test there. E.g., the program of Bitmex includes the rule:

Only test on testnet.bitmex.com.

A "responsible research" policy which asks that hunters make an effort to avoid damage. Rules would include not accessing real user data, limiting automated testing tools, etc. For example, Facebook's program demands:

You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) unauthorized access to or destruction of data, and interruption or degradation of our services. You must not intentionally violate any applicable laws or regulations, including (but not limited to) laws and regulations prohibiting the unauthorized access to data.

An emergency contact point. Some providers instruct hunters how to notify them immediately if their actions have caused service disruption. From the program of Exodus:

If you do accidentally cause some noticeable interruption of service, please immediately email us so we can handle it accordingly h1@exodusmovement.opsgenie.net and please include the subject title "HackerOne Outage: " for the alert to trigger.

Safe harbor clauses protect participants
Nowadays, many program policies come with a safe harbor clause. This is intended to protect hunters from liability if they act in good faith, even if their actions have caused damage. Since IANAL, I can't comment on the effectiveness of such a policy, but it's an established practice. Here is an example of a safe harbor clause in the program of Dropbox:

We will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. We consider activities conducted consistent with this policy to constitute “authorized” conduct under the Computer Fraud and Abuse Act. To the extent your activities are inconsistent with certain restrictions in our Acceptable Use Policy, we waive those restrictions for the limited purpose of permitting security research under this policy. We will not bring a DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope.

You'll find a similar passage in the rules of most large programs.


How this kind of mechanism considered as vulnerability?

The article simply doesn't contain enough information to asses the situation. Sending a password (without further encryption/hashing) over SSL/HTTPS is secure, if SSL is used correctly.

Perhaps the certificate validation was insufficient, allowing a MitM on SSL. (One of the comments claims that this was the case for your example.) If you don't validate the certificate the server sends to you, an attacker can impersonate the server. In such a scenario the information still gets encrypted, but with a key the attacker chooses.

Against active attackers, SSL is only as secure as your certificate validation.


Should one sign and encrypt using the same key? The Azure Training Labs are taking this approach

It is a general best practice to use two separate key pairs (and hence certificates) for signature vs. encryption.  I just refreshed myself on the reasons why:

When a key is used for encryption,
it's often wise to escrow it so that
if it's lost, the encrypted content
is not also lost.  However,
non-repudiation associated with a
signature certificate isn't viable
with multiple copies of the key pair
around.  So you don't want to escrow
the signature certificate.  From
Wikipedia

That's the best one I've heard of.  A lot of the time what I'm told is "just do it", and given that often one has to work within the constraints of the PKI one is forced to use, that's a fair enough statement.

Personally, I think for a simple PKI, bundling the two together - especially if you are using the "encryption" capabilities of the key for something like SSL - a transitory type of encryption for just point to point communication - then the security risk is not that high.

However -- sometimes you have to be ready to work with any PKI that comes along.  So if the code had hard coded the assumption that the encryption certificate and the signing certificate will always be the same thing, then I think you have an interoperability problem.

As a last thing - I'm a little confused on the code - I'm assuming that "ValidateToken" does the validation of the signature on the token, right?  It can't be both decrypting and validating the signature using the same key pair...  encryption is for sending to the key pair holder, signing is for verifying information from the key pair holder.  Is it just doing a signature validation here?


Can older or custom web browsers override the same origin policy?

The purpose of the same-origin policy is to protect the user (client) and not you (the server). Thus, it's irrelevant in this case. Attackers can use tools like wget, cURL, and even simply inject custom JavaScript in modern browsers using readily-available tools such as Developer Tools.

Therefore, it doesn't matter if old browsers have certain behaviours or not, an attacker will probably not use a browser at all.

All rate-limiting rules and restrictions must be applied server-side.


Filtering network access on a user/group/process basis

I have no experience of SELinux, but it is not necessary if you want to filter network access by users and groups. You can use the owner module to iptables, with rules like -m owner --uid-owner guest or -m owner --gid-owner staff.

There are several examples on our Unix sister site, in particular:

How to restrict internet access for a particular user on the lan using iptables in Linux
SELinux outbound access to other sites with restrictions
Dual network connection


Check uploaded python script for security issues before running it

Sorry to say, but this seems like a really questionable thing to do. Period.

There's a famous blog from Microsoft called "Ten Immutable Laws Of Security". Law #1 is:

  Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.

There's a reason it's number 1; creating a list of "bad things" to block is a losing game: for a full-featured and complex language like python, there will always be more creative ways to do bad things that aren't in your list.

I would encourage you to consider why you need to allow users to upload scripts, and whether you can accomplish the same functionality through a set of UIs, REST APIs, or some other standard method where the security is well understood.

If you absolutely need to allow scripts (python or any other language), then I would figure out the minimal amount of python syntax that users need to accomplish whatever it is your site does and reject any script that uses something not on that list. Do your research about every item on that list and whether it could be used to make a system call or otherwise change files on your filesystem. If that list includes import then you know you're sunk right off the bat because then you're faced with either trying to enumerate everything on your sys.path and block the "bad things", or trying to enumerate which modules users need, which methods within those modules they need, and manually verifying that nothing bad could possibly be done with them. Even assuming you have good well-researched lists, building the regular expressions to properly enforce the list is probably a difficult task in-and-of itself.

The other approach is to assume the server is totally compromised all the time, don't use it for anything else, keep it in its own isolation network far away from any other servers you care about, firewall off any outbound traffic, and tear it down and stand up a new one every now and then.

The idea of letting users upload and run scripts on your server seems a bit like letting random teenagers experiment with fireworks in your living room.


Is using Argon2 with a public random on client side a good idea to protect passwords in transit?

Argon2 is not meant to protect anything against MITM. It's not the right tool for the job. Using Argon2 on the client side (with or without TLS) will force you to either store the plaintext password on the server side, or it will make the hash become the password: in both cases you end up usually worse than when sending the plaintext password over TLS.
You might need to think more about your threat model.
Extended answer:
A "solution" can be worse when you look at your overall information system, and not just on one threat. An extra layer that does not significantly improves security might needlessly increase the complexity of the system, the chances of bugs to happen and the number of interfaces an attacker could try to exploit, thus decreasing the overall security of the system.
In your case, if your hash becomes the password, and you save this hash in the database, it is as bad as saving plaintext password in the database; especially since you are assuming an attacker able to do MITM in TLS, who should be able to replay the hash to authenticate. If you are not assuming that an attacker can have this capability, you do not need this extra layer of protection.


Privilege Escalation TTY error while using sudo /usr/bin/vi command

I know exactly what you are talking about and you are almost on the right track.

the sudo is letting you run /usr/bin/vi but in the same way you can't just do sudo vi somefile.txt, maybe there is a reason you can't do sudo /usr/bin/vi somefile.txt

For those wondering, I am hesitant to give an exact answer because this is an active CTF and it is discouraged to give the solution until it has been retired.


Connecting to company VPN with my own PC - what can they see?

It depends on the VPN used and I have never used Citrix. But AFAIK, VPN solutions commonly configure the network in a way that the machine is seen as local to the remote end of the VPN. That means that once connected to the VPN, all your network exchanges go through the VPN connection. Any other way would open an uncontrolled gateway between the internal network and the global internet.

All corporate VPN solutions I have used were that way: once connected, all network traffic goes through the VPN.

That means that your company should not know what files exists on your computer and for privacy reasons should not even try to know. But if you connect to Netflix once the VPN is on, it is likely that both the requests and responses pass through the VPN and the corporate proxy to internet. You should control what routes exists on your machine when connected to the VPN to confirm it, normally the command netstat -r can be used to show that.

Of course encrypted exchanges should normally not be decodable, but network admin generally abhor netflix requests through their network...


How far should I go in creating anonymity?

It sounds like anonymity is the opposite of what you want.

If you see me naked is it still a violation if you don't know my name?  Your system is a lot like this,  you are collecting personal information and then obscuring who it belongs to but at the end of the day you need to associate a large fact base with an individual,  and that is what people fear.

I would make sure your system is at least as bad as Google's stance on privacy.  Google is pretty awful when it comes to privacy,  but they are widespread and most of us have become accustomed to their targeted ads.  If you are worse than Google then you might get the wrong kind of attention.

You should also respect the Do-Not-Track HTTP flag.  It might not be against the law to ignore this flag right now,  but I am sure it will be.


The sleep command works on both Linux and Windows. The time for the software to respond normally vs when using the sleep command would indicate that the code execution works.

This would also not require any network traffic to show it was working which could be a benefit if outgoing traffic is blocked by a firewall.


Within an unprivileged application, there's no good way to store confidential data and hope to erase it and only it. If you write the data to a file, you don't know where this data will end up. SSD remanence is the least of your worries (and it may or may not be a worry depending on whether the flash controller implements a secure erase — I don't know how common this is on mobile devices). There may be multiple copies of the data on the filesystem if the file was written multiple times (either overwritten or replaced), if the filesystem was rearranged as part of defragmentation, if the device was backed up and restored, in the filesystem logs, …

On iOS, your best bet for small amounts of confidential data is the keychain. (If you have large amounts of data, encrypt it with a random (per-device) key and store the key in the keychain.) This is not a panacea (FAQ, SO thread), and as all things Apple there is very little publicly available technical information, but is likely to be better than most of what you can find on current mobile devices. There is nothing similar on Android.

If you want a full device wipe, that's a very different matter. Recent enough versions of iOS and Android offer a fast wipe feature (and I believe Blackberry does as well). This is handled at the OS level, not at the application level, but in an enterprise setting, it is common to grant the organization's IT team the permission to trigger a wipe remotely. (The fact that this indiscriminately erases both enterprise data and user data is a hurdle for BYOD adoption.) Fast wipes work by encrypting the whole storage except for a header containing the encryption key, and overwriting the encryption key. This is not foolproof as you may be vulnerable to SSD remanence, but it raises the bar significantly for an attacker.

On iOS, this feature is available on all devices running iOS 5 as well as some older devices running iOS 4. Android also has a device wipe feature which can be triggered by applications with the appropriate permission; I don't know what versions or settings wipe by overwriting the encryption key.

Remember that even if you throw the device in a volcano, there may exist other copies of the data in backups in the cloud (somewhere on Google's or Apple's servers) or on the user's PC.


Suspicious Redirect to malicious website

Seems like DNS cache poisoning to me. If your computer is running windows and it's not connected in an Active Directory, run in cmd "ipconfig /flushdns", without the "". If you are using Linux or MacOS, google the equivalent command and tell me in the comments if it helped, or we have to think of more options.


My ISP (BSNL India) is injecting ads using Phozeca which spoils websites and makes them unresponsive, can anything be done?

I had similar issues. I have a simple trick but it is temporary, but it is working for me and stopped BSNL ISP from tracking and pushing malware AD popup. I added a host entry in my computer for bsnl.phozeca.com and pointed it to localhost.


What are the potential security risks of using a commercial VPN service?

Broadly speaking, using a VPN does not eliminate all risk, it is about shifting the risk (perceived or real) from your ISP to the VPN.

People have different reasons for using a VPN like:

evading government surveillance
becoming more 'anonymous'
accessing geographically restricted content (streaming, movies)
protecting themselves against rogue access points when on the move

Depending on what you are trying to achieve a VPN can be a solution... or not.

The worst risk imo is that the VPN will often turn out to be useless and will not help you achieve your goals. I am not going to cover all possible scenarios but suffice it to say configuration errors are very common, at least client-side like:

leaking DNS requests
leaking IPv6 traffic

Or:

disconnections

If you are looking to 'cloak' your traffic from the authorities then the plan is not being fruitful. And most people don't have the technical skills to thoroughly assess their VPN setup.

  It's recommended to research and find a trustworthy VPN service, if
  needed. What could happen, if the service provider acts against their
  users? (Because of malicious intent or a security breach)

We should first define the meaning of 'trustworthy', because everyone probably has different expectations. Some people must think that a trustworthy VPN service is on that will never cooperate with authorities, even if you engage in highly illegal activity. The second aspect is how do we assess trustworthiness. I would guess: based on their track record, except that you won't hear so often about people indicted thanks to cooperation from their VPN service (but it happens).

You usually don't know the people running the VPN service so why would you blindly trust strangers with your Internet traffic ? Providers of VPN service talk a lot about privacy and make often misleading claims about 'not logging traffic', but there is no way to verify those claims.

If you are paranoid you can set up your own VPN service, cheaply. All it takes is a decent VPS. But that does not solve the confidentiality problem completely. The webhost could be monitoring (or logging) your activity. At least you have full control and you can configure it the way you want. But you become less anonymous too (because your Internet activity is tied to a static IP address). Again, it depends on your goals.

  Can the VPN connection potentially work both ways, as in: The provider gaining access to home networks? (When using OpenVPN or proprietary client software)

This is an interesting question. A VPN is a network tunnel so it works both ways. The provider has to segregate traffic and isolate the activity of clients. As for yourself, you should have a firewall on your computer. The other end of the tunnel can probe your computer. If the VPN is misconfigured (lack of isolation) it is conceivable that others on the same network segment could also probe you.

There are some other risks, that are not technical but practical. Many websites block VPN outright or flag their users as potentially high-risk clients (they assume you have something to hide). If you order some stuff you may be subject to increased scrutiny because of your IP address. Your credit card payment could fail become you appear to come from another country. At times you will be asked to justify yourself.

Keep in mind that the IP address ranges of popular services are usually well-known - lists exist. Since you are sharing IP addresses with other people you can also be affected by the bad actions of other people. Imagine that you are ordering stuff from some site, and another person defrauded them, using the same VPN, possibly the very same IP address. What the vendor thinks: you are the scammer and you're trying to pull another scam. You: trying to prove your innocence.

Worse, if you had an existing account in good standing it could be jeopardized/tainted because of that fateful connection made using a third-party VPN service.

In 2020 algorithms make decisions, risk assessment is computer-driven and humans are not always in the loop to endorse decisions. There is no such thing as automated justice. On the other hand automated discrimination does scale pretty well.


Is it possible to read files in a mobile phone for carriers through mobile network alone?

Just because you do not have a data plan does not mean that the phone company can not issue a reprogram to the phone and activate the data functionality regardless of if you are paying them for a subscription to data.  That said, what level of access they have to the phone's OS, even with a data connection, depends on the way the device is configured.

If the device has been installed with a clean copy of the OS that doesn't trust any software from the carrier, then accessing data on the phone likely won't be possible even with an open data connection.  If the phone is unaltered out of the box, it may be possible that the carrier has software in place to allow remote access and management of the device's OS installed though.

Their capability would then be anything they could program in and decided to do.  In theory, it would even be possible to tell a pre-installed application to turn on the data radio when receiving a particular call or SMS message, so turning off the data connection on the phone might not be sufficient to prevent remote activation.

It might not be known if such software is placed on the particular phone by carriers, but there also isn't really anything to stop them and is even a reasonable use case for it (in recovering stolen phones).


Is a simple, but very long password a good password?

Well it depends on what method the attacker is using to crack passwords. If they are using dictionary attacks, certainly this will be very safe. After that, the attacker can try pure brute-forcing, and those methods usually try all shorter passwords before longer ones. So against common automated attacks like these, you are probably pretty safe.

As mentioned, it might be a little awkward to type in a password like this around people, since it's easy to "read" from your keystrokes. However, it wouldn't be that hard to modify these simple passwords to be a little more complicated to make them harder to read.


The OpenPGP standard includes format for encoding private keys as sequences of bytes, and for symmetrically encrypting sequences of bytes with a password-derived key. While any PGP implementation is free to store private keys in any way that it sees fit, most (if not all) will use the OpenPGP formats.

The critical point in password-based encryption is how the password is derived into a key. This is all the password hashing theory: the derivation process shall be made slow (e.g. with a configurable number of iterations) and should use a variation parameter called a salt. OpenPGP includes a "decent" password-based key derivation, called Iterated and Salted S2K. If you take care to specify a high enough count (that is, as high as is tolerable on your machine), then you can get good security. With the GnuPG implementation of OpenPGP, the iteration count is specified with the --s2k-count command-line option.

Of course, the primary defence against brute force on a password is to choose a strong password, that is a password with a lot of randomness in it. Iterations and salts are just methods to cope with the not-so-strong passwords that erupt within the tangled mess of human neurons.