How secure IIS run together with XAMPP? I'm using IIS for web server & run phpMyAdmin via IIS.

But now, I saw someone use IIS and XAMPP. There is something I wanted to know.

Usually they set : XAMPP to localhost:81 or localhost:whatever

Something that I wanted to know is the phpMyAdmin run inside IIS is more secured than run phpMyAdmin via IIS ?

So, which one is better ?

1. Using IIS to run webserver (PHP) and phpMyAdmin
2. Using XAMPP inside IIS, then run webserver (PHP) using IIS and phpMyAdmin using XAMPP

There is something I know, I cannot directly access to phpMyAdmin if run on localhost:81, if I need to access phpMyAdmin I should open my server. But  I ever got hacked when I'm using XAMPP  to run PHP and phpMyAdmin.

Was looking to so many site for the answer, but still don't get the answer.

Effectively you do not ever want administrative consoles, administrative applications, or insecure applications exposed to untrusted networks such as the Internet.

It is possible to run these web-apps on other internal ports or simply ports that are not accessible to the outside world or other untrusted networks, then access the web-apps via a VPN. This would allow you to VPN to your server to do web-based configuration tasks and/or use the untrusted apps without exposing them to the Internet or untrusted networks.

The concern is that in some cases when you add such web-based administration tools these can be exposed to both the external (untrusted) and internal (trusted) networks at the same time, especially if it's via the same server daemon. So you will want to do a test to confirm this is not the case.

Alternatively, what some people do is run two different webservers on the same system (For example you could run IIS for external apps on ports 80 and 443, then run Apache with another app on a high port such as 32443 which is either blocked by a firewall or run on an internal loopback address such as 127.0.0.1. There are many ways to do this.

Back to your question of relative risk. The system with more code/applications accessible to the untrusted networks will be at greater risk from the untrusted networks. If you are comparing two applications side by side it will be a relative comparison at a given point in time taking into account the security controls in place for each application at it's most current version level.

In a direct comparison of the following two:

1.) ISS + PHP + phpMyAdmin
2.) ISS + PHP + phpMyAdmin + XAMPP

One would expect the second combination to be likely to have more vulnerabilities at a given point in time because it effectively exposes more attack surface. There are exceptions where added software adds additional security controls but in general this is an easy way to look at your exposed attack surface.

Note: There are many other ways to solve the problem you are trying to solve. You could also look at using tools like mod_security and the use of static IP's with firewall configurations too.

Finally, I have to point out that no matter which way you go you will want to do a lot more to secure this system if it is exposed to the Internet.


How is security maintained in session and JWT? I have been using Passport.JS session for a long time without really caring about security concern. For next project I thought of replacing session with JWT but security related concerns arise as I research more about JWT.

So if I use JWT for authentication, there are two types of tokens, an auth token and a refresh token. When I log in, I get a refresh token and this is used to communicate with authentication server to receive an auth token which will be used to get any sensitive information from the data server. The refresh token should be comparatively long lived, as opposed to the auth token which is short lived and be refreshed by the refresh token.

This refresh token should be stored somewhere. Common suggestion has been local storage but then a token that can generate infinite number of auth tokens is exposed to the client side - this doesn't feel safe.

Same applies to sessions. When we store sessions using libraries like Passport.JS
ID is (usually) serialized into session storage. Then another client can take the serialized session and use it to authenticate in another device (is this true?).

So none of these two methods seem very secure (if what I have said above is correct). Are we using JWT and sessions with the mentioned security risks or am I understanding this wrong?

I think your understanding is on par with what the technolgoy does.
Both methods have inherent security risks and security pros. But I think JWT wins for me as it allows you to do without sessions and I deal with session apps everyday, they can be a security nightmare.

There are several articles that can address the security concern for storing refresh/auth tokens if that is your main concern. Here is a JWT article by Auth0.
Here is another Article using nodeJS and JWT.

The point I'm making here is, if you are going to utilize either of these technologies, securing where your sessions or refresh tokens are saved needs to be carefully done as compromising that may lead to a security headache.

Note however in the case of JWT and refresh tokens, they can be easily blacklisted by the authentication server, requiring generating new ones which invalidates your old auth/refresh tokens.


Avast performing an attack? I have a Toshiba notebook, which came with Norton Internet Security.
In addition, I have installed Avast.

I received a warning from Norton about a OS Attack: GNU Bash CVE-2014-6271 intrusion attempt.

Norton "blamed" Avast, in my own computer, for the attempt.

How should I regard the warning?

More details follow.

I was at a hotel.
I had plugged an external long range Wi-Fi adapter for the first time in my PC. It was not operative since I do not have the drivers installed yet, but perhaps it was involved in the attack.
The report is attached below. It mentions 4 items involving 2 different IPs. It is confusing about who were the attacker and attacked. OFFICE2 is the name of my computer (unless some device replicated it).
My intention is to let go Norton when the trial period expires, but for the time being, both are active. The point in question here is beyond the convenience or not of having both active.
I have found only one link with a similar case. It is brief, and in Arabic, I guess.

Report:

Category: Intrusion Prevention
Date & Time:  15/09/2015 01:20:45 p.m.
Risk:  High
Activity:  An intrusion attempt by OFFICE2 was blocked.
Status:  Blocked
Recommended Action:  No Action Required
IPS Alert Name:  OS Attack: GNU Bash CVE-2014-6271
Default Action:  No Action Required
Action Taken:  No Action Required
Attacking Computer:  "OFFICE2 (10.100.105.51, 56941)"
Attacker URL:  10.100.100.1/cgi-bin/a2/out.cgi
Destination Address:  "10.100.100.1, 80"
Source Address:  10.100.105.51 (10.100.105.51)
Traffic Description:  "TCP, Port 56941"

Network traffic from 10.100.100.1/cgi-bin/a2/out.cgi matches the signature of
a known attack.  The attack was resulted from \DEVICE\HARDDISKVOLUME4\PROGRAM FILES\AVAST
SOFTWARE\AVAST\AVASTSVC.EXE.  To stop being notified for this type of traffic, in the
Actions panel, click Stop Notifying Me.

This is probably an issue with the co-existance' of multiple realtime AV software. One will suspect the other one's activities as malicious.

Avast is trying to scan your router/default gateway and Norton flags it as malicious here. You should uninstall any of the two as soon as possible.

Running multiple AV's on the machine can have effects like low performance, instead of increasing security, it decreases the security level, more false positives etc. Instead of running multiple AVs you can supplement your favorite ONE with Anti-Malware tools like Malwarebytes antimalware or Hitman Pro and observe safe internet usage practices.

Also, when uninstalling any, be sure to use the removal tool provided by vendor.
For Norton : Norton Removal Tool

  Using more than one anti-virus program is not advisable. Why? The
  primary concern with doing so is due to Windows resource management
  and significant conflicts that can arise especially when they are
  running in real-time protection mode simultaneously. Even if one of
  them is disabled for use as a stand-alone on demand scanner, it can
  affect the other and cause conflicts. Anti-virus software components
  insert themselves deep into the operating systems core where they
  install kernel mode drivers that load at boot-up regardless of whether
  real-time protection is enabled or not. Thus, using multiple
  anti-virus solutions can result in kernel mode conflicts causing
  system instability, catastrophic crashes, slow performance and waste
  vital system resources. When actively running in the background while
  connected to the Internet, each anti-virus may try to update their
  definition databases at the same time. As the programs compete for
  resources required to download the necessary files this often can
  result in sluggish system performance or unresponsive behavior.

  When scanning engines are initiated, each anti-virus may interpret the
  activity of the other as suspicious behavior and there is a greater
  chance of them alerting you to a "false positive". If one finds a
  virus or a suspicious file and then the other also finds the same,
  both programs will be competing over exclusive rights on dealing with
  that threat. Each anti-virus may attempt to remove the offending file
  and quarantine it at the same time resulting in a resource management
  issue as to which program gets permission to act first. If one
  anit-virus finds and quarantines the file before the other one does,
  then you may encounter the problem of both wanting to scan each
  other's zipped or archived and update files and each reporting the
  other's quarantined contents. This can lead to a repetitive cycle of
  endless alerts that continually warn you that a threat has been found
  after it has already been neutralized.

  Anti-virus scanners use virus definitions to check for malware and
  these can include a fragment of the virus code which may be recognized
  by other anti-virus programs as the virus itself. Because of this,
  many anti-virus vendors encrypt their definitions so that they do not
  trigger a false alarm when scanned by other security programs. Other
  vendors do not encrypt their definitions and they can trigger false
  alarms when detected by the resident anti-virus. Further, dual
  installation is not always possible because most of the newer
  anti-virus programs will detect the presence of another and may insist
  that it be removed prior to installation. If the installation does
  complete with another anti-virus already installed, you may encounter
  issues like system freezing, unresponsiveness or similar symptoms as
  described above while trying to use it. In some cases, one of the
  anti-virus programs may even get disabled by the other.

To avoid these problems, use only one anti-virus solution.


How to destroy old credit card? What is the best (in terms of security) way to destroy old (but still working) credit card?

Call the bank and cancel the card. It's the only way to prevent it from being used, since any merchant with whom you've previously used the card, or anyone who otherwise already has the card data (including simply a photograph of the card) could theoretically run it in a card-not-present transaction.

Once you cancel the card, the physical plastic card is relatively useless.

But if you want the most certain way to destroy a card, then the only way that is 100% effective and guaranteed to be absolutely irreversible is burning/melting it.


