Correct way of signing and verifying a message

Unless you've left out an important element, tour approach seems to have a major flaw: you're checking the validity of the payload using the public key included with the same message.

Anyone could therefore forge a valid packet simply by generating a new key pair, signing the payload and the attaching the public key to the packet. That is why your first step should always to evaluate the validity of the public key.

This is usually done by placing the public key in a signed certificate describing the claim of identity of the originator and having that certificate signed by an authority trusted by the recipient.

As for your other questions:

  Without going through a CA, how can I generate a PKI which I myself, can verify that I, and nobody else, has created that PKI?

Assuming you're simply misusing the acronym "PKI" to mean "public/private key pair" then you can't: you absolutely need to have a way to validate the public key in order to validate the message sender. Otherwise, as I described, anyone could create a packet.

That validation is what a CA is for: it allows the end user to tell that a given public key is owned by a specific security principal.

Another way of validating such a key is to use a key server: a system that hold the information linking a public key with a security principal. This could be used if you want to create a semi-anonymous transport system: if you do not want the recipient to be able to know who sent a specific payload but want it to be able to make sure it has the proper authorization and, at the same time, ensure that the central server cannot see the content of each payload. It doesn't looks like you're implementing that kind of system, though.

  From what I have read, it is common practice to transmit the public key when signing and verifying data. Is this correct?

You need to provide the public key to the end user, yes. But common practice depends on what you're doing exactly. In most cases, you'll not only have the public key but also some form of digital certificate allowing the end user to validate the key itself (if you don not have another mechanism in place to validate that public key). In the case of TLS, the common practice is to transmit ALL certificates in the trust chain (up to the root) to the client so they can check the full chain even if they are missing an intermediate certificate.

  Is there something wrong with the approach of creating a PKI for every message, since I am always transmitting the public key?

Not as such but creating a key pair is a delicate and resource-intensive operation. Unless absolutely necessary, it isn't typically implemented that way.


How to protect conditional 'if' in Android from reverse enginneering

TL;DR: there seems no definite way to prevent it. The following thoughts may, often as a combination of anti-reverse-engeneer-measures -  slow down an attack to a level that makes attacking to labourous, but do not specifically address (only) the conditional "if" (I am not aware of such) but hardening in general.
Concepts have been proposed such as "Hardened Anti-Reverse Engineering System" (HARES), with the software code only being decrypted by the processor at the last possible moment before execution (A. Greenberg, Wired 2015). This does not specificall address an "if" statement, but one may not be able anymore to find also the "if"-statement. I havn't followed up on HARES, and more recent discussions include hardening for mobile banking apps (M. Rupp on cryptomathic.com) and a more general discussion on softwareengineering.stackexchange.com.


unifi AP how to issolate the guest network

First of all let you know that applying restrictions to your guests will let them still 'see' other hosts because these restrictions don't block ICMP protocol, but still they can't even ping other hosts neither access.

If you want to isolate completely your guest network I would recommend you VLANs. You can easily set them up if you have a Unifi Security Gateway.

Set up a new network with a complete different pool of IPs and subnet (10.0.1.0/24 for example) and mark it as VLAN '123' for example.

Now in Wireless Network settings you can edit your guest network and in the advanced settings select 'Use VLAN with VLAN ID' and put in again '123'.

From now on your guests should been put in VLAN '123' with an IP in range 10.0.1.1-10.0.1.254 and will be completely isolated from the main network.

Hope I helped you or gave you at least some ideas!


What should I look for when auditing a Firefox extension / plugin?

IMPORTANT: This is in noway a full list of the things you should look for, use this answer as an example, a first step in your path and research on your own. I've had a similar task long time ago. I had to security-wise review the code of a Firefox addon, I'm sure you'll easily find Chrome/other browsers' equivalents. Also have in mind the Extensions in Chrome run in a Sandbox.

1. Anything that interacts with local files:

Whenever the FileUtils.File object is created and any of its methods is called

Check if the local file access is a documented behavior. What are files being accessed? Why? Are they released successfully?
Check if any local files are being modified. Is that a documented behavior? What are the modified files? Why?

2. Anything that interacts with Windows Registry:

Whenever an instance of nsIWindowsRegKey is created or any of its methods is called

Is Windows Registry access a documented behavior? What keys are accessed? Why?
Is Windows Registry modification a documented behavior? Is the modification temporarily? What keys are modified? Why?

3. Anything that interacts with the cookies

Whenever nsICookieService is used

Is accessing cookies a documented behavior? Why?
To which domain do these cookies belong? Why?

4.Any commands executed in the user's shell

Whenever nsIProcess is created and any of its methods called (closely watch .run() and .launch())

Is executing commands a documented behavior? Why?
What commands are being executed? Where is the output redirected?

5. Any window/tab being accessed

