npm git private repo auth

Our enterprise Github recently made a change so all anonymous access from work laptop are blocked. This causes problem as we have some private repo dependencies in our package.json like below:

dependencies {
 "sun": "git+",

Whenever I try to do npm install, it gives me authentication error. I can get it installed by add username password to the github url, however that would expose my plain corporate password.

After some research, it turns out  Git uses curl under the hood, you can use ~/.netrc file with the credentials. For GitHub it would look something like this:

  login <github username>
  password <password OR github access token>

This way, I can just have a github personal access token sitting in my .netrc file and it will always work. It is better than password as the corporate password get expired every 60/90 days and then the file need to be updated every time that changes.


oauth grant types

Recently we need to integrate our frontend spa with oauth(call third party apis), Need to figure out which grand type fit which use case.

The specification describes five grants for acquiring an access token:

  1. Authorization code grant
  2. Implicit grant
  3. Resource owner credentials grant
  4. Client credentials grant
  5. Refresh token grant

So most common is 1 and 2.

1 is for use case with a server which can store the client id/secret which can be used to authenticate the server app itself. The response after app auth will contain refresh token that can be used to request new access tokens.

2 is good for client side app(browser) which cannot expose client id/secret in js obviously. As a result, it gets the access token directly. The drawback is no refresh token is available because client environment can not be trusted.

3 is for first party app which collects the username/password itself and get access token back.

4 is good for app to app so that the request just need to contain client id/secret, it will get access token back.

5 is obvious, just the use case in 1 if access token expires.


this post has more details

you should never use WEP in router

Today I received another mail from Verizon saying my speed is upgraded to 75/75. However every time I test it is always 20/20. I also restart my router and even push the reset button at the back to do reset still no luck. So i decided to call them to see whether they throttled my bandwidth.

The tech support guy remote control my machine asking me to change the encryption type from WEP to WPA2. I was reluctant to do that since I have to change all my devices password again including all the laptops/desktop/phone/tablet/google-home/chromecast etc… Eventually I decided to follow him and made the change. And MAGIC happened, my speed jumps to 50/70. I really never could have thought the encryption type could affect speed that much. All I know previously was WPA2 is much more secure than WEP so I do not really care about my neighbor craking and using my wifi. Now knowing it would affect the performance so much, i would remember and never use WEP again. A good lesson.

What’s even better is if you have a 5Ghz, the speed will improve further according to this video.

stateful firewall with inbound outbound traffic


I have worked as Devops for cloud migration in the recent 3 months without really writing much code. Even though being exposed to many AWS services like EMR/EC2/ASG(auto scaling group)/LC(launch config)/CF(cloud formation) etc.. with the need of setting up security groups(SG), i find myself still a bit confusing with inbound and outbound traffic rules. Was wondering if i allow inbound traffic, i have to send response back to client which means i have to allow outbound traffic? Did some google search with the question and get the keyword stateful firewall.

So basically with a stateful firewall, when a connection is established, the firewall will automatically let packets out back to the client’s port. You don’t need to create rules for that because the firewall knows.


Before the development of stateful firewalls, firewalls were stateless. A stateless firewall treats each network frame or packet individually. Such packet filters operate at the OSI Network Layer (layer 3) and function more efficiently because they only look at the header part of a packet.They do not keep track of the packet context such as the nature of the traffic. Such a firewall has no way of knowing if any given packet is part of an existing connection, is trying to establish a new connection, or is just a rogue packet. Modern firewalls are connection-aware (or state-aware), offering network administrators finer-grained control of network traffic.

Early attempts at producing firewalls operated at the application layer, which is the very top of the seven-layer OSI model. This method required exorbitant amounts of computing power and is not commonly used in modern implementations.


A stateful firewall keeps track of the state of network connections (such as TCP streams or UDP communication) and is able to hold significant attributes of each connection in memory. These attributes are collectively known as the state of the connection, and may include such details as the IP addresses and ports involved in the connection and the sequence numbers of the packets traversing the connection. Stateful inspection monitors incoming and outgoing packets over time, as well as the state of the connection, and stores the data in dynamic state tables. This cumulative data is evaluated, so that filtering decisions would not only be based on administrator-defined rules, but also on context that has been built by previous connections as well as previous packets belonging to the same connection.

The most CPU intensive checking is performed at the time of setup of the connection. Entries are created only for TCP connections or UDP streams that satisfy a defined security policy. After that, all packets (for that session) are processed rapidly because it is simple and fast to determine whether it belongs to an existing, pre-screened session. Packets associated with these sessions are permitted to pass through the firewall. Sessions that do not match any policy are denied, as packets that do not match an existing table entry.

In order to prevent the state table from filling up, sessions will time out if no traffic has passed for a certain period. These stale connections are removed from the state table. Many applications therefore send keepalive messages periodically in order to stop a firewall from dropping the connection during periods of no user-activity, though some firewalls can be instructed to send these messages for applications.

Depending on the connection protocol, maintaining a connection’s state is more or less complex for the firewall. For example, TCP is inherently a stateful protocol as connections are established with a three-way handshake (“SYN, SYN-ACK, ACK”) and ended with a “FIN, ACK” exchange. This means that all packets with “SYN” in their header received by the firewall are interpreted to open new connections. If the service requested by the client is available on the server, it will respond with a “SYN-ACK” packet which the firewall will also track. Once the firewall receives the client’s “ACK” response, it transfers the connection to the “ESTABLISHED” state as the connection has been authenticated bidirectionally. This allows tracking of future packets through the established connection. Simultaneously, the firewall drops all packets which are not associated with an existing connection recorded in its state table (or “SYN” packets), preventing unsolicited connections with the protected machine by black hat hacking.

By keeping track of the connection state, stateful firewalls provide added efficiency in terms of packet inspection. This is because for existing connections the firewall need only check the state table, instead of checking the packet against the firewall’s rule set, which can be extensive. Additionally, in the case of a match with the state table, the firewall does not need to perform deep packet inspection.

DNS原理以及A/NS Record Cname

阮一峰 老师的一篇关于DNS的好博客,尤其喜欢里面对于分级查询以及A-Record, NS-Record, CNAME的解释, 简单明了, 所以转载了这一部分如下:







根域名的下一级,叫做”顶级域名”(top-level domain,缩写为TLD),比如;再下一级叫做”次级域名”(second-level domain,缩写为SLD),比如http://www.example.com里面的.example,这一级域名是用户可以注册的;再下一级是主机名(host),比如http://www.example.com里面的www,又称为”三级域名”,这是用户在自己的域里面为服务器分配的名称,是用户可以任意分配的。



# 即






  1. 从”根域名服务器”查到”顶级域名服务器”的NS记录和A记录(IP地址)
  2. 从”顶级域名服务器”查到”次级域名服务器”的NS记录和A记录(IP地址)
  3. 从”次级域名服务器”查出”主机名”的IP地址








$ dig +trace









七、NS 记录的查询


$ dig ns com
$ dig ns


$ dig +short ns com
$ dig +short ns




(1) A:地址记录(Address),返回域名指向的IP地址。

(2) NS:域名服务器记录(Name Server),返回保存下一级域名信息的服务器地址。该记录只能设置为域名,不能设置为IP地址。

(3)MX:邮件记录(Mail eXchange),返回接收电子邮件的服务器地址。

(4)CNAME:规范名称记录(Canonical Name),返回另一个域名,即当前查询的域名是另一个域名的跳转,详见下文。

(5)PTR:逆向查询记录(Pointer Record),只用于从IP地址查询域名,详见下文。



$ dig


;; ANSWER SECTION: 3370    IN  CNAME  600 IN  A




$ dig -x






$ dig a
$ dig ns
$ dig mx

bcrypt 加密算法

The prefix “$2a$” or “$2b$” (or “$2y$”) in a hash string in a shadow password file indicates that hash string is a bcrypt hash in modular crypt format.[3] The rest of the hash string includes the cost parameter, a 128-bit salt (base-64 encoded as 22 characters), and B184 bits of the resulting hash value (base-64 encoded as 31 characters).[4] The cost

Bcrypt basic

parameter specifies a key expansion iteration count as a power of two, which is an input to the crypt algorithm.

For example, the shadow password record :


specifies a cost parameter of 10, indicating 210 key expansion rounds. The salt is N9qo8uLOickgx2ZMRZoMye and the resulting hash is IjZAgcfl7p92ldGxad68LJZdL17lhWy. Per standard practice, the user’s password itself is not stored.



Bcrypt  vs Hash+salt

Both Bcrypt and hash+salt could prevent rainbow-table attack(which made the MD5 very vulnerable). In the Hash world, SHA(4 flavors) is better than MD5 in that it almost does not have collisions(collision is one of import reason MD5 is not secure since it is quite easy to generate collision in MD5).

Speed wise, bcrypt is ms level which is kind of slow if you have a lot of user login concurrently. hash+salt will be much faster though less secure.


如何生成安全的密码 Hash:MD5, SHA, PBKDF2, BCrypt 示例

2015 in review

The stats helper monkeys prepared a 2015 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 31,000 times in 2015. If it were a concert at Sydney Opera House, it would take about 11 sold-out performances for that many people to see it.

Click here to see the complete report.