Will my method for managing account data work? I'm looking at whats nessecary to create a small accounts server for a video game I'm programming in my spare time. User privacy is a very important topic for me, and I don't want to keep anything about my users that isn't really needed to provide the service I'm offering. I don't feel I have the right require that info, and I don't really want the responsibility of protecting that info (Don't get me wrong though I'll still do whatever is nessecary to protect what I do take).

My primary idea for this is to store unsalted email hashes as the account identifiers, the usual salt+hash password, and no other identifying information. I haven't really seen mention of this done previously so I'd like to confirm that the idea is sound. With this system I can still send emails to users for things like password recovery since they will still need to send me their plaintext email to log in.

Is this a good idea? If I retain IP addresses for logging purposes and link IPs to accounts, will a hacker be able to match the IPs elsewhere and work out/guess many emails anyway? Is a large list of user IPs valuable to anyone?

Are there any other methods for minimising identifying and private information while still ensuring that each user can only log into their own account (such as password alternatives)?

Is this a good idea?

Yes and No. I don't think there is any harm of storing hash($email) instead of $email You're gaining privacy over usability since you will not be able to send an email to all users at the same time. Collision will be your biggest problem here. I am assuming you are using a collision-almost-free hashing function to avoid collision (e.g. sha512)

  If I retain IP addresses for logging purposes and link IPs to accounts, will a hacker be able to match the IPs elsewhere and work out/guess many emails anyway? Is a large list of user IPs valuable to anyone?

A hacker who is on-path and doing man-in-the-middle CAN match accounts with IPs by simply sniffing the network packets. He/she can even hijack these accounts if you use constant cookies for sessions.

Think about a situation when you have mutiple accounts coming from the same network (same IP) The IP address of each client will not be different.


Risks of Long-life Session Most "big" websites seem to have enormous sessions. From looking through the cookies, Stack Exchange seems to have a one-week rolling session, GitHub has 45 days, and Gmail seems to have a never-ending session.

What are the security implications for having sessions longer than an a few hours? Apparently, the recommended time for session expiry is just fifteen minutes, but obviously that's pretty bad for user experience. Is there a nice, happy medium for session expiry that smaller webapps can use? How do major websites manage to get away with such long sessions?

Indeed the question is pretty interesting. Either way it boils down to a risk assessment plus controls in place of each system. Roughly, we could imagine 2 undesirable consequences of long-life session:

Somebody can just open browser with your logged account. Controls:

Close all sessions from another device via Account settings if you suspect that your personal device has been stolen.
Lock your personal device. Except that the session is 15 minutes long, there is no big difference between 7-week session and infinite session: somebody can use your computer if you don't lock it, and the session is usually being renewed infinitely until you use device. So you should lock your device and close all sessions from another device if your computer has been stolen.

Somebody can steal your session ID and open it on another device. Controls:

User notification about that via Push Notifications, SMS, e-mail.

About controls in place of mentioned systems, let's look at each case:

Stack Exchange has 1 week rolling session. Controls: you can login with Google or with custom e-mail, you can remove sessions, you can logout.
GitHub has 45 days. Controls: there is a two-factor authentication (2FA), session control, backup e-mails, SSH keys, logout.
Gmail has never-ending session. Controls: suspicious login detection, alerts, 2FA, backup e-mails, everything....

Keep in mind that the difference between 7 days and 45 days session policy is kind of subtle: while session is still active somebody can just open your browser if you forgot to lock your device. Therefore it looks like there is no too much to do about a not locked device, but GMail has pretty huge control about any suspicious activity. Anyways, security engineers select expiration time from their internal security risk assessment which may differ from case to case, it may differ from our perception, there is always a portion of subjectivity.


Is JWT secure to use as session identifier? I was reading this article and it says that there might be some vulnerabilites with JWT.
From the article:

There were two ways to attack a standards-compliant JWS library to achieve trivial token forgery:

Send a header that specifies the "none" algorithm be used
Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key.

But in order to send this headers, wouldn't the attacker need to have access to the secret?

A JWT consists of three parts. The header, the payload and the signature. The header specifies which signature method is used, so it the signature can not be verified before reading the header. Note that this is an implementation error; the header should not be able to change the signature algorithm.

  Send a header that specifies the "none" algorithm be used

In this case there is no signature, so the attacker can modify the message at will.

  Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key.

In this case the attacker needs to know the secret. However, RS256 uses asymetric cryptography, in which the public key is often published. If the attacker succeeds in changing this to HS256, the public key is used as symmetric key instead. So the attacker knows the secret because it is the public key.


What happens when encrypted email is in-transit? If you're using a service that offers end-to-end encryption, what happens when you send an email to another non-encrypted email address? Let's say I write my email in ProtonMail and then send it to a Gmail account, is the email somehow encrypted in-transit?

Unfortunately I don't really know how to word my question any better than this, sorry if it doesn't make much sense. I guess what I'm asking is how secure encrypted email services are when only one party is using it. The way I understand encrypted email is that the connection between you and the server is secure, but as soon as the email departs to the recipient, I don't know what actually happens to all the previous encryption.

It depends on the design of a particular service, but if you send an email outside of a service providing encrypted emails it is subject to the same relaying mechanisms as every other email on the Internet.
This means you don't know and have no control over (and that's reason you want to avoid sending unencrypted emails in the first place).
Regarding ProtonMail it offers two solutions for encrypted communication with recipients outside the service (source Wikipedia, March 2016):

Emails sent from ProtonMail to non-ProtonMail email addresses may be sent with or without encryption. With encryption, the email is encrypted with AES under a user-supplied password and then stored on ProtonMail's servers. The recipient receives a link to the ProtonMail website on which they can enter the password and read the decrypted email.
(...) ProtonMail added native support to their web interface and mobile app for Pretty Good Privacy (PGP). This allows a user to export their ProtonMail PGP-encoded public key to others outside of ProtonMail, enabling them to use the key for email encryption.

In practice a test email (with both encrypted and unencrypted content) from @protonmail.com to @gmail.com email was sent directly between the two parties using encrypted and authenticated protocol ESMTP with STARTTLS:
Received: from mail2.protonmail.ch (mail2.protonmail.ch. [185.70.40.22])
        by mx.google.com with ESMTPS id e3si15787607wjn.27.2016.03.18.05.07.18
        for <________@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 18 Mar 2016 05:07:18 -0700 (PDT)

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of _________@protonmail.com designates 185.70.40.22 as permitted sender) smtp.mailfrom=________@protonmail.com;
       dkim=pass header.i=@protonmail.com;
       dmarc=pass (p=QUARANTINE dis=NONE) header.from=protonmail.com

This post also touches on the subject of encrypted email transmission.


Human vs. Vulnerability Scanners When would a human outperform a scripting tool when testing for vulnerabilities? For example, would a human ever find something that SQLmap wouldn't? In what cases would it be preferable/are there any examples?

For example consider the url:

"fakeurl.com/vuln.php?id=4"

A human could try:

"fakeurl.com/vuln.php?id='"

and see if an error message pops up, but in that time he could just run

sqlmap -u fakeurl.com/vuln.php?id=4 --batch --dump-all

and find everything so much faster.

I know a lot of people like to look down on script kiddies, but for practical, professional purposes it's best to just do things fast and properly. It seems to me that working by hand is less efficient and more prone to errors. Can someone give me a case (technical or a historic example) where a human found something a tool wouldn't have?

Most access control / authorization flaws would never be found by a (generic) tool, because it does not have the understanding of what is supposed to be accessible and what not. (Having said that, experienced pentesters probably know that quite a lot of applications also don't have this documented...) So that is an example of a whole class of problems.

Any logic flaw (for example a user being able to create another user with more privileges by design) would also not be picked up by an automated tool.

Any chain of vulnerabilities would not be correlated, like for instance how to use a low risk info leak, together with a medium risk DOM XSS together with another low risk vulnerability to change a user's password to anything the attacker wants (this is an actual example I have seen).

Testing DOM XSS with a plain (usual) scanner like most of those commercial tools is quite difficult as they don't have a Javascript runtime, so they will miss most of it.

Also for things that are testable, a tool may have several patterns to try, but will probably miss more complex cases. For example what if an application had a blacklist filter for XSS that explicitly blocks alert(1) and all of the attack vectors from the tool had that as the payload? Getting through a blacklist filter is almost always possible, but is very hard for an automated tool.

Or consider DoS. How would an automated tool find that?

For a final example, what about buffer overflow in an uploaded and processed file, say a user uploads an image which gets resized by a server side library, vulnerable to bof. How could the automated tool know that's the case and how would it create an exploit for it?

These are just a bunch of examples, I'm sure others will cite a lot more.

In short,

there are whole classes of vulnerabilities that cannot be tested for in the generic case
even for vulnerabilities that are automatically testable, it is pretty much impossible to write comprehensive tests (a set of tests that finds all instances of the vulnerability).

Of course with all of this in mind, I think there is nothing wrong with using tools to make several things quicker. However, any result from a tool needs to be reproduced by the tester, and also he must be aware of the limitations of the tool to be able to augment results with more creative attacks.


how to mitigate a DDoS from botnet on your website that comes from random IPs I am wondering how do you mitigate a ddos attack which is coming from a botnet and hitting random URLs on a website.

If there was a consistent URL it was hitting then it would be fairly simple, and wouldn't matter that it is coming from random IPs.

How do you prevent an attack which is random IPs and URLs?

The tricky part is to distinguish between requests from the botnet, and requests from humans who actually want to read the pages. There is no 100% reliable way to do that in all generality, because some DDoS tools are quite good at imitating humans, and also because most humans appear to be quite good at behaving like mindless drones. Nevertheless, that's the gist of the issue: you must find a distinguishing characteristic between botnet requests and non-botnet requests (and if you find one, next month's botnet will have adapted -- this is an endless race).