Whenever window is accessed and/or any getElement* method is called (closely watch createElement calls that inject <script> elements.

Is accessing a web page's DOM a documented behavior? Why?
What are the elements added/removed/modified? Why?


While OpenPGP in the current revision is defined by RFC 4880, there are two additional RFCs providing extensions:

RFC 5581 defines the Camellia Cipher in OpenPGP
RFC 6637 defines elliptic curve cryptography in OpenPGP

Furthermore, a draft for EdDSA signatures is already proposed. GnuPG 2.1 already implements this draft.


From this support thread on the LastPass website:

  LastPass says they never receive my Master Password. Don’t I send it to the LastPass servers when I log in?

  No, when you login to LastPass, two things are generated from your Master Password using our code discussed previously before anything is sent to the server: the password hash and the decryption key. This is all done locally.

  The password hash is sent to our servers to verify you. Once verified, we send back your encrypted Vault. We are only sent your hash, not your Master Password.
  The decryption key, which NEVER leaves your computer, is then used to decrypt your Vault once it comes back.

So to answer your questions:

  How does LastPass know that my password is correct?

LastPass only has access to your vault in an encrypted form; they can't read it without knowing the key.  When logging in, your client only sends the hash of your password, and LastPass simply compares it to the password hash they possess.

  How does LastPass decrypt my passwords on a new device?

The decryption key is a function of your password.  As a result, the same input (your password) will always produce the same output (hash + the decryption key).  That's all your new device needs to know in order to decrypt your vault.

  Is it really secure?

The answer to this depends on how much you trust LastPass.

If it works exactly the way they say it does, then a sufficiently strong password should be relatively secure.

If at any point they obtain access to your password (whether it be intentional or accidental), you should probably consider it to be compromised, and should not only change your LastPass password, but the password for every account you have in your vault.

  What if I forget my Master Password?

If you forget your password, you lose access to your vault.  LastPass can't send it to you or reset it..

For users who are willing to trade away some of their LastPass security in exchange for a "safety net", LastPass allows you to produce and use One-Time-Passwords, and you can even enable Emergency Access to provide access to your account from specified users.

LastPass Help Desk - One Time Passwords

  One Time Passwords

  If you are using an untrusted public computer and need to access your LastPass data but are hesitant to do so because of potential keyloggers, LastPass provides One Time Passwords (OTPs) as one option for securely accessing your account.

  While using a trusted computer, go to https://lastpass.com/otp.php to create a list of random passwords that can be used only once to log into LastPass. You must be logged into the plugin to manage your OTPs. From this page, you will be given the option to Add a New One Time password, Clear All OTPs, or Print your OTPs.

  Each time you generate a new OTP, it will be added to your list. These passwords can be printed or carried with you on a portable storage device. You can then revisit the above page to login using this password and you can be certain that, even if captured, the password will not allow access into your account in subsequent attempts because it expires after you login with it once.

  You can even use OTPs with another form of multi-factor authentication (Yubikey, Google Authenticator, Sesame or GRID), to be even more secure when you are not using a trusted computer.

LastPass Help Desk - Emergency Access

  Emergency Access

  Do you worry about your family, friends, partner, or spouse having access to important accounts should something happen to you? Do you want an easy way to give them the passwords and logins they’d need to manage accounts on your behalf? Prepare for the unexpected and ensure your loved ones don’t get locked out of important accounts, like paying bills or the mortgage, and that they can manage your digital legacy.

  With the Emergency Access feature, you can give trusted family and friends access to your LastPass account in the event of an emergency or crisis. Your designated Emergency Access contact(s) can request access to your account and securely receive the passwords and notes without knowing your Master Password. You decide how much time should pass before they’re given access once they request it, and you can decline access if it’s requested unnecessarily.

  Emergency Access can also be used as an alternative account recovery feature, if you worry about ever forgetting your master password and want to ensure you have a backup way of recovering your vault.

  Please note: the person you share access with will need their own LastPass account as well.


How to exploit DOM XSS in cookies without having XSS on the page?

Yes, unless you can set cookies of you choice, it's not really exploitable.

  Are there generic ways to set the cookie without having XSS on the page already?

Yes! There are basically 3 ways we can set cookies in a browser;
1. Via Set-Cookie response header
2. Via HTML <meta> tag
3. Via JavaScript document.cookie

So, what you need is either of;
- HTTP Header Injection
- HTML Injection
- XSS

Since you only need cookies, also try looking for vulnerable subdomains for aforementioned vulnerabilities. There was a bug in Firefox which also allowed setting cookies from SVG images with <img src>, please refer to;
http://insert-script.blogspot.com/2016/12/firefox-svg-cross-domain-cookie.html

And, just to be complete, you can also use network level hacks like MITM, DNS Hijacking, and so on.


Circumventing Netflow's visibility on SSL traffic

While a C&C client would hide its real target by not using SNI it would be suspicious especially because it does not use SNI with HTTPS while everybody else does. It might be better then to claim that it connects to some innocent target by setting the SNI extension accordingly but in reality connecting to the C&C server. This only needs some fiddling in the TLS stack and is not much harder for an experienced attacker to do.

But since the certificate of the server is sent by the server in clear with a  full TLS handshake one can still check if the certificate returned by the server matches the name given in SNI and is also issued by a trusted CA. To bypass this the C&C client might try to simulate a resumed connection everytime. To do this way more fiddling with the TLS stack is needed so it might be simpler to use a protocol which looks enough like TLS to fool the detection but is not real TLS. I think this is what Skype has at least done in the past to bypass firewalls and maybe it still does this today.

Another approach would be to use domain fronting, i.e. (mis)use a system which is serving multiple domains on the same IP address, serves the certificate based on the SNI extension in the TLS handshake but serves the actual content based on the Host header which is encrypted within TLS and thus not accessible when doing passive inspection. In this case it looks like the client connects to some innocent site while in reality it connects to its C&C master.

If the attacker controls relevant parts of the server (for example because it was hijacked) it could also (continue to) serve a mostly innocent site and then use only specific path on it for the C&C communication. Since the path of the URL  is not visible when doing passive inspection of HTTPS it probably looks like the client is just accessing innocent data on this site.

Still, SNI is not the only thing which can detected with passive analysis. The handshake of the client also shows which kind of ciphers it supports and the preference and a variety of TLS extensions and their order. Also significant pattern of the traffic like size of request and response  or timing are still visible even if the traffic is encrypted.  This can also often be used to fingerprint the client and thus distinguish typical browser from other clients and maybe known C&C clients. Cisco has done interesting research in this area.


You have not found a bug in OpenSSL, not a real one. You may have found a gap in your understanding, though.

Namely, encryption works on bytes and produces bytes. What you see with your eyes are characters. In order to accommodate character-oriented devices (e.g. your eyes), OpenSSL applies an extra encoding on the encryption output: it takes the bytes and turns them into characters, using Base64.

Base64 turns every group of three bytes into a sequence of four characters. The characters are taken from letters (uppercase and lowercase), digits, '+' and '/'. However, the input length might not be a multiple of 3; in your case, the AES output is 16 bytes. The first 15 bytes (5 groups of 3) are Base64-encoded into 20 characters (5 sequences of 4 characters). The remaining lone byte is encoded again as 4 characters, but with a special rule: the last two characters will be '=' signs.

Now, when you modify the second '=' and replace it with a '-', then you are turning your string into something which is not valid Base64; yet OpenSSL will still try to recover from it and decode bytes out of it. In fact, the way OpenSSL works is the following: it first removes all characters that are not part of the 64 "normal" Base64 characters (letters, digits, '+' and '/'). It then proceeds from what remains (here, 22 characters). If you replace a '=' with a '-', then you are just replacing a character that OpenSSL removes, with another character that OpenSSL removes as well; therefore, things keep on working. However, if you replace a '=' with a '+', then OpenSSL will keep that '+' and end up with 23 characters, which, upon decoding, will yield 17 bytes, not 16. AES won't like an input whose length is not a multiple of 16.

All of this is about encoding: transforming bytes into characters, and back. Encryption is not relevant here.


How to test security of an encryption algorithm?

Yes, it is called writing research papers and getting them peer reviewed.

There is no reason you should ever write your own encryption algorithm unless you are in the field of academic research, and then you will still not "use" your algorithm for at least 4 years (that's how long it took to choose SHA-3 between the time when the algorithm was submitted to when it it was selected as the official standard) while other people look at it.

You will make mistakes that you will not even know are mistakes (do you know what a timing attack is? does your algorithm protect against it?). If someone with resources ever wanted to attack your algorithm do you think something you came up with could stand up to a team of PhD Crypto Analysts looking at it with a fine tooth comb for a week, a month, a year?

Use a existing library, please don't make your own.


Public WiFi is still insecure, and it will always be if not used together with something like a VPN.

Many websites use HTTPS, but not nearly all. In fact, more than 30 percent don't.
Only around 5 percent of websites use HSTS. And it's still trust on first use. If the max age is short, that first use can be quite often. Let's face it, even if you are  a security pro chances are that you would fall for SSL strip anyway. I know I would.
Just because you use HTTPS doesn't mean you do it right. There's still lot of mixed content out there. Many clients still support old versions with known vulnerabilitites, so an attack doesn't have to be a zero day to be successful.
Even if you use HTTPS, you leak a lot of of information anyway, such as the domain you visit, all your DNS traffic, etc.
A computer or phone uses the internet for more than just browsing:

All it takes is one app that has bad (or no) crypto for its update function and you are owned.
All those apps you gave permission to access all sorts of personal data... They are phoning home constantly and you probably have no idea what data they are sending and what if any crypto they use.
Dancrumb has more examples in his great answer.

Defense in depth.

A VPN is cheap and it is still a low hanging fruit when it comes to security.


Can work IT see the contents of my personal Google Drive?

There are a lot of things wrong here from an InfoSec standpoint.

Why are different employees sharing the same workstation login and consequently browser cookies etc?
Why were you using such an insecure computer to log on to your Google account?
Why did your coworker not notice they were in somebody else's private files and log out immediately?
Why is your coworker assuming you were looking at NSFW images and reporting you for it?
Unless the content was beyond work-inappropriate and legally questionable, or such usage is clearly against the acceptable use policy (AUP), I don't believe it is ethical for your employer to comment on your personal files.. that said, different jurisdictions have different opinions on this.

As for "can they see what's in my drive?"  There may be hints in the browser history, cached thumbnails, images or content.  Metadata would contain the most recent date and time of the access.

If they were skilled, they might see that Google drive was not used when you were on the machine, but it was used when your coworker and IT was using the machine.

Various enterprise security products can look deeper, but given you're sharing a login, I would be highly surprised if they had anything which could look deeper or record the content of what was seen in your drive.  (e.g., Interception proxy or Network recorder)

Despite the lack of these enterprise tools, there's no guarantees of what has been read or changed: an insecure computer with multiple users had authenticated and unsupervised access to your Google account.  What was downloaded, copied or looked at is anyone's guess.  An enterprise account might have an audit log, but I don't believe any such thing exists for personal accounts.


First of all, your actual risks determined the need for confidentiality, integrity, and authentication. The risks can be deletion of rows, insertion of rows, altering cells, or the rollback of the whole database.. I'll not address these.
You seem only need an authenticated encryption (AE) and not interested in the bundle AES-GCM that provides confidentiality, integrity, and authentication. For the CBC mode of operation, you need HMAC to achieve this. Now your obligations for the CBC mode of operation;

choose a uniform random 256-bit key and keep it secret all the time.
for each field choose a 128-bit initialization vector (IV) that should be unique and unpredictable
The IV can be stored in a column or prepended to the data.
the unpredictable requirement of the CBC mode is not a problem in your case.
the padding oracle attacks are also not possible in this scenario.
the CBC-HMAC must be used as Encrypt-then-MAC

AES-CBC guarantees CPA security. With the AES-CBC-HMAC you will get authenticated encryption.

So, will CBC solve my purpose. I have written this code?

It is not advisable to use the same key for encryption and HMAC, or in short for two different purposes. You can use a Key Derivation function to derive keys for AES and HMAC from the given key HKDF, PBKDF2.


Often times compromised passwords are the most direct route.  If someone's e-mail account or online storage get compromised, then anything in them is up for grabs.  This is the purported way that many leaks occur.  There are lots of others ways that it could happen, but those are probably the most common after "intentionally leaked for publicity".


Compromised submarine cables and the consequences to internet?

https:// is not unbreakable

The conditions required to break HTTPS cannot be achieved by passively observing traffic over an undersea cable.

There's several effective attacks against SSL/TLS but pretty much all of them require the attacker to actively interfere with the transmission. To perform a MITM attack against actual encrypted traffic the attacker would also need access to a CA certificate (which many governments do), although there are other (more noticeable) attacks such as SSL stripping.

Even then, if certificates are pinned to particular trusted signing CA (as is the case in some mobile apps and I believe also Chrome when accessing Google services) then they won't be able to perform a MITM attack even with a compromised CA.

The NSA was successful in tapping Google's fibre network because they weren't using encryption within their own network between data centres.

TLDR; HTTPS keeps you safe from passive mass surveillance. Active attacks might still work but there will almost certainly be some evidence of this happening if you look hard enough.

  the vpn ip and know that know i'm connecting to an vpn and be able to
  correlate my traffic when it leaves the vpn and much more?

An IP is not typically considered private information. Without knowing your IP your ISP won't be able to route traffic from the VPN to you and therefore they will unavoidably know that you're communicating with a host that might turn out to be a VPN gateway.

Having said that, who you're communicating with after the VPN and what you're actually communicating is a secret from your ISP and this is usually the information people are trying to protect when they use a VPN.

There are solutions to this (such as TOR) where your IP is known, but it is not known if that traffic actually came from you or was just forwarded by you.

TLDR; An IP is not typically secret information, but a VPN will still protect what you're communicating and with whom.


Protect database resources from fake data inputs via web forms

To authenticate users, you use authentication mechanisms.... The answer to your question, as stated, is to provide logins.

If you want to prevent authenticated users from filling your database with erroneous data, then you need correlation mechanisms. Make sure the data entered conforms with what is expected and what can be correlated with existing entries. Just like financial applications need to correlate transactions with other transactions, to ensure that new data cannot be 'invented'. Alternatively, the user data can be validated after it has been entered by a human, or a heuristic algorithm to determine expected ranges of values.

If correlation is not possible, then you cannot trust the data in the database. This is fine when the only people depending on the data are the users entering the data, but if you require other users to depend on the data, then you need accountability mechanisms. Be able to push back on the users to ensure that they conform to requirements.


x509: must the signature algorithm and public key algorithm match?

The signature in the certificate is computed by the CA, and must match the public key of the CA. There is no problem with having a certificate which contains a DSA key while being signed by a CA which uses a RSA key.

There is a big problem, though, with trying to encrypt some data with a DSA key. DSA is only for digital signatures.


Signing/certifying keys as a YubiKey user

I think it's first of all important to understand that in GnuPG "subkeys" are just sets of fully independent keys that have capabilities assigned to them: a signing key is artificially limited to be only be able to do signing operations. The certification key is just as much of a subkey as the signing key -- there's really nothing that makes it extra special. We only call it the "master" key by convention, and it is often confusing to people (e.g. in the physical world a "master" key is able to unlock all locks, so many users expect their GnuPG "master" key to be able to decrypt messages encrypted to the "E" subkey). The certification (C) key is just another key that can indicate relationship between your identities and other keys belonging to you. Understanding that lets you better understand why the answer to the following question is "you do it already, with your 'C' subkey":

  Is it possible to certify keys with a subkey?

So, can you put your "C" subkey onto the smartcard? Yes, I believe 2.1+ versions of GnuPG make it fairly easy to put your C key into the "S" slot of the smartcard. With some extra tweaking, you can even have your keys on multiple smartcards, though you may run into corner cases with weird behaviour.

Having a dedicated off-the-network system for certifying keys is common practice, though few people go through the trouble of setting it up. All the mechanisms you mention are fine for that purpose, and I'll let you pick the one that suits you best.


Assuming I own the client. Is it acceptable to embed my authorization servers login page in an iframe?

You simply develop the client, you don't own it. As soon as someone installs it on their devices, you don't own it anymore.

Anybody can then analyze the client code, find the authorization server, and access the URL from outside, by hand. Content Security Policy is an agreement between browsers, so if I run the request by hand using curl, for example, CSP will not save you.

Ask your employer why the redirect is not allowed and what he suggests. Embedding the authorization server in the client is asking for someone to decompile it, find the authorization process, and create a "keygen" in a couple hours.


Receiving lots of spam after registering a new domain on GoDaddy

Anybody can see new domain registrations, at least in mainstream extensions like .com/.net/.org. This is public information and you could even compile this data for yourself using zone files.
You can even apply for zone access straight from the registries. Example: Verisign TLD Zone File Access Program. Note that the rules vary from one extension to another. For instance most country code extensions (eg. .ca .fr etc) will not release their zone files or severely restrict access, but some however do publish lists of new or deleted domains on their websites.

The modus operandis of spammers is this:

they obtain the list of new domains on a daily basis (from zone files, public lists, or otherwise)
they scrape the whois record for each new domain
they start spamming

There are plenty of legitimate reasons why people (including myself) use zone files, for example for research purposes, trademark enforcement or if you are running a search engine and need to discover new contents etc.
Of course the downside is that registrants are left open to spamming and unwanted exposure of their acquisitions (many people probably do not realize data mining is going on and the data is going to be archived somewhere). You can now expect to receive dozens of spam in the next few days for SEO services or web development services from India or USA (allegedly).

TL;DR: The registrar is not to blame here. Your experience is very typical and unfortunately normal.
It is a good idea to use a dedicated E-mail address for the whois record and possibly list a virtual phone number and a P.O. box in case somebody needs to contact you. As per Icann rules, you must maintain accurate and truthful whois data but you can avoid exposing yourself whilst remaining reachable.
I would not recommend using third party whois privacy service for reasons that are too many to explain and beyond the scope of your question.


Is it possible for a virus to be embedded in a image and can this image execute on Android Oreo by just opening the image?

I am aware that on Windows this is very much possible. But is it possible on Android [...] Can you install a virus/malware/spyware by just clicking on an image?

Yes, it is possible, although difficult. There is no fundamental difference between Windows and Android in terms of image decoder vulnerabilities. In fact, chances are that both systems are using the same library for decoding, with identical vulnerabilities. The precise mitigations (DEP, ASLR, stack canaries, etc) applied by the operating systems are similar as well.

The only way this can be done is if there is a severe security bug in the image library. A security bug may be able to hijack the library and trigger arbitrary code execution. In these cases, the malicious image is not actually an executable itself, but rather contains a slightly modified format that is not so different that it causes an error, yet is similar enough that it is processed by the library, triggering unintended behavior. These kinds of bugs are pretty rare, and they are fixed rapidly when they are discovered. You should keep your software up to date (preferably with automatic/unattended updates) in order to avoid having a vulnerable image library for long.

  Also what exactly happens when someone renames a malicious apk to .jpg or .png or .mp4. Will the malware/spyware execute if you open the image/video?

If someone renames a malicious executable file so it has an image extension or otherwise find a way to pass it to the media decoder (e.g. changing the MIME type), you will simply get a message that the image cannot be displayed. The decoder will not automatically recognize the file and execute it if it is not an image. Decoders work by first checking for so-called magic bytes at the beginning of the file which specify the type of file. The bytes for an APK and for a JPEG file, for example, are completely different. If it does not see the JPEG bytes it will simply refuse to even try to parse the file.


You could definitely hijack the session by getting cookies, if you can execute the Javascript in that page/frame by sending the message.

Refer : How to send cross domain post request via javascript

The minimal requirement here is, you'll need a server which you control. So that you can configure the Access-Control-Allow-Origin header of the response generated for your AJAX Request.


I could decipher the characters using ASCII code, I got the following result:

[BEL] K [LF] [LF] [LF] [FF] NULL ceuQ \n CI <&NG [SI] [BEL] [BS] [ESC] ( [SO] & " \n E [FS] #' [DC2] [DC4] K [DC1]

[BEL], [LF], [FF], [SI], [BS], [ESC], [SO], [FS], [DC2], [DC4], [DC1] are control characters, then it isn't a encrypted text, it's text in hexadecimal. I think that sqlmap inject control characters to know if it is possible to execute specific actions, for example, [BEL] is a device control code to execute a warning.

You can know more about control characters in the following link.

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

I hope this information helps you.


IPSec is a good solution in terms of security for tunneling traffic between sites, on the other hand you can choose other alternatives based on VPNs depending on your requirements. My suggestions is to read a bit more about it and check what is the best solution for you.


Does WhatsApp disclose the sender's IP address?

WhatsApp uses a client/server architecture based on Jabber (XMPP).

For the recipient(s) to see your IP addresses, the application will have to include your IP address in the metadata of the message. But this has no functional role in the design of such an application.

Your packet capture will likely show IP addresses belonging to WhatsApp(or Facebook) and maybe a CDN company like Akamai that stores media.


bot detection via browser fingerprinting

I've seen similar services which work as a proxy and encode all your webpages in some really obfuscated Javascript, so that a real browser would have no problems browsing that site while it would be really hard, if not impossible (what if the JS was random and different with each request) for a conventional scraper to do the same.

The problem is that it's really easy to defeat all these approaches just by running a real browser and not wasting your time creating a scraper.

Take a look at Selenium WebDriver, which allows you to attach to a real browser and control it programmatically - none of these solutions will detect it since it appears as a clean Firefox (or Chrome, or any of the supported browsers) installation to the outside world.

Rather than wasting your time trying to block the bots, ask yourself why do you want to block them - if they're overloading your web server, implement IP-based rate limits, if they're spamming implement some captchas, otherwise let them be, they aren't doing any harm to you.


A scammer placed a remote file on a Wordpress website?

Sounds like he has a PHP backdoor as you suspected. There is very little you can do to be sure that you have completely removed all traces of the attacker's presence. He might have multiple backdoors, he might have scripts that email him new FTP passwords, he might even have a Windows rootkit installed. The only real solution is to reformat the machine and revert to a backup.

However, if we are working on the assumption that you do not have a backup, and that your attacker is lazy and is just relying on a PHP backdoor, then you would want to grep your entire docroot for things like;

system exec passthru shell_exec proc_open popen fopen fwrite

Of course, your attacker might be using a backdoor written in something other than PHP, which is yet another reason this whole process is fairly meaningless. Nevertheless, you might just be able to kick him out.


Referring, to this answer I would take this to mean that the browser could cache the response, therefore it is good practice to set the headers to inform the browser that it should not.

As that is a an old post, note that we should now be looking at this section of rfc 7234 rather than the obsolete 2616. Many modern browsers now interpret no-cache as no-store as equivalent, although for the small price of setting the correct header I would explicitly set no-store.


Is the most (theoretically-) secure OS/distro something minimalistic like Gentoo or something security-focused like Qubes?

... mainstream software like Firefox, Thunderbird and Libreoffice,

This is actually highly complex software, so bugs are likely.

...  and update/upgrade every day

Updating every day assumes that issues are fixed immediately after somebody has known about. In practice the attacker might actually know about a vulnerability before anybody else and thus can exploit it before anybody fixed it, i.e. a zero-day attack.
Of course updating is important but it does not prevent all attacks.

... something minimalistic like Gentoo or something security-focused like Qubes?

Qubes cares about more and stronger separation on the same computer.
If you just use plain Gentoo you likely run Firefox, Thunderbird and Libreoffice under the same account and all of these have access to your sensitive data. Proper use of Qubes instead means that you have stronger separation inside the computer, at least as long as you don't run the internet exposed Firefox in the same VM as a Libreoffice working with sensitive data. This way even a zero-day attack is restricted to the internet facing VM and has no access to the sensitive data in the other VM.
While you could achieve something similar with different user accounts on Gentoo the separation is less strict, (different user accounts provides less separation than different virtual machines) and maybe less comfortable to use too.
Of course, if you just run everything in the same VM then Qubes does not offer that much in additional security, but this is not how you are supposed to use it.


Human brains are poor RNG. People are bad at generating random values in the privacy of their heads. They just cannot think randomly; though they can convince themselves that they do.

Physical process, on the other hand, are rather good sources of entropy. Take your mouse movements. A few dozen times per second, the mouse measures how far it has moved since the last tick, and sends that information to the server. When your hand shakes, it tends to do so somewhat regularly, but biology is such that each elementary move will be subject to some jitter, which happens to be substantially bigger than the precision of the mouse; even with a lot of training, it is very hard for a human hand to do the exact same move repeatedly (otherwise there would be a lot more people like Yehudi Menuhin). So the bottom line is that mouse movement measures contain some entropy. (Remember that "entropy" is here defined as "that which the attacker does not know"; the mouse certainly knows how much it has moved, since it is that mouse that actually sends the values on which the RNG are built.)

The other half of the answer is aggregation. A mouse-based RNG will use hundreds or even thousands of measures, accumulate them all and condensate them into an appropriate seed that will concentrate all that entropy. This is simple enough: simply feed all the values to a cryptographic hash function, e.g. SHA-256, and you will get a 256-bit seed that has all the source entropy, wherever it was hiding in the measured mouse movements. Hash functions are good for that; they reduce the size but keep the entropy (up to the hash function output size, but 256 bits is more than enough for all purposes).

An attacker may guess that the user will do circles, but will have a hard time getting all the individual movements right, especially since psychology won't help him: the human user himself has no idea how his hand movements are turned into numbers. Since we are talking about hundreds of numbers, the number of possible combinations (i.e. "entropy") raises exponentially. Contrast that with a human user thinking about a new password: the user will choose letters following some inner "witty" train of thought, that the attacker can guess more or less brutally (e.g. if the letters are all the first letters of some words in a sentence from a book, the attacker can automatically try all sentences from all books he can find in electronic format); and, more importantly, the human user won't be bothered to produce more than a dozen or so of "seemingly random" characters.

In passwords, length does not make strength -- but lack of length can be quite effective at preventing strength.


Why does Tor use a new route every few minutes

Tor is best known for providing anonymity to the users communication. Every time tor uses different routes to forward the data to destination to maintain anonymity. If it is not doing so then same path can be traced to intercept the communication. I think this is the best method to anonymize the communication.


How do you estimate the costs of a security breach?

As a security professional, it is often best to 'outsource' this calculation to the business. For example, if you identify a vulnerability which you can demonstrate is easy for an unskilled attacker to exploit to destroy the customer database, and the operations team estimate bringing it back from backups will take 4 hours, including checks, ask the business owner what that will mean to them in terms of cost or impact.

The business should have a view on indirect costs created by customers avoiding the company, and an advertisement complain to restore confidence.

Once they have told you the cost, your side - helping to define protection - is much easier, as @growse said.

The equation usually does not work on a one-to-one though. You'd think if cost of breach is higher than cost to fix then carry out work to fix, but more commonly we see it being more like if cost of breach is more than 10x cost to fix then remediate.


Is an encrypted .dmg file decrypted on the dropbox server?

Yes, as long as you are mounting using diskutil and not decrypting to the current working directory.

This is because the decryption is happening on the fly based on the data in the image when a encrypted image is mounted.

Please note that modifying any data in the mounted, encrypted dmg will re-encrypt the dmg to contain the changes such that Dropbox will think it has changed. This might lead to a lot of re-uploading, since ~/Dropbox is usually watched for changes and any changes instantly uploaded by the Dropbox app.

Please also note that for Dropbox, this is just a big ball of data that changes - as the dmg is chunked into 8 MiBiBytes chunks, a small change thus may lead to 8 MiBiBytes reuploading. Which is basically a good thing, security-wise, but might be unexpected and/or undesired in terms of bandwidth use.

I am unsure as to how Dropbox identifies what has to be uploaded with dmg files. Using diff may work but seems unlikely as there would have to be a shadow copy of every file for diffing - and dmgs might get big :)


Is it possible to do exploit-free Linux keylogging with non-root client-only X Windows access?

Yes, it is possible to do keystroke logging with just an X11 connection. The two common ways to do this are to use the XTEST extension, or to use XQueryKeymap(), which returns the current state of the keyboard. As an X11 connection just goes over a socket, if a process has access to the X11 cookie and can authenticate itself with Xorg, it will be able to monitor (and inject) keystrokes.

Using a nested X server would protect from this (though I would recommend Xephyr rather than Xnest, as the latter is deprecated). You would have to give the sandboxed process access to the nested server's X11 cookie, and prevent it from accessing the root X11 cookie.


How do I sanitize LDAP input and prevent injection attacks?  What LDAP injection scenarios are possible?

In worst case an attacker can run query of his choice in LDAP directory. Results may differ but definitely you don't want attacker to do this.

If you are using .NET framework, you could use AntiXSS library. I know that LDAP injection is not XSS, nevertheless XSS is also a form of injection and correct way to prevent this kind of vulnerabilities is to validate input date and encode it correctly before passing it to an interpreter (browser, SQL server, LDAP server). AntiXSS library offers functions intended to encode potentially dangerous data before passing it to LDAP (LdapDistinguishedNameEncode, LdapFilterEncode). You can also take a look into OWASP ESAPI project, especially into DefaultEncoder.encodeForLDAP function.


Good resources for learning cryptography and OpenSSL?

You probably don't want to be working at the level of selecting from among several encryption algorithms, digital signature primitives, etc.  That's too low-level, and it requires too much crypto knowledge to get everything right.

Instead, you want to be selecting from full protocols that other have vetted: e.g., TLS, OpenPGP, OpenID, OAuth, etc.  There the authors of the protocols have already done the work of figuring out how to piece together the encryption/signing algorithms into a full protocol, and those protocols have been carefully vetted by knowledgeable cryptographers.  Therefore, if you can possibly use some existing vetted scheme like this, you will be much better off (and much less likely to have subtle flaws in your crypto).

If I had to recommend one book for the practicing programmer, I would recommend Cryptography Engineering: Design Principles and Practical Applications by Ferguson, SChneier, and Kohno.  It is fantastic.  But it also describes design of cryptographic schemes at a rather lower level than you probably want to be working, if at all possible.


Trying to cut the code review up into multiple pieces suffers from two problems. The first is the infamous and ever present problem of enumerating badness, and the second is the overhead of recruiting and managing the remote freelancers.

Going for an open ended review will avoid the issues of splitting it up, but you will need to take care ensuring that the freelancers don't just stop at the low hanging fruit because they feel that they have written as much as you paid for. Any remote outsourcing needs to be very carefully specified - being very specific about how you want the review reported will manage the risk of freelancers stopping early. Developing this specification interactively with the freelancer - maybe even starting with a complete blank slate - will provide a great opportunity to assess the scope and depth of their knowledge better than a quiz would allow.

Deliberately seeding the code for review with problems is also a possible approach to assessing reviewers, but you get the feedback too late in the process to be of use unless you're looking for reviewers to use on a repeat basis.

While getting multiple reviews will probably be worth your money it may not be worth the increased process overhead. The trade-off will vary between organisations - if technical staff are doing all the recruitment and management their time is likely better spent on code and internal review, if project management time is plentifully available the overhead may be acceptable.


In general, you can't.
IP addresses are assigned to organizations, not regions.  Those organizations may in turn assign address blocks to specific regions, but some don't.  The steps for figuring out what IP address your target might have would go something like this:

Figure out which ISPs operate in the area
Figure out which IP address ranges have been assigned to each of those ISPs.
For each address, do a lookup in your geolocation database to see if it's in the city of interest.

Note that because you're doing many lookups, the uncertainty inherent in geolocation is magnified.  Additionally, your target may be using an ISP that doesn't do geographic assignment (eg. satellite internet), or may be using an ISP not on your list.


Do heuristics exist for modeling the "harmlessness" of a file?

Likely heuristics are:

File is a valid file of a known type (eg. a JPEG that falls within a strict reading of the JPEG spec).
File does not contain any extraneous data (eg. JPEG permits unformatted data after the image.  A safe file would not have any.)
File does not contain any known exploits for the format.

Other possible heuristics:

File does not use unusual features of the format (eg. a JPEG that uses unusual application-specific markers would be considered suspicious).
File does not appear to embed data of a different type (eg. a JPEG with something that looks like HTML in the comment field could be an attack on the Internet Explorer type-sniffing mechanism, though this is prone to false positives).

For learning more about this, I'd recommend reading up on the specs on a few file formats, and looking for exploits involving those formats.


Using Nokia feature phones with new SHA256 Certificates

Basically, you can't both support older devices, and have the improved security of hashes signed using the more modern algorithm.

The push to eliminate SHA-1 has been extensive, and, by the usual standards of these things, remarkably quick. This isn't a bad thing - there are well documented problems with SHA-1 signed certificates, and while these are not currently viable for most attackers, the technology is improving all the time, and it is better to have completely deprecated SHA-1 signatures before the technology reaches the dangerous point.

There is very little that can be done to handle the lack of support for older root certificates. These are designed to expire after a while, and although the expiration has been brought forward, the plan was always to eventually stop using them.

Similarly, you can't backport a certificate signature. You can, obviously, sign the same certificate with two methods, although you can only use one of them for a given web server safely (unlike ciphers, SSL doesn't negotiate signature methods).

If you could find a provider willing to sign a certificate using the SHA-1 algorithm, with the older root certificate, you could direct feature phone users to a distinct version of the site using this, while other users get a version signed with the newer algorithm. In order to do this, you would need to have your landing page either running over HTTP, or signed with the older certificate, then redirect from there. If you sign it with the newer certificate, the older devices won't be able to access it, so will never reach the redirection.

This does present a security risk, but this might be considered acceptable, and the difficultly of finding a willing and able CA remains.

The other option would be to perform a similar operation, but self-sign the certificate for these devices. This doesn't solve the root certificate issue, but may allow for an encrypted connection, if users can manually accept the certificate (I don't know whether this is always possible on feature phones - been a while since I tried). This provides confidentiality without implicit trust provided by a CA, but you get to control the signature and other features of the certificate.