One possible defence is to require a Proof of Work from clients. Embed in your site some Javascript code which performs a relatively complex computation, the output of which being embedded in the next request from that client. If done properly, then you could make sure that the botnet burned at least some substantial amount of CPU in the process; the idea being that if DDoSing your server is too expensive, then the botnet master will direct his wrath to another target. After all, he is a businessman...

I have not seen PoW deployed in a Web context, and the Javascript idiosyncrasies may make it difficult to do (a browser with a Javascript interpretor will not make that much "work" per second), but the concept seems sound.


I don't understand what's wrong with just using cookies for authentication? I'm writing an app-server and there is an option to just use secure cookies for authentication. Here's how it seems to work:

You define a 32-byte secret key on the server
When the user logs in, you check the database to see if the bcrypt hashes match, and if so, you call request.remember(user_id)
On route handlers that require authentication (and the user_id), you unwrap the user_id by decrypting the cookie and if it's valid, you continue. Otherwise, return an Unauthorized error.
If a user hits the logout handler I just call request.forget() and the cookie is deleted on the client.

This all seems to work. So what I'm curious about is why doesn't everyone just do this? I look around and there seems to be a lot of talk of JWTs, generating auth token UUIDs and storing them in Redis/the database, etc. So apparently this method isn't secure? And you need to store state on the server?

If I were to guess, I'd say a problem with this approach might be that if the cookie is stolen somehow (not sure how since it's all over TLS and the cookies are HTTP-Only and Secure if that matters), then the user would be able to be impersonated by an attacker. But I think this would apply to the other schemes too?

Another issue I could see is that a user could just randomly generate auth tokens until they found one that matched a user? But I'm not sure if this is a problem either since I'd just rate limit the authentication handler and I'd imagine this sort of thing would take a while? Oh, maybe they could make 100 accounts and see what the encrypted cookie auth token looked like and bruteforce it client-side to find out what the secret key on the server was? And then they'd be able to impersonate users by generating auth tokens? Although I think it would take way too long to find the key since it's 32 bytes?

I guess this approach doesn't automatically expire cookies (is that why this isn't used much? But I think there's a way to add an expiry header to cookies? Would that work?) I'm not even sure if I need expiration for this app.. Seems like it would annoy users. How long do sessions last at places like Google/Facebook? I feel like I'm always logged into those services forever.

I don't know. I feel like I'm missing a lot of information here. Is there somewhere where I can find a pros and cons list of all these different approaches?

The scheme you describe is potentially vulnerable to cross site request forgery (CSRF).

An malicious request could be made on behalf of the user. This request would send the cookie which would pass the authentication checks, and perform any activity the user could themselves.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

If you look at the link above to the OWASP article on CSRF it specifically lists secret cookies as an invalid mitigation technique.


Are clients blocking all incoming connections secure? When clients (which are using both Linux and Windows) block all incoming traffic in a network, and the router is also blocking all incoming traffic, are we (almost) 100% secure? Maybe excluding silly stuff, like when the user runs something in his PC that he found online, or got through email from an unknown source. Add to it, keeping the PCs updated.

Would this be an effective security policy for a small company?
Could clients within this network attack/hack other clients?

No, actually the users' behavior online is your biggest risk. If it was just running programs downloaded off the Internet or received in email attachments that would be easy, you could educate users or use technical means to prevent the file downloading and the email attachments.

The problem is your users will contract malware just by visiting web sites or just by opening PDF files! And this is much harder to deal with!


alternatives to the "PGP pathfinder" The author of the PGP pathfinder deceased this year. Shortly after the data was not updated any more.

Are there any alternatives known to find signature paths?

The program used to calculate it is public: https://pgp.cs.uu.nl/wotsap/

As is the archive data it uses, updated as of... today https://pgp.cs.uu.nl/archive/wot-0.3/


Javascript - Client side encryption / key storage I realize this is often described as a bad idea. So first of all I'll state motivation - feel free to critique this.

Creating a product for an industry which tends to be overly concerned with security. The product needs to store and return user files but they do not need to be readable server side.

I feel that by encrypting client side would reduce the trust required from clients. Their confidential data would only be touched by JavaScript which they could inspect and monitor. It also mean any security issues server side which would allow access to stored data do not result in client documents being available (exception being if they can modify served JS).

My ideal solution would be -

- Key generated and injected to all clients users by clients IT team.
- JavaScript uses key to encrypt documents client side. These are then sent to the server and stored.
- On retrieval documents are decrypted again client side.

There seem to be several libraries to support client side crypto. But Currently I see no way to persistently store a key for the user. Ideally this would be in a similar fashion to adding certificates to the browsers store - i.e. they can be injected once.

Does anyone have any suggestions?

(To be clear: this only protects users in situations that the attacker only gets read-only access and protects users who haven't used the site since an attacker replaced the javascript with a malicious version. It does not protect users from you being malicious from the start unless the user painstakingly verifies / records all javascript that your site delivers them. If that last part is important to you, there might be a way to use ServiceWorkers to alert users whenever a new version of your site's javascript is executed, etc, but that's for another question.)

You can store encryption keys locally in the client with localStorage or IndexedDB. The encryption keys could be strings that your client javascript uses.

On supporting browsers, for increased security you could use the Web Crypto API (+ IndexedDB) instead. With the Web Crypto API, you can generate keys in javascript and use them for encryption/decryption, but the javascript code can not get access to the raw key material no matter what. That means even if an attacker gets access to your server one day and replaces the javascript with a malicious version, they can not replace it with a version that leaks users' keys. (However, they could replace it with a version that makes clients download their files, decrypt them, and upload them back to the server in the background on the next time they go to the site. This would take time and could be noticeable to users and/or you, so it might give you enough time to patch the issue before all user data is leaked.)


I found an unknown ipv4 address on my router I’m having issues with my sky router and my children’s access to inappropriate sites, I put blocked sites on my router and I’m now seeing an unidentfied ipv4 address trying to access the router for porn - the address is 100.103.216.0
All the other devices linked to my ip addresses are 192.168.0.1- 21
Can someone explain if I have a hacked computer on my system or whether it’s one of my kids mobile devices?
Many thanks

Are you perhaps using carrier-grade NAT (CGN)? That address you specified is part of RFC 6598, a standard that specifies the address range 100.64.0.0/10 (which includes the address you provided). This means that it is not a local private address, but the address provided to you by your ISP. In order to overcome the IPv4 shortage, your ISP assigns you this special address, and then uses NAT to convert it to your real (shared) public IP address. In other words, the address you are seeing is the one between your router and your ISP, not between some device and your router. All this says is that someone is requesting a blocked domain through your router. Most likely culprits? Curious children.


How can encrypted messages from proton mail help data requesters? I am reffering to a part of this news video: Hak5 news video starts at 5:33

I found out that proton mail can only give out encrypted message to requesters(reference):

  ProtonMail can only hand over encrypted messages as we do not have the ability to decrypt user messages.

How can the encrypted message help the FBI or other requesters to plead the attacker guilty?

What you shouldn't forget about encrypted e-mail, is that while the message body is properly encrypted, some meta data like the subject, sender or receiver aren't.

The subject of the emails, together with the metadata to link the sender-person to the receiver person, can be very valuable.

In an example of a terrorist case, someone who has been suspected of planning an attack, who happens to be mailing with a lot of users that have known terrorist group links, can be enough proof to assume that he was at least involved with them.

This could be a pointer that our suspect is actually what we think he is!


In DoS, does every sent Spoofed IP packet have a different IP? so, my question is:

When a DoS attack occurs and the attacker is using spoofed IP packets, do this packets all carry the same spoofed IP or does every packet have a different IP header?

Thanks

That depends on why the attacker is spoofing.

If they are spoofing to make it difficult to seperate their traffic from general internet traffic then it makes sense to spoof as randomly as possible.

If they are spoofing to exploit a hole in a firewall (for example a firewall that accepts all packets from addresses internal to a victim) then they would obviously choose addresses from the range they belive the firewall will allow.

If they are spoofing to perform a "reflected" attack then the spoofed source IP will be the IP of the victim.


Apple Mac Security - What do I need to know? As I've been working on Windows machines most of my life I know most of the best practices and apps to keep them secure.

When it comes to security on Apple macs I'm clueless as to where to start.

I think this webpage is a very good start:

Mac OS X Security Configuration Guides

You can download on it several Configuration Guides and Security Configuration Guide for Mac OS X 10.3 (Panther) to 10.6 (Snow Leopard) (but unfortunately right now, not for the latest version 1.7 (Lion)).


Clicked on fake "Download Now!" ad on file transfer site (legal file for legit purposes) by accident; does anyone know what measures I should take? I was sent a file by a coworker via "sendshare" - my first time using the service. The page loaded a bit slowly and the ads came in before the actual download link. I was in a hurry to get the file - it was a time-sensitive job - and I ended up clicking on the deceptively-designed ad at the top of the page instead of the download button. It took me to a page that looked just like the download page but with no logo and the same fake "download now!" link at the top. My hackles went up and I closed the tab before clicking again.

I went back to the page, realized my mistake, got the real file and completed the work. Afterwards, I opened up the same page in my Linux machine, went to the scammy page, and saved the source in order to examine it. It was a WALL of javascript that I can't make heads nor tails of.

I'd like to include it here so people can look at it and maybe tell me what I need to look for on my system (I'm running Security Essentials as we speak; AVG just finished; MalwareBytes is next on deck) or online to reduce my exposure, but it's so big I don't want to overwhelm people or Stackoverflow's system. I was logged into Gmail at the time, not Facebook, so I don't know if I need to change any passwords (I already use two-step verification on Gmail) or not.