Can someone find out what phone was used to send an email

You can get the IP address by looking at the RAW email. gmail has this option when you are in the mail you want to check, go into the little down arrow that says more and choose "show original" the IP information is in there. Take time to read it, as there is more than 1 IP involved in getting your mail there.


Storing user credentials in local file or database

Seems you are doing all the right things regarding crypto (salt, pepper, proper hashing algo). The additional security you might get by either going local file system or storing within a DB running on a different machine might not be significant.

If you go local file system

If possible turn on filesystem level encryption.
Set appropriate access permission on the file.

If you go the DB route

Make sure that machine running DB server is properly hardened.
If possible turn on DB encryption.
Ensure user authentication required to access DB.
If possible ensure Application Server to DB communication is over a secure channel


Deleting credit card information after every transaction

effective in securing it from this kind of theft?

Threats against credit card information while shopping online are diverse. I would say that your proposal is effective (as oppose to having no effect whatsoever), but the overall threat reduction is small.

This technique might be effective in partially mitigating some of the following threats:

Companies who store your credit card details at rest in either plain text or with weak encryption
Threats from malicious employees who might have access to the database
An attacker who compromises your account and places orders while logged in as you

However, this technique would make little difference in the following circumstances:

Man-in-the-middle attacks where the attacker can observe your credit card details during transmission (SSL/TLS is effective at controlling this threat but that's another story)
Compromised software or malware on systems that interact with your credit card details, such as web servers, databased servers, payment terminals
Attackers who have access to database backups which might contain your credit card details even after they've been removed from your account
Software which does not actually function in the way you'd expect. For example, you can't be sure the system doesn't just mark your credit card record as inactive as oppose to physically deleting it. You also can't be certain the record is securely deleted and not recoverable by someone who has access to the hardware.
If your credit card details are included in any logs which might remain even after you've removed the credit card from your account
Dodgy merchants and phishing

  There have been many reports of hackers compromising credit card
  information

If we look at a few recent case studies:

Target

  At the critical moment — [...] — the malware would step in,
  capture the shopper’s credit card number, and store it on a Target
  server commandeered by the hackers.

It wouldn't have been effective in that case as the attack was executed while the payment was being processed rather than while the credit card details are at rest.

Staples

  Staples says as many as 1.16 million customer credit cards may have
  been compromised as part of a malware attack

Home Depot

  the malware in this attack was embedded in the company's in-store
  payment systems

So it would seems that malware is a common thread in several of the most publicised attacks. Having said that all these examples are big-box retailers rather than strictly online stores.

TLDR; It would have some effect, but overall probably not enough to be worth doing and it depends on the merchant whether it would be effective at all.


I assume that you are referring to various different users, rather than one in particular (given that it is a public computer the chances of it being the same person every time is slim), so I would say that you are already doing the right thing.

It could be tempting to go a little further and try to contact the user(s) and let them know what is happening, but their is a fine line between being helpful and crossing over into unauthorised access (to find out their contact details or using their account to send them a message), which depending on your location might be illegal.
Also if someone lacks awareness of the need to logout they may well not understand the advice you try to offer and it could end up being misconstrued and cause you a whole bundle of hassle (I speak from experience!).

Depending on the organisation that has provided the computer, it would probably be worth bringing it to their attention, that way they have the option to make users aware of the need to explicitly log out of sites after use, hopefully they will have some appreciation of the implications and do something to try and raise awareness (though how is dependent on the local setup).

Ultimately though it is down to the individual to be responsible for their actions, there is only so much the rest of us can do.


Authorization expiration without reliable clock / time

Your question first sounds ironic, because you seem to not want to use or trust NTP while I assume your system is connected to the Internet.

But what if we assume that you do not trust you connection to the Internet and fear a MITM attack or other tempering. This would render the NTP indeed useless. But with preshared initial certificates, your primary system could work. And you will have to trust (at least some of) your successfully verified communication partners.

Here, you have still an option for the expiration feature: you can ask your other valid peers periodically for the time (sort of reimplementing NTP in your application). This should yield you a clock with at least a precision of some seconds (or better).
If you reboot you can save the last time, and asked for the time as soon as possible. However, if you reboot your system within minutes, you still maintain a clock with a precision of minutes (So your clock on a freshly rebooted system never derivate for the actual time further than the time it takes to reboot). Since certificates are usually issued for about a year, a precision of minutes a perfectly fine.

If you mean your problem is, that you do not have a something to count real time, you still can go with a logical clock. So you can e.g. count how often a certificate is used (signing/verification) and reissue a new one if a threshold has been exceeded or expire the certificate if used further. You can either count this per certificate or for all together.


Is it bad practice to remove a resolved report from Open Bug Bounty archive?

On the Open Bug Bounty website about page, it states:

  ...security researcher[s] can delete the vulnerability submission at any
  time before public disclosure of the vulnerability details. However,
  once disclosed, the submission can no longer be deleted to prevent
  undue pressure on the researchers. We never remove any information
  about vulnerabilities for political or business reasons.

The only real reason the reporter is offering to delete this report is likely because once the vulnerability publicly disclosed, it's public and cannot be deleted.

I can't think of any good reasons to have the report be deleted prior to public disclosure. There are plenty of good reasons to postpone a disclosure, but not to delete one.

Contact the reporter to confirm they have no other concerns about this report. While unlikely, they could have a legitimate reason to delay the public disclosure.

Best practice would be to go forward with public disclosure under your agreed disclosure timeline.

(That said, if the reporter chooses to delete the submission on their own volition without your input, that's their right according to how Open Bug Bounty is set up.)


First of all, I hope by domain.com and subdomain.domain.com you do not mean you are using HTTP in which case the cookies are highly exposed and manipulated on an attacker's will. I hope also -in case you are not using HTTPS- the services of your website are not crucial (not e-commercial, for instance).

As a general good security practice, **never store private information in cookies **. If a client of your website uses his/her main email address to login then for sure they wouldn't like to see it used by a third party (spams) thanks to your website (in case you use, for example, Google AdSence). Add to this a set of common famous cookies' vulnerabilities such as  cross-site cooking or simply cookie theft.  An email address is important data -in my case, I wrote it encoded on my profile. I definitely advise you not to use email within cookies.

Solution:

As everything else, sessions are not safe for 100%, but still it is better to generated unique session identifier in the cookie, and  store everything else on your server instead. This pretty much eliminates common threats such as cookie poisoning. And as for cookies, do not store  any data in the session pertaining to access credentials (in your case, the client's email ?)


How to run nmap HTTP scripts on unusual ports

The other answers here are very good. However, there are a couple ways to do what you want that will work without editing the scripts:

You can teach Nmap to recognize this service. Nmap's service fingerprints are in the nmap-service-probes file. Nmap already recognizes some versions of MiniShare with this match line, added in Nmap 6.00:

match http m|^HTTP/1\.1 200 OK\r\nContent-Type: text/html\r\n\r\n.*<title>MiniShare</title>\r\n.*Total: (\d+) files	([^<]+)
\r\n
\r\n

MiniShare ([\d.]+)|s p/MiniShare http interface/ v/$3/ i/$1 files, $2 shared/ o/Windows/ cpe:/o:microsoft:windows/a

But your service responds a little differently, and does not match. Please follow the instructions Nmap provides to submit this service fingerprint so that other users will benefit. In the meantime, you can construct a similar match line so that the service will be identified as "http" with -sV and the script will run.
As a general rule, you can try updating to a newer version of Nmap. At the time of this writing, 6.47 was the latest version, so this won't help you, but it may help someone reading this answer later.
You can force NSE scripts to run against all open ports by prepending a "+" to the script name. For example, --script +http-title will try to request a page and retrieve the title for every open service on the target. This can be dangerous and slow because the scripts were not written to be run against arbitrary services, and may time out or crash the target services.

One final warning: requesting --script http* will try to run a lot of scripts that you may not intend, including (in the development version): 23 "exploit", 1 "dos" (denial of service), 51 "intrusive", and 10 "external" category scripts. A better way to specify this would be --script "http* and safe" or --script "http* and default"


How to pass PCI DSS 2.0 anti-virus requirement (5.1) on Linux?

Can you pass PCI DSS without installing antivirus on all linux
  workstations and servers?

Yes, absolutely.

  Can you pass PCI DSS without installing additional firewalls or
  configuring iptables on all linux workstations?

Yes, absolutely.

In both cases the PCI-DSS contains statements that allow you to make reasonable arguments as to the applicability (or not) of the requirement to specific systems.

You must put AV on all "systems commonly affected by malicious software".  If you don't want to put it on Linux, then you must make the case that your systems aren't affected by anything an AV package detects.  And, obviously, if that Linux server is a Samba file server for hundreds of Windows clients, that's specious and you should do it anyway.
DSS 1.4 doesn't say you need firewalls on all workstations, it says you need firewalls on all "mobile and/or employee-owned computers with direct connectivity to the Internet".

Now, @graham-hill correctly points out you'll need to convince other people of the truth of these things.  Maybe those other people are your auditors, maybe those other people are your own coworkers.  Maybe they're reasonable, and maybe they're not.  Maybe it's easy, maybe it's hard.  Read the requirements, document your case, make the argument, try to win... and realize that it's an unjust world and you may lose anyway.


Best practice is not to encrypt the passwords at all, but to hash them instead, for precisely this reason: if you encrypt, then you need to have the key available to the server.

If your system is such that it absolutely MUST store the actual passwords - for example, your server connects to some other service impersonating the user - then there are a few things you can do, like using an HCM, or storing the key on a different server in the hope that it doesn't get stolen along with the main one, or using something like OAuth so that the credentials you store are only usable by the server and hence of less use to an attacker.

But these are only partial mitigations. If you store passwords on the server then the server knows them and if someone compromises the server they can learn them too.


Is it always better to put authorized_keys in one's own .ssh directory rather than in root's .ssh directory?

Security wise you want people to use sudo not su (Sudo can be setup so it logs all activity, a.k.a. an audit log).

further more on most *nix root access to ssh is prohibited (Setting in the settings file that I would recommend you enable). this is to prevent a breached SSH(-server) can be utilize for ROOT access.

Further security I would recommend is use encrypted keys (e.a. you have a password you need to enter for your key not your login prompt) and use an agent to share your public keys. Otherwise all I would need is your stored key to gain access, removing 1 of the security thresholds.

further more, limit sudo (and su) use for System Administration tasks only (and only for those task you can not do otherwise) use groups for shared access not the root.

I would even go so far as to recommend you use different keys per connection (do not reuse keys especially the id_rsa key) and use the .ssh/config to set what key is used when.

-> Additional Clarification for the "different keys"

The reason you use different keys is so you have layered security, it makes it easier to revoke a key and replace it (and not 'forget' an old server locking you out of that one) and if you do it per client and connection you have the same option on both ends.

Especially if you control more than a few servers this can become a hassle in the long run. for some systems I even have more than 1 key to segregate permissions and authority (having multiple "security zones" on the server with different keys (that have different passwords) so that the one with write access is not the same as the one with shell access.

Another Point I would like to make is that its always better to use the least amount of permissions as possible. So instead of using su to login as root,  use su to become a different user (the one with write permission in your folder anyway, such as www-data on ubuntu for the apache httpd folders) than do your thing, and if you really need to use more permissions (change permissions and installing applications are those mostly for me) use "sudo [operation] (options)" instead of just sudo su. not only leave this cleaner audit logs, it also limits possible errors (writing in the wrong location, writing files as root when they should be owned by the webserver, etc.) and it requires you to know  what it is you are doing. instead of just going "hey, it worked like this last time".

"Sudo su" is like removing a wall with a pipe bomb. it removes the wall, but a simple sledge hammer could have done the same (with less possible collateral damage).


On a general basis:

/dev/urandom is no less secure than /dev/random. In fact they both use the same algorithms and the same seeds. Occasionally, /dev/random just stops because someone, someday, read something about entropy, did not understand it, and now thinks that randomness is something that is burned upon usage and must be refilled regularly.

(This page makes a rather nice job explaining things on that subject.)
There can be situations where there is not enough available entropy in the whole system. These situations do not occur with normal Linux distributions because they generate and save a random seed at boot time, to be used for the next boot, effectively ensuring that /dev/urandom is cryptographically secure all along. To get into one of these situations, you have to either play some weird games with VM snapshots, or use not a PC but some very limited embedded system; this is quite far from the contexts where you would use GnuPG.
It is very noteworthy that in the case of VM snapshots, the "entropy estimate" of /dev/random will gleefully report that it is full of the stuff, which is, in this case, very wrong. That is, not only does the blocking behaviour of /dev/random is scientifically unsubstantiated, but it also totally fails to be triggered in the one practical case (VM snapshots) were entropy loss could be feared.
Also remember that contexts where /dev/urandom is inappropriate are also contexts where /dev/random is inappropriate. Using /dev/random will not make things "more random"; at best, it will refuse to work instead of generating a key of theoretically lower security ("theoretically" because none of this has ever resulted in a practical break, even as a demonstration in lab-controlled conditions). As explained above, this is really an "at best" and it won't actually work that way with VM snapshots and reset.

Fortunately, all the activity involved by a boot implies collection of enough entropy to achieve cryptographic security (for arbitrarily long /dev/urandom outputs, even). See this article for more analysis. GnuPG key generation is not done by the kernel in the early boot steps; it occurs much later, during normal operation, when the PRNG has been properly seeded.

None of this prevents some people from insisting on some ritual dancing with entropy. Apparently, the GnuPG authors are part of that specific theological interpretation -- either because they believe it or because they yield under the market pressure.

Summary: using /dev/urandom instead of /dev/random is not weak for GnuPG. GnuPG is used in a context where /dev/urandom is properly seeded and will achieve all the required unpredictability, and /dev/random will do no better (not in practice, not in theory either). In the one situation (VM snapshots) where the output of /dev/urandom could be inadequate for GnuPG, the output of /dev/random will be equally inadequate for the same reasons, and the blocking mechanism of /dev/random will not be triggered. The conclusion is that switching from /dev/urandom to /dev/random for GnuPG is completely useless.

... that is, from a technical point of view. Using /dev/random instead of /dev/urandom could induce some blocking that can help in persuading the weakly-minded that "serious cryptography is happening". It won't make things more secure, but it may make the user feel safer.


Why does an iphone require me to enter the passcode and not accept my fingerprints when I switch it on after power off?

Since iOS 8, full disk encryption is enabled by default and the passcode is used as key (paired with some secret kept in the phone's HSM so offline bruteforcing is not possible, making it relatively secure even with only a numerical code).

For FDE to work we need something consistent as a key. A passcode fits the bill perfectly, it either matches or doesn't. You also do not need to know the code itself to be able to tell if the entry is correct - an one way hash will still tell you whether the entry was correct while making it extremely difficult to reverse the process and get the code from the hash.

A fingerprint on the other hand is never an exact match. It's always fuzzy and there is a tolerance percentage under which the fingerprint is considered matching, otherwise it's not. Since it's never quite consistent most hashes we use for passwords are out of the way so you have to keep an entire picture of the fingerprint to be able to tell whether the fingerprint is correct, so if someone gets that data it's trivial to make a fake print based on that, whether as with passwords you'd have to bruteforce the hash before you get the actual password.

This also means a fingerprint can't be used as a key for FDE, because it will always be a little different on each scan, or, if the fingerprint image is kept somewhere unencrypted for comparison before revealing the real FDE key then it's insecure because an attacker could just obtain that real key right away (using hardware attacks, exploits, etc).

This is the reason why a passcode is asked on first boot. It decrypts the data partition and keeps the key cached in RAM, where on subsequent unlocks the partition is already mounted and decrypted, and the lock is purely a software restriction. It would also make sense for the phone to keep fingerprint data on the encrypted partition, which means at boot the phone has nothing to compare your fingerprint against to tell if it's correct or not.

Finally fingerprints are not more secure than passwords because you leave them on everything you touch.


I'm not sure how you would be able to do XSS based purely on numeric values. However a good approach is to always escape input variables and check them for type. For instance if a user is required to input a number, he might also insert a string which could cause an exception in your program. This is something you need to take into account. Note that client side validation is useless (so checking with JavaScript or a dropdown list with only numbers is not going to help you perform secure input validation).

So in Python you can do:

   try:
       float(variable)
       "do database logic"
   except:
       print "not valid."


Modifying requests using Burpsuite considered to be valid security vulnerability?

What Burp does is intercepting a request and allowing the user/pentester to modify it. Technically it acts as a proxy, allowing the user to send pretty much arbitrary input to your application (server-side).

You seem to assume, that requests can only be sent using your app. This is not true and generally pretty dangerous to rely on. Keep in mind, that everybody can do a "Bash-Fu-1-Liner" using cURL and send literally anything to your server. Your webservice has to be prepared for that! If the only input checks you perform are client-side (which is untrusted code as users can mess with it), you have to overthink your security measures.

Separate client-side and server-side. Think of them as two pieces of software which have to be secure on their own.

Edit: As you added a test case to your question, I'll add the answer here. Penetration Tests flag a lot of things as potentially dangerous. It may be true and little bugs, which don't look like they can wreck havoc on your server, will do so, if exploited properly. However, a Penetration Tester will scan your app, test around, find bugs and report everything which looks dangerous. Keep in mind, that he does not know the application as well as you (or the Software Engineers/Developers) do.

Bugs found by him/her might be false positives and it's on you (and the tester) to verify bugs and prioritize them (irrelevant - critical) according to their damage potential (and other factors). Once in my environment, a pentester's scanner found a document which was reported as "Privilege Escalation" as its regular link is behind a login. False Positive, as it was an unimportant document.


How to provide to your Webpage a security like Wix and how to break that security

Make sure httrak is setup to spoof a real browser (user agent), and try and slow the requests down. Wix probably blocks known download user agents.

See this page:
https://www.httrack.com/html/fcguide.html
You will need to search on the page as it's very long.


Deterring Mobile phone Tethering in the workplace

There are potential technical options you can pursue, and several of those have been mentioned in other answers, such as global policies or BIOS settings to disable the USB ports, or physically disabling the USB ports.

However...

My suggestion is that if you have a systemic problem with this sort of thing, it isn't, in fact a technical problem at all, but a policy or people issue instead, and you should be looking for ways to deal with the underlying issue, and not the symptom of mobile tethering.

The most likely cause, is in fact you.  (You being inclusive of the IT department, management, and the policies in place.)   If your policies are too restrictive, and people are having a hard time doing their jobs because you've removed or disabled the tools that they need, good employees will become frustrated, and they will find ways around your restrictions in order to accomplish their duties.   With good employees, productivity always wins the day, no matter how hard you try and prevent it with policy and technology.   As the saying goes, security at the expense of usability comes at the expense of security.

So, if that is in fact the issue at play here (and in order to find out you'll have to actually talk to the employees!) then you need to figure out how to change your policies in order to enable them while still effectively managing risk to the business.  There will have to be trade-offs, but such is life.

There are other less likely possibilities, such as perhaps this behavior is limited to users who don't know that it isn't allowed, or who would rather goof off at work with things that have no business purpose than do their jobs.   If that is the case, it's still a human resource issue, not a technology issue, and the solution is not to crack down on tethering, but to crack down on those employees and educate them or show them the door.

In any case, don't jump straight to a technical solution for a behavioral issue.  You likely aren't going to solve the problem, but may in fact make it worse.


"Security" is a bit too broad here.

If you're looking for integrity checks -- that is, "has the file been altered in transit?" -- then what you need is a checksum. Just about any cryptographic hash will do (except MD5 and older, maybe avoid SHA-1 as well for new projects), so SHA-256 for example is a fine choice.

Of course, if you want the recipient to be able to crypographically verify the checksum, then what you're after is a digital signature. Roughly: you checksum the file, you then you encrypt the checksum with your private key, which means anyone in possession of your public key can decrypt the checksum, compare the checksum against the file, and verify that it's the one you signed.

Don't implement this yourself directly; use GnuPG or PGP. They've worked out the details that I glossed over.

If by "security" you mean "secrecy" -- if instead you want to guarantee that the file is only readable by the person you intend to send it to, then you encrypt the file using the person's public key (using the standard combination of asymmetric and symmetric ciphers), which means that only the intended recipient can decrypt it.

Again; use GPG or PGP. They do it right.

If you want to have both, then do both. The combination is also supported.


Xss filter bypass ><script>alert(1);</script>

There is no default way/trick to bypass this.
However you can try to identify if there is a regex in place that you can break.
Or if there are any normalization/decoding inconsistencies.
Some ideas:

Check if the encoding happens recursively.
if you provide multiple '<', will they all be encoded?
Try different types of encoding (e.g. url encoding, double URL encoding) and see how the application treats them.
There are cases were the application normalizes Unicode characters (have a look here Unicode Normalization Bypass)


If malware does not run in a VM why not make everything a VM?

One has to take into account why the malware is doing this distinction in the first place.
Some malware does not run in the VM because the chance is high that this VM is used for inspecting the malware (i.e. some security researcher) since most normal users don't use a VM. But if everybody is using a VM then the chance is low that the VM is used for inspecting. This means there is no real reason anymore to use this kind of simple heuristic to distinguish between a potential security researcher and a victim. Therefore this heuristic will be considered useless and a different one will be used in the future. Which means that future malware will also run inside a VM.
Note that there are also other heuristics, like checking if specific tools often used by researchers are installed on the system. Now, why not just let everybody install such tools in order to disable malware? Same reason: the heuristic will be no longer used by the malware authors since it no longer works reliably enough.


What are the real world risks of sharing your device and network information with advertisers?

This is typical tracking behavior for most types of Internet advertising. The information you mentioned (IMEI, MEID, etc) can be used to track various things, such as which apps you use on your phone, your geographical location, etc. Given that this is an android phone (apple can be even worse!), Google can link your phone activity to activity you do on other devices, such as your computer or maybe your tablet. It essentially is used to build a profile of who you are in order to target advertising toward you that you may have an interest in.

Chances are, they know you better than you know yourself.


Character filtration in globalisation supported application

Trying to duct tape "more security" by trying to guess what is safe and what is not is going to fail.

The only way to make sure you don't get code injected through input is to treat input as data and never mix it with code, whether it might be safe or not.

For SQL that means prepared statements.
For XSS attacks it gets a little trickier because there is no such easy option.
But the basic rules are the same. Do not mix data and program logic.

So to summarize: Do not try to best-guess what of your input is safe to treat as code. Never treat it as code. Separate code and (input) data and you don't have to worry about other languages and character encodings.


How to explain computer security to low-grade students?

The chap who runs ISECOM (Pete Herzog) has an initiative called "Hacker High School" (he mentions them in nearly every email he sends out!)

http://www.hackerhighschool.org/lessons.html

There's an interview here about it:
http://www.securitybistro.com/blog/?p=3952


Find security weaknesses in this website (exam question)

Vulnerabilities 1 & 2:

5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);

These are SQL injection vulnerabilities. The program invokes a SQL query built using input coming from an untrusted source. As you pointed out $USER is vulnerable but $message is also.

Vulnerability 3:

8s  if (!empty($row)) {
9s     echo ”Your message: ”.$message.” has been added”;
10s   }

This is an XSS vulnerability. Although it is hard to classify specifically the type given the little amount of source code, because the data is being stored in a DB (thus making it persistent); however the example code does not show other areas it is output, so we can only state that it is reflected at this point.

Potential Vulnerability 4:

3s  $pass = $ ̇REQUEST[”pass”];

Computer programs depend largely on context, so while it appears that the author of this program wanted to authenticate, this may not be the case. If the author did want to authenticate, then $pass is not checked anywhere. Regardless of if this is a vulnerability, this is unused code. It is bad practice to leave unused code in a production program.

Potential Vulnerability 5:
1c  <form action=”message.php” method=”get”>

This is potentially a CSRF vulnerability. Once again this is dependent on the programmers intent to have validation. If they did then the form post must contain a user-specific secret in order to prevent an attacker from making unauthorized requests.

Potential Vulnerabilities 6 & 7:

5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);

$message and $USER are potentially stored XSS vulnerabilities, although the sample code does not show these variables getting retrieved, it would be fairly safe to assume these may be displayed in another part of the program.

Potential Vulnerability 8:
4c
Password: <input type=”text” name=”pass” />

This is potentially a shoulder surf vulnerability. This input should be obfuscated. Once again this depends on the programmers intent to actually validate, and the actual meaning of the pass input field. We can assume that this is a password, but unless we get confirmation from the programmer, it is just that, an assumption.

Potential Vulnerability 9:

1c  <form action=”message.php” method=”get”>
2c
Message: <input type=”text” name=”message” />

3c
Username: <input type=”text” name=”user” />

4c
Password: <input type=”text” name=”pass” />

5c
<input type=”submit” />

This is potentially a shoulder surf vulnerability. This will result in a GET request displaying the password on the URL, which could result in a shoulder surf attack. Once again this is dependent on the programmer' intent.


Is the Common Name mandatory for digital certificates?

As far as X.509 is concerned, the Common Name is not mandatory. However, a number of systems will use the CN for display purposes, e.g. most "certificate manager" GUI in Windows. Therefore, it is recommended, if only for ease of sysadmin tasks, to include reasonably precise CN in certificates.

If you want to, from an application, pinpoint a specific certificate, then the good identifier to use is the "thumbprint", which really is a hash of the certificate. As long as the hash function is collision-resistant (Microsoft uses SHA-1, which is still quite robust in that respect), no two distinct certificates will exhibit the same thumbprint.

The "standard X.509" method of referencing a specific certificate is to use the pair issuerDN + serial number. Only the combination of both values is (supposedly) unique; serial numbers alone don't cut it. Mind that I am talking about the issuer's name, not the subject's; and this is the whole DN, not just the CN part of it. Moreover, it is allowed for a certificate to have an empty issuerDN provided it also contains an Issuer Alt Name extension with the complete DN. This means that properly using the issuer+serial pair can be somewhat complex. The thumbprint is easier.


SQL Injection after Like Operator with continuing query

MySQL does not normally allow multiple statements per call, so you can't do this type of injection. The error you're seeing is because of this. The application has to explicitly enable multiple statements per call, which is done differently on a per-language basis. For example, PHP has mysqli_multi_query, whereas the C binding requires you to pass CLIENT_MULTI_STATEMENTS to mysql_real_connect and then query calls can have multiple statements in them.

Whereas other RDBMS products (e.g. MSSQL) support a SELECT ... INTO syntax that may allow you to inject an INTO clause onto the end of a SELECT and use it to add new rows to another table, MySQL does not support this synax. Instead you have to specify INSERT INTO at the start, so it isn't possible to inject an INTO clause in this fasion.


What cryptographic module does Sql Server 2008 use to run in Fips 140-2 compliant mode by default?

You can find all official and validated modules on the website of nist.gov. SQL server could make use NetLib® Encryptionizer® DE/FIPS (number 1532).

All though it will probably make use of the standard  Server 2008 libraries encryption which provide AES encryption. (The standard encryption in SQL Server 2008).
I believe that dssenh.dll (Cert 1338) and rsaenh.dll (Cert 1337) have been FIPS 140-2 validated.


Sending a skype message by ip or mac addresses

Skype traffic travels through the Skype central servers. You cannot directly connect.


How might my browser session be hijacked on iOS Safari?

This looks like a rather insidious ad which Rotten Tomatoes happens to have on their site. I've seen several other sites where they redirect me to a URL which then opens the App Store and I can't get back to the original site... Because of the sand boxing of iOS apps and because you have not jail broken your device, I have no reason to suspect malware in your device.


Does "crypto offloading" require the use of ASICs? Can the concept be applied elsewhere?

Simply put, not, crypto offloading does not require ASICs.  To expand:

Crypto-offloading simply means removing the computational burden of encryption operations from a general purpose system, and performing them on a dedicated system instead.  The example from your training materials is dealing with TLS, and removing the responsibility for encrypting the connect from mail or web servers, and leaving it to a purpose built SSL terminator instead. The actual underlying hardware (ASICs, in their example) is not important to the higher level concept.

In addition to SSL terminators (or load-balancers with TLS offloading capabilities) some other examples of encryption offloading are layer-2 network encryption appliances, VPN concentrators, or the example you proposed, HSMs, which can indeed serve to off-load crypto operations from an application or service.

Inside the SSL terminator, VPN concentrator, or HSM, you could be performing the crypto operations with ASICs, with FPGAs (as @cHao mentioned in a comment) or even with standard general purpose CPUs.   20 years ago, ASICs were a very common option due to the performance increase they could provide over the general purpose CPUs of the day.  Today, not so much.  You still will find devices with ASICs, but nothing really needs them any more.  Even Seretas's 100Gb/s line rate link encrpytor uses much less expensive and more flexible FPGAs instead.   General purpose CPUs are so much more powerful these days that not only can they handle reasonably heavy encryption as well, but many applications don't feel the need to off-load crypto at all any more...With today's CPUs (most of which even have specific AES instructions for encryption), the demands crypto places on them simply aren't enough to justify off-loading any longer.


Proper way to obtain CA certs for verification

I have seen this done with SSH key authentication by phone.  The procedure was for me to generate private and public keys and send the public one to the hosting provider via email.  They would then phone me, read out half of the fingerprint and require me to read out the other half.  If they matched, they would put my public key on the server and I could log in.

This is unlikely to be practical for verifying Facebook's SSL certs, however the key point is that the verification was done using a different method to the original transfer which makes a potential attacker's job much harder.

If you can request the certificate using a different computer on a different internet connection and compare it to the one you have then you can be reasonably certain that you have the correct cert.

SSL has chains of trust which SSH keys don't, so it should be adequate to verify the root CA certs and use those to verify the target cert.

On Ubuntu, there is a ca-certificates package that contains the certificates that the Ubuntu maintainers trust.  The certificates themselves can be found in /usr/share/ca-certificates.  Other Linux distributions will have similar packages.


The code128 checksum is not cryptographically secure.
I think you are misunderstanding the purpose of a checksum. A checksum is designed to make it possible to detect accidental corruption or mistakes in reading data. The data is converted into a checksum, and compared with the expected checksum. If the two differ, you know that there was an error in reading the data. The intention is to reduce the chance that an accidental mistake in reading results in the same checksum. The checksum algorithm itself is public and is easy to calculate, such as with the following function, where code128_table is a specific index table (Code A, B, or C):
uint8_t code128_checksum(uint8_t *buf, uint32_t len)
{
    uint32_t sum = *buf - 32;

    while (--len)
        sum += len * code128_table[*(buf + len)];

    return sum % 103 + 32;
}

This checksum is extremely simple, designed only to make detection of errors during the scanning process possible. It is a "true" sum, meaning that it is nothing more than the summation of the representations of each component character multiplied by a weight factor. Thus the sum is literally just that, a sum of the data it is protecting. It is not designed to provide any sort of cryptographic properties to the barcode. The way it is designed, all the following are trivially possible, in order of increasing computational complexity:

Hashing - Given an un-checksummed barcode, calculate the checksum.
Collision - Create two barcodes with different contents but an identical checksum.
Second preimage - Given a checksummed barcode, create another with the same checksum.
First preimage - Given only a checksum, create a barcode with the same checksum.

The only thing which it is (modestly) good at is ensuring that a random change to the barcode will not result in an identical checksum. Even for that, it's not particularly good. A superior (albeit still not cryptographically secure) checksum of the same digest size would be CRC8, as a CRC is superior to a regular checksum for the purpose of error detection. A simple implementation of an 8-bit CRC (where crc8_table is a carefully selected 8-bit CRC polynomial) would look like this:
uint8_t crc8(uint8_t *buf, uint32_t len)
{
    uint8_t crc = ~0;

    while (len--)
        crc = crc8_table[crc ^ *buf++];

    return crc;
}

Regardless of whether you use a simple checksum, CRC, or a significantly more complex and slower cryptographically secure hash function, if the keyspace is merely 8 decimal characters and all 8 characters from the sequential ID are valid for the company ID B2DS, you could, quite trivially, create all 99,999,998 possible barcodes, with matching associated checksums. A completely unoptimized implementation took 19 seconds on my own computer. The keyspace is just too small, even with a cryptographically secure hash.
As @Philipp mentioned in a comment, a better solution would be to hand out barcodes with a random ID. Allow each ID to be used a limited number of times, and monitor for attempts to use a barcode with an ID which has not been explicitly issued. If that is done, then even if there are a thousand valid barcodes at any given time, a random barcode would have only a one in ten thousand chance of being valid, making it far harder to use the codes fraudulently.


How secure and how to find if a website use Flexible SSL from Cloudflare?

Flexible SSL does not provide end-to-end encryption. From here:

you can see that the CloudFlare link to the server is unencrypted.

However, as the user link to CloudFlare is, this mitigates most typical Man-In-The-Middle scenarios. For example, ranging from Mallory on the coffee shop wifi connection, to rogue employees at an ISP, all the way up to government agents in a regime (except for the case where this government controls their own trusted root/intermediary certificates they could use to sign your domain).

Risks of having the CloudFlare to server link unsecured means that not only is the traffic unencrypted, there is no authentication between CloudFlare and your server. Any attackers in such a privileged position to perform a BGP Hijacking attack, would be able to reassign the IP address of your server to their own server, and intercept the traffic. If you are connecting from CloudFlare to your server by means of a hostname, then some type of DNS attack may be possible. This would probably have to be an attack on the DNS records themselves rather than a DNS poisoning attack because it would be difficult to pinpoint which CloudFlare endpoint would be resolving the lookup.

This also does not protect you against any rogue ISP employees or government agents within your hosting country.

As for the end-user - there is no real way of telling whether a connection is via Flexible SSL because the browser address bar and padlock will only authenticate their connection to CloudFlare, not to your server.

As for any attacker - they may be able to do some passive recon and find out where your domain used to point to, giving them the address of your endpoint. From here they could try some direct connections to find out if your server accepts HTTPS connections, or is simply plain HTTP. You can mitigate this by blocking all source traffic not sent from CloudFlare's IP ranges.


Private keys with or without password for webservices?

From my point of view you should not have the private key with password on this scenario, because your microservice will need to know the password in some way.
In general and from my experience the private keys of microservices are stored in other backends dedicated to this, for example with LDAP. So your microservice that is authorized to the backend that stores the private key, can transfer safely the private key to the memory of your microservice directly. Of course this depends on the setup that you have and how the services interact with each others.


Opening browser with already authenticated user in other app

As soon as the user clicks the button, create a long random single-use token and send it to the server (something like yourdomain.com/setsession?session=SESSIONID&single-use-token=TOKENID. This token will be used later to retrieve the session id.

After that, the application start a very simple HTTP server, and serve its own HTML page to the default browser. This page will redirect to yourdomain.com/getsession?token=single-use-id, which in turn will open the desired page and set the session cookie.

The getsession component will do a lookup for the token, and if it comes from the same IP as the setsession, it will delete the token, and send the session cookies to the browser.

With self-destruct tokens, you don't have to worry about replay attacks and token reuse, even if someone sees the token.


Can you sniff VPN traffic just like you would a coffee shop?

VPNs are encrypted per User. What tcpdump will tell you in a Public WiFi is that there are people using VPNs. But thats all - everything else is encrypted and - assuming the VPN vendor implemented the crypto correctly - cannot be sniffed on the user-side.

However: If you know the VPN users exit node you could sniff packages travelling in the exit nodes network. You would then have to corelate these packages with the encrypted ones you see the user sending/receiving. Inpractice, this is very cumbersome due to the vast amount of internet traffic but was effectively used by the FBI to pwn tor users. That means: Using a VPN and not using HTTPS/TLS creates an attack surface big enough for a determined attacker to render your VPN useless.


OneDrive: How can Windows Security's "Remember my credentials" feature be misused?

I assume what is remembered is the OAuth2 refresh token.

In this case,

no, it can't be used for other services.
yes, it can be used from another PC. From the server side, it's no difference. Maybe a different IP, but that could be your "first" computer too
this token is valid for at least 6 month in Onedrive (https://github.com/OneDrive/onedrive-api-docs/issues/124) (altough changing your password invalidates it immediately)
no, the token alone, without server access, isn't related to login name and password.