It seems that the Javascript code you shared with us is .... jQuery! :)
That's also a reason for why it is so long.

Well it has been minified, so its just awful to read, but I wasn't understand why a possible exploit was playing with everything : form elements, css, dom, etc. But since it's jQuery, it explains everything. (just search on google with some line of the js and you'll find the jQuery minified source).

Now, I can't garantee that the code you couldn't paste was a real exploit, BUT I don't think so.

The reason is simple: It's for the sake of the business of sendshare to assure that they users will come back and maybe use the paid version of their system. If they send you ads that contain virus, this will be known and won't be good for their business.

Now, we're never too sure, and I was going to tell you to check your machine in case you were infected, but you are already doing it, that's good :)

Moreover, since you know where the ad come from, you can look up the name of the ad company in google and see if other users has reported malicious code in their page. It will help know if you are possibly infected or not.

I'm sure you'll be fine and AVG/MalwareBytes won't find any viruses regarding this experience :)

Update: Just a funny update about the BBC - The Documentary, posting a 3 episodes video about ... "Danger in the Download".


Is it really "Time to add a word" if there are no tools to crack passphrases of 3 words and up? It's "time to add a word" says Arnold Reinhold, the creator of Diceware, in his blog (3/2014). He advices to use 6 word sentences (or 5 words with one extra character chosen and placed at random) from now on. Reasons given include that he predicted the likelihood of a change in 2014 back in 1995, and that "Today criminal gangs probably have access to more computing power then the NSA"

There is evidence and there are hints (Wikipedia (On the other hand ..) and stackexchange (my comment on Goldberg's answer) that there are (slight?) weaknesses in the Diceware word lists (not in the method). Understanding the he evidence in "Improving the Diceware memorable passphrase generation system" is beyond my math capabilities. I do understand though that the average recovery  time of a 4 word sentence can indeed be reduced because ~22 character sentences are the most likely ones. And if the passphrase character count is somehow known, even the exhaustive recovery time may be reduced.

However, Arstechnica mentiones 3/2014 (update) an email received from Gosney in which he would have written "Since there are no tools that currently combine three or more words, we don't really know for sure how much slower it would be compared to his 25 GPU monster cracks."

Are there really no tools and performance measurements available for cracking 3 word or larger Diceware passphrases? I have tried to find measurements and can only find grammar based proof of principle recovery of phrases.

Added in 2 steps after the answers of Thomas Pornin and Arnold Reinhold

Arnold Reinhold acknowledges one word list weakness (Diceware words can run together, “act” and “ion” form "action"). Arnold Reinhold: "I now recommend that users of Diceware put a space character between each word, which completely eliminates this problem."
Yet, what is a new formula for calculating entropy of a passphrase when spaces are not used?

You cannot know what tools exist. Actually, if the attack pattern can be enunciated ("just use three random words from a list of common words") then it can be translated to code in a matter of minutes. That the already-compiled, ready-to-run tool is not accessible from a single Google search and a couple of clicks does not mean that it does not exist, only that the level-zero, pre-schooler attackers may have some trouble trying to crack your password. But would you consider your security goal achieved when you have defeated bored kids ?

Any assertion comparing computing abilities with that of "the NSA" should be dismissed as meaningless. You cannot use as the basis of a measure scale a quantity which is already unknown; it would be like describing your new truck as "longer than Nessie". A sentence like:

  Today criminal gangs probably have access to more computing power then the NSA

really reads like:

  I don't know what "criminal gangs" and "the NSA" can do or not, but I want you to get afraid and be crushed by the weight of your own fantasies at that point.

What matters is entropy: a mathematical, precise notion of what the attacker does not know. You should use a password generating process which allows you to not only achieve high entropy, but also lets you compute that entropy with the least possible assumptions; in particular, you don't want to have to suppose that some tools "are not available to the attacker", because that cannot be readily quantified. As for multi-word passphrases, see this answer for entropy calculations.


Is connecting to an open WiFi router with DHCP in Linux susceptible to Shellshock? Source: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

  For the same reason, userland DHCP clients that invoke configuration scripts and use variables to pass down config details are at risk when exposed to rogue servers (e.g., on open wifi).

Wonder if Linux dhclient is vulnerable to config details passed from the router.

If so, many desktop Linux rigs should be patched ASAP. Also interested in DHCP configuration done in Android.

Yes.

The dhclient-script network-configuration shell script is run during the DHCP process, and a number of parameters from the server (such as domain-name) are passed to it in environment variables.  The script is set to be interpreted by /bin/sh, so if your system has that symlinked to /bin/bash (which is quite common), you're vulnerable.

What's more, on Debian (and possibly many of its myriads of offsprings like Ubuntu), which uses dash as /bin/sh, dhclient-script is explicitely shebanged to /bin/bash, and it does seem to contain a bashism, too.


Why strace isn't showing system call being made in shellcode? I'm new to shellcoding.
I have written assembly code :

section .text
global _start

_start:
 jmp end

start:
  ;open file
  pop ebx ; get address of filename
  xor eax,eax
  mov [ebx+3], al
  mov al,5
  xor ecx,ecx
  mov edx,777
  int 80h
  ;exit

  xor eax,eax
  mov al,1
  mov ebx,1
  int 80h

end:
   call start
   db "AAAA"

However when I check either the "sys_open" system call is being made or not using "strace" tool it doesn't show any system call related to file opening.

What is wrong with my shellcode???

"strace" output:

rakesh@rakesh-VirtualBox:~/shellcode$ strace ./a.out

execve("./a.out", ["./a.out"], [/* 21 vars */]) = 0
brk(0)                                  = 0x6cf000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c53efe000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=62357, ...}) = 0
mmap(NULL, 62357, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7c53eee000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\30\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1815224, ...}) = 0
mmap(NULL, 3929304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7c5391e000
mprotect(0x7f7c53ad3000, 2097152, PROT_NONE) = 0
mmap(0x7f7c53cd3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b5000) = 0x7f7c53cd3000
mmap(0x7f7c53cd9000, 17624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7c53cd9000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c53eed000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c53eec000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7c53eeb000
arch_prctl(ARCH_SET_FS, 0x7f7c53eec700) = 0
mprotect(0x7f7c53cd3000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ)     = 0
mprotect(0x7f7c53f00000, 4096, PROT_READ) = 0
munmap(0x7f7c53eee000, 62357)           = 0
fstat(1, {st_mode=03260764276, st_size=140733642434881, ...}) = 3
write(1, "\242\350\303\32\377\177\0\0\0\0\0\0\0\0\0\0\252\350\303\32\377\177\0\0\276\350\303\32\377\177\0\0"..., 777 <unfinished ... exit status 1>

I'm editing this answer to clean up the confusion about -e open. -e only does filtering and will not add extra info to the strace log. The only case when strace is not logging open syscalls is when a forked subprocess is invoking them and the -f parameter is not set, which is not relevant in your case.


Can I use RSA to encrypt an AES256 key that I put at the beginning of my AES256 encrypted file? I have a master server generating large files for other (known) servers to download.

Those files:

Are quite big. From 20MB to 5GB.
Are written once by the server and then it forgets about them.
Nobody should be able to read the content of the file except the server it has been generated for.
Will be downloaded over HTTPS using a library such as RequestJS

Based on this knowledge, I planned to generate an RSA key pair for each server, store the public key in the database of the master server along with the servers' specific data (like unique identifier) and only keep the private key on the server it belongs to.
I thought I would just have to encrypt the whole 5GB file using the server's public key and only it would be able to decrypt it.

However, after looking around on the internet, I noticed that it's an extremely bad idea to encrypt big things using RSA. It's not meant for this purpose at all.

I also heard a lot about AES and decided to take a look at the way the TLS works and noticed it uses RSA encryption for the symmetric AES keys.
Now, I'm thinking that I should encrypt my files using AES with a randomly generated key per file but I need to transmit the key to the server.

My idea is the following:

Generate a random 256 bits key per generated file.
Use this key to encrypt the whole file.
Use the public key of the target server to encrypt this key.
Prepend the encrypted key to the file so that it's a whole package.
Sign the whole thing with the master private key (but I haven't thought about that yet so I'm open to suggestions regarding the algorithm)

And, on the reception side, the server would just read the first 256 bits, decrypt with its private key and use the decrypted payload as a key to decrypt the file itself.

Since I have no deep knowledge of security, I would like to be sure that it a good idea. I see no real downside but I may not know what I'm talking about enough to judge that.

At first I thought HTTPS would be sufficient but I don't want anyone to be able to get the file so I still need more encryption than the connection itself.
Moreover, I wouldn't want a "slave" server to be able to decrypt the content of another. And I should be able to revoke a server by changing its key pair.

You are reinventing the wheel by trying to solve your problem at a low level. You are trying to combine RSA and AES encryption primitives to create something that will asymmetrically encrypt a file. What you should be doing is looking for a solution that can asymetrically encrypt a file. For example,

NaCl crypto box
GPG


Restrict user login to a specific machine How do you restrict user access to a corporate web site to a particular machine ?

including the following conditions :

Each user is meant to use his credentials ONLY from the assigned machine.
The website is deployed on the internet.
Static IP's are not affordable due to huge number of users.
The corporate web site has confidential information which should not accessible to users outside their designated cubicles.

You would typically install a client certificate on each user's machine and require it for access to the web site.

This of course requires the machine's OS be locked down heavily to ensure that the client certificate cannot easily be moved.

If this is not possible, an alternative would be to use a hardware dongle that is physically attached to the machine in a non-removeable fashion. (And of course you'd have to physically attach the machine to the cubicle.)


access-control-allow-headers: * is being ignored Although the OPTIONS returns * for Allow-Headers I'm getting the following CORS response.

Access to XMLHttpRequest at 'https://example1.com' from origin 'https://example2.net' has been blocked by CORS policy: Request header field x-requested-with is not allowed by Access-Control-Allow-Headers in preflight response.

While the OPTION request looks like this:

Request Method: OPTIONS
Status Code: 204

Request headers:

Access-Control-Request-Headers: x-requested-with
Access-Control-Request-Method: POST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Response headers:

access-control-allow-credentials: true
access-control-allow-headers: *
access-control-allow-methods: GET,POST
access-control-max-age: 86400
content-length: 0
content-type: text/plain charset=UTF-8
date: Wed, 12 Jun 2019 05:03:06 GMT
status: 204

Why do I get this CORS error? and how to avoid it?

The Access-Control-Allow-Headers header does not support wildcards. You can only supply a list of actual headers that are allowed.

If you still want to allow all headers, you can make your web application look at which headers are present in the request and reflect all these in Access-Control-Allow-Headers.


What are the major threats involved in storing the session identifiers in local storage instead of cookies? I want to know the major security threats involved in storing the session variables in client side local storage, instead of storing it in the cookies. Can somebody give me a brief description?

I assume you mean a server-side identifier, like PHPSESSID or ASPSESSIONID.

Client accessibility comes to mind. With cookies, they can be marked as HttpOnly, thus making them unreadable from JavaScript. This mitigates an attacker that exploits XSS from stealing your session cookie because a complying browser will refuse to give the cookie to the malicious script.

Local storage on the other hand, has no such protection that I am aware of. Local storage is never sent to the server by the browser (where cookies are), so it would be useless to have local storage that cannot be read client side.


Why some antiviruses detect viruses and some not? I am curious why some anti-viruses detect viruses and some do not. From what I found online, antiviruses parse the binary files and check the sequence of code which is malicious(exists in virus database).

What is there any difference in how do they treat files?

Also what are virus encoders? Do they have anything with my question.

Thank you

You described one type of anti-virus software: signature based AVs. These anti-viruses look for suspicious sections of binaries that match known viruses. However, each AV has it's own list of "known viruses", so they may catch different viruses. There is no universal list of viruses that each AV can check against.

The other type of anti-virus looks for suspicious behavior in any running programs. Each AV program will look for it's own definition of "suspicious behavior" and so the results of each AV may differ.


Enterprise Network Security - Firewalls for a small environment Good day. I am the IT Manager at work and we are looking to enhance the security of our infrastructure given the sensitive nature of the data we house.

We have a small environment consisting of a few host servers running VMWARE, a dedicated physical backup server, and an enterprise HP SAN, all sitting at a Datacenter.

The consultant we hired as our software developer has been insisting that we need multiple physical firewalls for separation of our environment (proxy accessible to the public, Web app layer, data layer, and development layer (restricted to the other 3 layers)).

I am no network architect but I find it hard to believe that in an era of virtulization we still need physical separation.

As an organization, we need to meet FIPS 140-2 and NIST compliance on our entire architecture and have a small team/budget to make all this happen.

My question is, are 4 physical firewalls needed to provide the security or can this be done virtually in our environment?

One more thing, Cloud services are not an option for us for contractual reasons.

You do indeed need physical separation but in a small network that doesn't necessarily mean 4 separate firewalls. However, if you don't do that, you will be adding to the risk.

It is up to you and your organisation and maybe whatever external auditors you use to agree what level of risk is acceptable.

There are many firewall devices that have more than 2 network interfaces and any decent make will allow you to configure different security settings between different pairs of interface.

For example, even the router I use at home - a Ubuquiti EdgeRouter Lite - has 3 interfaces and a firewall configuration tool that lets me have different settings between either of the two internal and 1 external interfaces.

The risk, however, is that a compromise either of the firewall (at OS or firewall application layers) or a compromise of a user account on the firewall would allow reconfiguration of all interfaces with no further protection.

As you can probably see, a 4 device solution would only actually be much more secure if:

They all use different admin accounts
They are multiple device types - because if they are all the same, they are also likely to have the same software level and therefore the same vulnerabilities.

You can further mitigate the risks of either solution type by ensuring that logs are actively passed through to a SIEM which alerts on any changes and if data stops coming through. That could be as simple as a centralised syslog server - though that requires some expert eyes to be regularly reviewing the logs. Better is a proper SIEM solution that presents a single dashboard for all threats.

The bottom line is that what is key here is not so much the physical architecture but rather the concept of data/system segregation. Also points removed from your consultant if they didn't recommend centralised reporting and audit.


Processor microcode manipulation to change opcodes? I had recently thought of an extreme way of implementing security by obscurity and wanted to ask you guys if it's possible.

Would a person with no access to special processor documentation be able to change the CPU's microcode in order to obfuscate the machine's instruction set?

What else would need to be changed for a machine to boot with such a processor - would BIOS manipulation be enough?

Although modern x86 processors allow for runtime microcode upload, the format is model-specific, undocumented, and controlled by checksums and possibly signatures. Also, the scope of microcode is somewhat limited nowadays, because most instructions are hardwired. See this answer for some details. Modern operating systems upload microcode blocks upon boot, but these blocks are provided by the CPU vendors themselves for bugfixing purposes.

(Note that microcode which is uploaded is kept in an internal dedicated RAM block, which is not Flash or EEPROM; it is lost when power is cut.)

Update: there seems to be some misconceptions and/or terminology confusion about what microcode is and what it can do, so here are some longer explanations.

In the days of the first microprocessors, transistors were expensive: they used a lot of silicon area, which is the scarce resource in chip foundries (the larger a chip is, the higher the failure rate, because each dust particle at the wrong place makes the whole chip inoperative). So the chip designers had to resort to many tricks, one of them being microcode. The architecture of a chip of that era would look like this:

(this image was shamelessly plundered from this site). The CPU is segmented into many individual units linked together through data buses. Let's see what a fictional "add B, C" instruction would entail (addition of the contents of register B and register C, result to be stored back in B):

The register bank must put the contents of the B register on the internal data bus. At the end of the same cycle, the "TEMP" storage unit should read the value from the data bus and store it.
The register bank must put the contents of the C register on the internal data bus. At the end of the same cycle, the "A" storage unit should read the value from the data bus and store it.
The Arithmetic and Logic Unit (ALU) should read its two inputs (which are TEMP and A) and compute an addition. The result will be available on its output at the next cycle on the bus.
The register bank must read the byte on the internal data bus, and store it into the B register.

The whole process would take a whooping four clock cycles. Each unit in the CPU must receive its specific orders in due sequence. The control unit, which dispatches the activation signals to each CPU unit, must "know" all the sequences for all the instruction. This is where microcode intervenes. Microcode is a representation, as bit words, of elementary steps in this process. Each CPU unit would have a few reserved bits in each microcode. For instance, bits 0 to 3 in each word would be for the register bank, encoding the register which is to be operated, and whether the operation is a read or a write; bits 4 to 6 would be for the ALU, telling it which arithmetic or logic operation it must perform.

With microcode, the control logic becomes a rather simple circuit: it consists of a pointer in the microcode (which is a ROM block); at each cycle, the control unit reads the next microcode word, and sends to each CPU unit, on dedicated wires, its microcode bits. The instruction decoder is then a map from opcodes (the "machine code instructions" which the programmer sees, and are stored in RAM) into offsets in the microcode block: the decoder sets the microcode pointer to the first microcode word for the sequence which implements the opcode.

One description of this process is that the CPU really processes microcode; and the microcode implements an emulator for the actual opcodes which the programmer thinks of as "machine code".

ROM is compact: each ROM bit takes about the same size, or even slightly less, than one transistor. This allowed the CPU designers to store a lot of complex distinct behaviours in a small silicon space. Thus, the highly venerable Motorola 68000 CPU, core processor of the Atari ST, Amiga and Sega Megadrive, could fit in about 40000 transistor-equivalent space, about a third of which consisting of microcode; in that tiny area, it could host fifteen 32-bit registers, and implement a whole paraphernalia of addressing modes for which is was famous. The opcodes were reasonably compact (thus saving RAM); microcode words are larger, but invisible from the outside.

All this changed with the advent of the RISC processors. RISC comes from the realization that while microcode allows for opcodes with complex behaviour, it also implies a lot of overhead in instruction decoding. As we saw above, a simple addition would take several clock cycles. On the other hand, programmers of that time (late 1980s) would increasingly shun assembly, preferring the use of compilers. A compiler translates some programming language into a sequence of opcodes. It so happens that compilers use relatively simple opcodes; opcodes with complex behaviour are hard to integrate into the logic of a compiler. So the net result was that microcode implied overhead, thus execution inefficiency, for the sake of complex opcodes which the programmers did not use !

RISC is, simply put, the suppression of the microcode-in-CPU. The opcodes which the programmer (or the compiler) sees are the microcode, or close enough. This means that RISC opcodes are larger (typically 32 bits per opcode, as in the original ARM, Sparc, Mips, Alpha and PowerPC processors) with a more regular encoding. A RISC CPU can then process one instruction per cycle. Of course, instructions do less things than their CISC counterparts ("CISC" is what non-RISC processors do, like the 68000).

Therefore, if you want to program in microcode, use a RISC processor. In a true RISC processor, there is no microcode stricto sensu; there are opcodes which are translated with a 1-to-1 correspondence into the activation bits for all the CPU units. This gives the compiler more options to optimize code, while saving space in the CPU. The first ARM used only 30000 transistors, less than the 68000, while providing substantially more computing power for the same clock frequency. The price to pay was larger code, but RAM was increasingly cheaper at that time (that's when computer RAM size began to be counted in megabytes instead of mere kilobytes).

Then things changed again by becoming more confused. RISC did not kill off the CISC processors. It turned out that backward compatibility is an extremely strong force in the computing industry. This is why modern x86 processors (like Intel i7 or even newer) are still able to run code designed for the 8086 of the late 1970s. So x86 processors have to implement opcodes with complex behaviours. The result is that modern processors have an instruction decoder which segregates opcodes into two categories:

The usual, simple opcodes which compilers use are executed RISC-like, "hardwired" into fixed behaviours. Additions, multiplications, memory accesses, control flow opcodes... are all handled that way.
The unusual, complex opcodes kept around for compatibility are interpreted with microcode, which is limited to a subset of the units in the CPU so as not to interfere and induce latency in the processing of the simple opcodes. An example of a microcoded instruction in a modern x86 is fsin, which computes the sine function on a floating-point operand.

Since transistors have shrunk a lot (a quad-core i7 from 2008 uses 731 millions of transistors), it became quite tolerable to replace the ROM block for microcode with a RAM block. That RAM block is still internal to the CPU, inaccessible from user code, but it can be updated. After all, microcode is a kind of software, so it has bugs. CPU vendors publish updates for the microcode of their CPU. Such an update can be uploaded by the operating system using some specific opcodes (this requires kernel-level privileges). Since we are talking about RAM, this is not permanent, and must be performed again after each boot.

The contents of these microcode updates are not documented at all; they are very specific to the CPU exact model, and there is no standard. Moreover, there are checksums which are believed to be MAC or possibly even digital signatures: vendors want to keep a tight control of what enters the microcode area. It is conceivable that maliciously crafted microcode could damage the CPU by triggering "short circuits" within the CPU.

Summary: microcode is not as awesome as what it is often cracked up to be. Right now, microcode hacking is a closed area; CPU vendors reserve it for themselves. But even if you could write your own microcode, you would probably be disappointed: in modern CPU, microcode impacts only peripheral units of the CPU.

As for the initial question, an "obscure opcode behaviour" implemented in microcode would not be practically different from a custom virtual machine emulator, like what @Christian links to. It would be "security through obscurity" at its finest, i.e. not very fine. Such things are vulnerable to reverse engineering.

If the fabled microcode could implement a complete decryption engine with a tamper resistant storage area for keys, then you could have a really robust anti-reverse-engineering solution. But microcode cannot do that. This requires some more hardware. The Cell CPU can do that; it has been used in the Sony PS3 (Sony botched it in other areas, though -- the CPU is not alone in the system and cannot ensure total security by itself).


Firmware Backdoor Protection http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Security_Risk

  Ubuntu Linux founder Mark Shuttleworth has likened ACPI to Trojan
  horses.[28] He has described proprietary firmware (firmware ACPI or
  any other firmware) as a security risk, saying that "firmware on your
  device is the NSA's best friend" and calling firmware (ACPI or
  non-ACPI) a Trojan horse of monumental proportions". He has pointed
  out that low quality, closed source firmware is a major threat to
  system security:[7] "Your biggest mistake is to assume that the NSA is
  the only institution abusing this position of trust — in fact, it's
  reasonable to assume that all firmware is a cesspool of insecurity,
  courtesy of incompetence of the highest degree from manufacturers, and
  competence of the highest degree from a very wide range of such
  agencies".

  As a solution to this problem, he has called for declarative firmware
  (ACPI or non-ACPI).[7] Firmware should be open-source so that the code
  can be checked and verified. Firmware should be declarative, meaning
  that it should describe "hardware linkage and dependencies" and should
  not include executable code.

Is there anyway to properly protect yourself from backdoors in the ACPI or in general?

Can firmware be infected or injected with backdoors or trojans very easily?

Firmware is code. It executes on the CPU on behalf of some hardware device; or it executes on the device directly.

In general, if your own hardware is intent on spying on you, then you lose. A more worrying development is that many pieces of hardware (e.g. keyboards) contain a completely honest firmware that is upgradeable, and some malware has been spotted in the wild which replaces some firmwares (using the "upgradeable" feature) with malicious code.

The biggest firmware of all is called the BIOS; it is the code which runs first when the computer boots up, before the operating system is loaded (and, indeed, the BIOS is responsible for loading the OS). Malware installed in the BIOS itself resists, by definition, complete reformat-and-reinstall of the operating system. The CIH virus, better known as "Chernobyl virus", was already muddling with the BIOS back in 1998 (but it was doing so rather inexpertly, resulting in a mangled BIOS, not a stealthily infected BIOS). More recent virus will install in a non-destructive way, and persist.

The BIOS is not the only piece of reflashable firmware in a computer, so the possibilities are large.

To write a firmware-installable virus, you need to do some reverse-engineering on the hardware and firmware format. It seems that attackers do that. Open-source firmwares would technically make such reverse-engineering easier, but would also help the "defenders" who look for security vulnerabilities that they can fix. It is the classical Open-source / closed-source security debate which has been ongoing for quite some time and has not reached any sort of definitive conclusion yet.

The call for "declarative-only firmware" is a bit misguided, though. The idea is that no piece of hardware should come with specific code to be executed on the CPU; instead, such code should be in the operating system driver. This fails to take into account the whole situation, in two main ways:

A machine must be able to boot up in order to actually load the OS and the drivers, so there must still be some firmware somewhere (namely, the BIOS) who knows how to access the hard disk.
Many peripheral devices have their own CPU. This includes of course GPU, but all network interfaces, keyboards... and, for them, it makes no real sense to call for a "declarative-only firmware" since the code is meant for the device CPU anyway, not for the main CPU, and the OS never sees it. A keylogger inserted into the firmware for an Apple keyboard has been demonstrated.

Generic workarounds:

Work only with hardware from "trustworthy sources" with strict internal security procedures (in particular background checks on employees) so that chances are that the firmware is initially clean and honest.
Make it so that firmware is not reflashable. There again, this depends on the hardware. For instance, for some motherboards, the BIOS cannot be reflashed unless a specific jumper is physically set; otherwise, the needed reflashing current simply cannot reach the chip.

Since a lot of existing hardware with reflashable firmware cannot be made non-reflashable, and "trustworthy sources" are a rarity from the point of view of any nation (because parts come from different countries), it follows that these generic workarounds are not actually practical.

(Maybe China could come up with a "100% Chinese computer" but having all parts produced on your national territory is not the same as being able to trust in their honesty and reliability.)


JS snippets on my live project do not appear in my code residing on my production server I have a Django website project that is live (let's call it example.com). It's a forum where users can submit comments and reply to them. It has a Postgresql database, and gunicorn + nginx reverse proxy as the web server set up. I'm hosted on an Azure-powered virtual machine, with the Debian-based Ubuntu 14.04 lts as the OS. Lastly, note that the web application and the server sit on two separate virtual machine instances.

I suspect my servers might be compromised - I'm at the data-gathering stage where I'm ascertaining whether (i) indeed my servers are compromised (ii) whether my data is compromised too (iii) how did the compromise happen, so that I don't get hacked again.

In Django applications, there's a base.html file that all other .html files inherit (or extend in Django). This base.html file contains the <head> tag with required meta tags etcetra, so one doesn't have to replicate it in every template file.

My base.html file has some javascript code in it that I did not write. In fact, I don't use javascript in my code at all. This malicious javascript snippet redirects my users to adverts (it's a money making hack). If I log into my web application's production server and nano to the base.html file (i.e. open it in a text editor), the offending snippets of javascript do not appear there.

Secondly, when I inspect element on my live website (browser: Firefox), I see an ev button next to the collapsed  tag of my website:

This is apparently an events button to debug JS in Mozilla's code inspector. If I press it, I see:

I'm unsure what's :37 (port 37?). Moreover, if I press the pause (debug) button in front of click, I am taken to one of the JS snippets residing in my base.html code:

My confusion is regarding how can these JS snippets be part of my live website when the files in my production server appear to be without them?

I'm guessing finding the source of the hack would require going deeper into this. I haven't installed SSL yet, but I suspect my problem can't be helped by that. This is a two-person project - and the other person is a non-techie, cultural anthropology major specializing in South Asian studies, so I'm sure she has nothing to do with it.

I have set rules.v4 for iptables to:

*filter
# Allow all outgoing, but drop incoming and forwarding packets by default
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Custom per-protocol chains
:UDP - [0:0]
:TCP - [0:0]
:ICMP - [0:0]

# Acceptable UDP traffic

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT
-A TCP -p tcp --dport 80 -j ACCEPT

# Acceptable ICMP traffic

# Boilerplate acceptance policy
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Pass traffic to protocol-specific chains
## Only allow new connections (established and related should already be handled)
## For TCP, additionally only allow new SYN packets since that is the only valid
## method for establishing a new TCP connection
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

# Reject anything that's fallen through to this point
## Try to be protocol-specific w/ rejection message
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

# Commit the changes
COMMIT

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
1COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

The code you have pulled out of their page is New Relic Browser monitoring. This is Javascript which lets the website track the performance of pages for their live sites and for the customers using it.

It provides performance data back for how long the page took to load, where in the world you are from and time each element loading to show where any degraded performance may be.

You can find out more information about this product at
http://newrelic.com/browser-monitoring


When and why to send an email notification of password reset The Devise documentation states that "For security purposes, sometimes you need to notify users when their passwords change." In general, when would you need to provide such notification, and why?

At most websites I use, especially for my 401(k), I get an e-mail every time I change my password changes.  Given that it is something that affects my financial future, I appreciate that so I know right away if the password were to change and I didn't initiate that.

In respond to your question, it depends.  For a website that just wants people to log in for some reason (such as a pizza place that doesn't store my credit card info or address), it may not be a big deal to notify people of a password change.  For anything with privacy or security issues, such as medical, financial, IT security, anything to do with minor children, or other such systems, I'd say that notification of all password changes, immediately, would be mandatory.  For code repositories, I'd want to know if someone is logging in as me so I can prevent theft of my company's or my personal intellectual property. For that I'd send a notification of a password reset so the user could ensure that code being uploaded/downloaded by them is being done from the appropriate repository.


Norton detects intrusion attempt from virtual machine - how is this possible? Sometimes I have to fix an infected WordPress website. I always check the infected website from a virtual machine (Oracle VM VirtualBox). I'm also running Norton 360 DeluXe on the host machine.
In the 2 most recent projects, for both, I received a notice from Norton that 'an intrusion attempt was detected and blocked', on the HOST machine. So apparently the malware can 'breakout' a VM? (Despite having read this article, that it should be totally isolated.)
As how can Norton otherwise detect this as the page was opened in the VM?
Also Norton says: No action required, is that really true? Could the host be infected with stuff Norton did not detect?

It does not feel safe anymore to use a VM to visit infected website. Should i be worried? Did i do anything wrong? What are the alternatives?

You are assuming that the intrusion is coming from the VM to the hypervisor. A VM "breakout" is when the VM accesses the host directly.
An infected VM that has access to the network can attack the host's network. That's not a "breakout".
But the alert in your image is indicating that it saw traffic to a domain on a watchlist. That's not an intrusion or an attack on the host. Norton is inspecting traffic from the machine, which includes traffic from all VMs, and flagged the suspicous traffic. This is not a surprise, since you stated that the site was infected.
There is nothing in the info you provided to support your claim that there was an intrusion from the VM to the host...


Linux wireless hacking book I am looking for recommendations on a good wireless hacking book. I would like something more focused towards the defensive, but a healthy knowledge of both would be great. I would also need it to go in depth on using wireless tools such as iwlist, iwconfig and maybe some simple scripting of these tools.

Any suggestions?

Hacking Exposed Wireless, 2nd Edition
Seven Deadliest Wireless Technologies Attacks
Unauthorised Access: Physical Penetration Testing For IT Security Teams
Modern Cryptanalysis: Techniques for Advanced Code Breaking

The best I ever saw on defense was in the Linux Networking Cookbook, Recipe 4.7. Making WPA2-Personal Almost As Good As WPA-Enterprise.


Is NTLM (over HTTPS) on IIS a good idea for a Internet-facing website I am writing here since I have a huge doubt. I am performing a technical security assessment on a custom developed web application (ASP.NET).

The application:

is Internet-facing
Uses HTTPS
Uses IIS with NTLM authentication with NTLMSSP message protocol
Lack of HSTS
ASP.NET framework is not updated (v.4.0.xxx) - this will be a
separate observation

My assessment is risk-based and I have read several publicly available resources related to NTLM over HTTPS, however, I cannot come up with a clear idea if I should suggest changing the authentication or not.

I learned:

NTLM over HTTPS is better than basic or digest, since NTLM does not transmit credentials over the network, but transmits encrypted challenge/responses messages:
Microsoft is kind of trying to move clients towards Kerberos. Is this true and does this apply for Internet-facing web apps?
NTLM was affected by multiple vulnerabilities in the past, even recently: CVE-2019-1040, CVE-2019-1019. Per my understanding, SMB relay attack scenario should be applicable, however, It the likelihood seems low (attackers should be in a privileged position in the network and have another server to relay the attack). However, the protocol comes with concerns: https://www.preempt.com/blog/the-security-risks-of-ntlm-proceed-with-caution/
NTLM does not support MFA
NTLM protocol is old

My conundrum is:

"should I point out this auth protocol as non-secure?" (meaning,
should i say to the system owner to change the auth protocol?)
If I do, "what are the alternatives or risk remediations?"

Secure HTTPS
Using HTTPS is great though a secure protocol and cipher must be used. There are a number of vulnerability scanners that will test this. Here are two examples:

Qualys SSL Server Test
Nmap ssl-enum-ciphers

NTLMv2 is Fine
You didn't specify whether NTLMv1 or NTLMv2 was being used. If the former (NTLMv1), this would definitely be a finding and cause for concern. There's no reason for that protocol to be in use nowadays especially on a public facing application. NTLMv2 is perfectly fine and some may consider it more secure than alternatives since it works on a challenge/response where the actual password isn't even sent to the server. As an example, Microsoft SharePoint and Exchange can have publicly facing components using NTLM authentication.
Difficulty with Windows Authentication
No Kerberos
NTLM authentication is the default authentication method when the application is configured to use Windows Authentication. This is because Kerberos requires extra configuration steps and the client needs access to the Kerberos infrastructure (i.e. Domain Controller). This would be fine if the web application is only accessed from the LAN or via a VPN. However a public facing web application doesn't make this a feasible option.
Lacking Session Management
Windows Authentication lacks control over session management. Take for example an app using Forms Authentication, the session cookie can be expired after a specified time or extended on each request. This isn't the case with an application using Windows Authentication. Failure to properly terminate a session would definitely be a finding.
No Branded Login Page
The Windows Authentication login box is the generic window provided by the browser. Many prefer to provide the user a "Branded" login page as it allows the user to be more aware of what application they're about to log into. Checking the URL bar to ensure the location is accurate and certificate is valid (e.g. colored green). This leverages end-user education on phishing prevention and good security awareness. Depending on your environment, this could be a finding.
No Brute Force Protection
Generally there are two methods to protect a website against brute force login attempts: MFA and captcha. Be default, a web application using Windows Authentication doesn't support MFA. You may find an provider that leverages a module to achieve this but I'm guessing you're not using one of those providers. Regarding captcha, there is no way to implement that. This requires one to monitor the web application for brute force login attempts.
To address this, I wrote a PowerShell module WebsiteFailedLogins. From the README:

This PowerShell module was created to identify the following scenarios affecting IIS hosted websites.

Brute Force Login Attempts - excessive failed logins from a single IP address and often targeting a single account.
Password Spraying Attempts - excessive failed logins from a single IP address using a single password across multiple user accounts.
Distributed Login Attempts - either of the above techniques being sourced from multiple IP addresses.

It leverages Microsoft Logparser and a configuration file to parse the target website's IIS logs. When a threshold is met or exceeded an alert is generated via standard out, email, and/or written to a Windows Event Log. No changes are needed on the webserver. This module can even run on a separate system where there's access to the IIS logs.

Older Framework
This isn't necessarily a finding. Run Windows Update, or whatever product you use to manage Security Updates, on the server running IIS. If there are missing updates then it will obviously be a finding. Check CVE's for any addressing the web application CLR. Chances are, if there are no missing security updates there will not be an open CVE.
Check Supporting Components
If you're concerned about an older framework, this leads me to believe the application itself is dated. Look into supporting components like jquery to ensure they're not using an insecure version. This may reveal a finding.
Alternative - Forms Authentication
With HTTPS configured to use a secure protocol and cipher, the best alternative is Forms Authentication. While the login credentials are transmitted in clear text; secure HTTPS mitigates this. It also achieves:

Better Session Management
A Branded Logon Page
MFA or Captcha Integration

This approach will require a retooling of the web application. Two caveats to be aware of include:

The web application must use a secure method of authenticating credentials on the backend. Whether its Kerberos or LDAPS, just be sure the credentials are not shared in an insecure manner on the backend.
Access must be tested to ensure resources are not accessible via insecure methods. For example, by default MVC applications would use a static handler to improve performance when serving .js and .css files thus bypassing the authentication requirement. In some instances these resources should be accessible to authenticated users only.

Alternative - SSO
The best method to address these authentication issues is to implement a Single Sign-On (SSO) provider. It will still require the web application to be retooled for the new authentication method. However, long term this is the best approach as it centralizes authentication for the enterprise.


Root access without password I know it's strongly advised against enabling root access on server but as cracking SSH keys is almost impossible can I enable root access just by using ssh keys and be safe?

My OS is Ubuntu 16.04.

I guess universe has its own jokes but the funniest and saddest thing happens to me the day after I asked this question and my laptop's mainboard broke and now I'm glad I had another user apart from root which doesn't accept password and only connects via SSH keys.

can I enable root access just by using ssh keys and be safe

This depends on how well you protect the private key belonging to the authorized public key.
I see no problem that somebody might brute-force the server directly to get access as root. But somebody might hack your client system, steal the private key and then use it to get root access to the server.


Metasploit SSH Error: could not settle on kex algorithm I am running a trial of Cobalt Strike which runs over the Metasploit Framework. I am trying to perform an SSH related attack on my laptop, and I get the error in the title for all SSH related attacks. If I try to login via ssh (not an attack) using Metasploit I get an error for the username and pass I know is correct; this might be related to the error in the title. Any ideas on how to fix this?

After changing sshd_conf the following error occurs:

Metasploit uses an SSH implementation written in Ruby which only supports the algorithms listed below.

https://github.com/rapid7/metasploit-framework/blob/b3c7fff32a62739241a223515574674b4a6b483c/lib/net/ssh/transport/algorithms.rb#L31

ALGORITHMS = {
  :host_key    => %w(ssh-rsa ssh-dss),
  :kex         => %w(diffie-hellman-group-exchange-sha1
                     diffie-hellman-group1-sha1),
  :encryption  => %w(aes128-cbc 3des-cbc blowfish-cbc cast128-cbc
                     aes192-cbc aes256-cbc rijndael-cbc@lysator.liu.se
                     idea-cbc none arcfour128 arcfour256),
  :hmac        => %w(hmac-sha1 hmac-md5 hmac-sha1-96 hmac-md5-96 none),
  :compression => %w(none zlib@openssh.com zlib),
  :language    => %w()
}

The server needs to provide a match in each category to create a secure connection.  Unfortunately, the Metasploit Ruby algorithms are considered weak by contemporary cryptographic standards, and newer OpenSSH server configurations disable them by default.

Metasploit would require additional Ruby code to implement newer algorithms.  The server, however, can enable additional algorithms in the sshd_config.  Modify /etc/ssh/sshd_config to specify compatible algorithms:

# Metasploit Client
KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256cbc,arcfour128,arcfour256
# Unsupported Ciphers from Metasploit: rijndael-cbc@lysator.liu.se,idea-cbc,none
MACs hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96
# Unsupported MACs from Metasploit: none

This will totally replace the server's algorithms with weaker ones.  A better solution would be to add the algorithms, or some subset, to the defaults.  Unfortunately, the configuration options require complete specification, so it is OpenSSH version dependant.  Defaults can be found in man sshd_config and then specified with the above options as additions.

For Fedora 22, it would be something like:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1


Sniff HTTP(S) from PPTP VPN server I've setup an PPTP VPN server on my Debian 7 server. I'm using this VPN in combination with my Android phone to ensure a secure connection.

However, i'm getting curious of what my phone is sending and receiving, especially from Google. Is there a way to setup an HTTP(S) sniffer in my VPN server. I have some basic knowledge about sniffing (wireshark etc). I'm really curious what options are available to sniff http/https traffic thats flowing through my VPN?

You can use "burp" as a proxy which would enable you to see all http packets that you are receiving and sending.

It is pretty simple to use and works with pretty much everything. You can even edit/drop/resend packages.


Sending data from Android client to database I have created an Android app which sends data to a web service. Right now the user sends his test results (test id, test name, test time, and user ID). The problem is that I send the data from the client to the web service in JSON; the web service can be accessed in the browser. However, an unauthorized user could use his browser to call the webservice method for inserting the score. How can I solve this problem? I need to let only the Android client send the data to the webservice.

In general, this can't be done.  If the user has access to the app, they can reverse-engineer it and undetectably emulate everything it does.

What you can do is put obstacles in their path.  Simply transmitting a salted hash alongside the data will stop 99% of would-be attackers; if you're willing to go to greater effort, using public-key cryptography to encrypt and sign the message being transmitted will stop almost everyone.

This won't stop or even significantly slow a professional attacker, but if your primary threat model is "college student majoring in art history" or "casual Facebook user", it's more than adequate.


Does adding a recovery phone number to a Gmail account make it less secure, in the case that I lose both my laptop and phone? Background
I have a "main" Gmail account, which I set to keep logged in, on my laptop. This "main" Gmail account is important, because it's the email address I used to sign up for many other services (and, so, if I forget my password on these other services, I get the password reset link sent to this Gmail account).
I have a phone. I do not keep myself logged into my main Gmail account on my phone. I rarely log into my main Gmail account on my phone; but whenever I do, I only stay logged on for a few minutes, and then I log back out.
I have a secondary Gmail account, which I list as a recovery email address for my "main" Gmail account. My secondary Gmail account's password is written in a safe physical place (not in my wallet or backpack). I rarely log into this secondary account. (This secondary email has my phone number as a recovery phone number, but as I explain below, I'm thinking that this might be unsafe?).
Is it better to not use a recovery phone number?
My main concern is to keep my "main" Gmail account secure, even if I lose my laptop and my phone at the same time. (I tend to keep both in my backpack, instead of keeping my phone in my pocket).
Is it a bad idea add to my phone number as a recovery phone number to my "main" Gmail account?
That is, I'm thinking it would be a bad idea, because if I lost my backpack, then anyone who found my backpack could gain permanent access to my Gmail account in a way that I could not prevent:

even if I act quickly and use a different device (ie, one that I didn't lose) to force my main account to log off of the stolen laptop, the person who found my backpack would still see that my main Gmail account is used on this laptop (ie because when they open up google, they see google accounts "added" to the Chrome browser as account options for logging in). Then, they could use my phone to "recover" my main Gmail account.

and then, even if I use my secondary Gmail account as a recovery option for my main Gmail account, I'm thinking that the attacker owning my phone to "recover" my main Gmail account would trump me using my secondary Gmail account to recover my main Gmail account.

However, I'm thinking that it's harder for an attacker if I have no recovery phone number on my main Gmail account. Then, in order to get access to my main account, the attacker would first need to get access to my secondary account using my phone.
And finally, I'm thinking that if I have no recovery phone number on either account, then my main account is safe from an attacker, even if they have both my phone and my laptop.
Question
What is the best plan for me to protect my main Gmail account, even if I lose both my laptop and my phone?

Is the best plan to not have a recovery phone number on either my main or secondary Gmail account? (ie, is it true that if I choose this option, then an attacker could not get permanent access to my main Gmail account, even if they owned my lost laptop and lost phone?) What are the drawbacks of this plan? What other plans might I consider?

Laptop
If you use proper password on your laptop, then guessing it can take millions of years. The more realistic scenario would be to shut your laptop down, extract disk, read it in some other system. If your file system is not encrypted, then the attacker may read cookies and try to restore your session. If your laptop was stolen by some occasional people, not by some prepared attacker, it may take several days, until somebody get access to the data on your disk. You will have a lot of time to reset password.
Phone
If it is not some special agency, the chances to unlock your phone for occasional people are very low. You will have a lot of time to reset password.
When phone is needed?
Now suppose somebody has noticed the password you have typed, e.g. by recording you on smartphone during login. If they want to use your password, Google will see that IP or device has changed and will request confirmation and can send a request to your smartphone. You will just tell Google it was not you and the attacker will not be allowed to log in, or if logged it, will be logged out. Where as without phone the attacker would get normal access to your account.
TLDR
Your assumptions about compromising your account via stolen laptop ad phone are not quite correct. The problems without having any phone attached to the account can be more serious than in case of having it attached. That's why I would suggest to attach a phone to the account.


Password Storage with Jasypt StrongPasswordEncryptor vs PBKDF2 We are currently working on authentication for a web application. For password storage, we're using Jasypt StrongPasswordEncryptor with SHA-256 and tens of thousands of iterations. Going into the project, I had hoped to implement PBKDF2-HMAC-SHA512 (I do not believe I could get traction on a switch to bcrypt or scrypt).

The Jasypt StrongPasswordEncryptor simply re-hashes the passed however many times specified using SHA-256 (or other algorithm chosen), instead of the HMAC iterations in PBKDF2. I understand that the security benefit of PBKDF2 is its slow speed, while SHA is fast. However, since PBKDF2 is simply reiterating HMAC-SHA (or some other function), it's hard to show an improvement over the current method.

If the security improvement from the change is minimal, it is unlikely to be done. If there is a substantial security improvement, it's still early enough in the project to be made.

What is it about HMAC-SHA that makes it better/slower than a normal SHA?

What sort of information can I bring to a change request - how much of an improvement would there be?

Is the change necessary?

Jasypt's StrongPasswordEncryptor is a special case of Jasypt's StandardStringDigester that, despite its name, is not standard at all. From the description, it appears to be some custom construction, which thus has the same problem than any other non-standard construction: it has not been reviewed. We don't know how to design secure functions, and the best we can do is to put functions under the collective scrutiny of (many) cryptographers for some time (years). A non-standard function did not benefit from even that, so we really don't know if it is good or not.

Not following peer-reviewed standards is, in my opinion, a serious security defect. Switching to PBKDF2 would thus be a significant improvement. (But I predict that people who indulge in custom functions will think otherwise.)

Of course, bcrypt is better.


How does encryption, certificates in an end to end SSO flow? So, I know how public-private key encryption works. I understand how/why certificates are required. I understand how a SSO flow (IdP initiated) works. But, I do not understand how the three of them happen together. I am confused about what "signing" a SAML assertion means. I'm confused about "encrypted certificates". I just can't seem to tie it all together - can someone help me understand this better?

The IdP will sign either the SAML response of the SAML assertion using its private key. The SP verifies the signature using the IdP's public key.
It's also possible to encrypt the SAML assertion in which case the IdP encrypts the assertion using the SP's public key and the SP decrypts the assertion using its private key.
So, an IdP-initiated SSO flow might see the IdP signing the SAML assertion using its private key followed by encrypting the signed assertion using the SP's public key. The encrypted assertion is bundled into a SAML response and sent to the SP. The SP decrypts the SAML assertion using its private key and verifies the signature using the IdP's public key.