iOS开发实战：Token + MD5 + RSA 接口认证方案详解

1. 项目概述与整体设计思路

1.1 这个项目解决了什么问题

在iOS客户端开发中，网络认证是每一款App都绕不开的环节。不管是登录接口、支付接口还是数据同步接口，只要涉及用户身份和敏感数据，都需要一套可靠的认证方案。我见过不少项目在初期为了赶进度，直接在请求参数里拼一个明文密码就上线了，结果被爬虫抓包之后用户数据大量泄露，只能紧急下线整改。这个项目就是针对这类问题，把iOS端常用的三种认证技术——Token、MD5和RSA，整理成一套可以落地实践的简明方案。

先说说为什么需要“认证”。客户端和服务器之间的通信本质上是不可信的，中间可能有抓包工具在窥探、有代理在转发、有恶意程序在模拟请求。认证要解决的核心问题是：服务器如何确认“你”就是“你”。Token的作用是身份凭证，用户登录成功后，服务器签发一个Token，客户端后续请求带上它即可；MD5的作用是完整性校验，防止参数在传输过程中被篡改；RSA则是加密和签名的利器，能够保证关键数据的机密性和不可抵赖性。

这套方案适合谁？如果你是iOS开发新手，刚接触网络安全概念，这篇文章能帮你把三者之间的关系理清楚；如果你已经有一定开发经验，但一直没有系统整理过认证方案，这里的代码示例和排查思路可以直接抄作业。项目中的代码基于Objective-C编写，Swift的实现思路也基本相同，只是语法层面的差异。

1.2 为什么选择 Token + MD5 + RSA 这个组合

很多开发者会问：现在都有HTTPS了，为什么还要自己做认证？这个问题的答案要从“传输安全”和“业务安全”两个层面来理解。HTTPS解决的是数据在网络上传输时的加密问题，防止第三方窃听和篡改；但服务器收到的请求到底是不是合法客户端发的，请求参数是不是被人恶意构造，这需要业务层面的认证机制来兜底。简单说，HTTPS管的是“路”，Token和签名管的是“人”。

MD5在历史上的地位很特殊。早期很多App用MD5给接口做签名，把参数排序后拼上密钥一起做哈希，服务器用同样方式校验。这种方式实现简单、不需要网络开销，但它有个致命弱点：MD5算法本身已经被破解，碰撞攻击的成本极低，而且对“密钥”的隐藏很困难。在iOS客户端里，硬编码在二进制文件中的密钥很容易被逆向工具提取。因此，这套方案里MD5主要用于非敏感数据的完整性校验，而不是用于高强度密码存储。

RSA则用来弥补MD5的弱点。它属于非对称加密，公钥加密、私钥解密，或者私钥签名、公钥验签。在iOS端，我们可以把公钥内置到App中，服务器持有私钥。客户端向服务器发送敏感数据时用公钥加密，服务器用私钥解密；服务器给客户端下发数据时用私钥签名，客户端用公钥验签。即使有人拆包拿到了公钥，也无法伪造服务器身份，这也是RSA在认证体系中最大的价值。

Token则是这三者中的“业务枢纽”。它由服务器签发，携带用户身份和有效期限，客户端通过它在后续请求中维持登录状态。整套方案的合作模式是这样的：客户端首次登录时，密码通过RSA公钥加密后传输，服务器解密校验；登录成功后服务器签发Token，后续请求带上Token；每个请求的参数再做一遍MD5签名，用于防止中途被篡改。

2. Token机制从设计到落地

2.1 Token的生命周期与存储策略

Token设计最核心的问题不是怎么生成，而是怎么管理。我在实际项目里见过很多团队，Token就简单设个30天过期，存在NSUserDefaults里，结果用户改了密码后旧Token还能用，账号被人在异地登录了都不知道。一个合理的Token生命周期应该包含：签发、携带、校验、刷新、吊销五个环节。

签发环节由服务端完成，Token里至少要包含用户ID、签发时间、过期时间和一个随机序列号。有些团队用自增ID，这会带来安全隐患——Token可以被枚举出规律，建议使用UUID等随机数。

携带环节，iOS端最常见的做法是把Token放在HTTP Header的Authorization字段中，形如Authorization: Bearer <token>。为什么不放在URL参数里？因为URL会被记录在服务器访问日志、代理日志、浏览器历史中，Token很容易泄露。放在Header里是行业共识，也是相对安全的位置。

存储环节我推荐Keychain而不是NSUserDefaults。NSUserDefaults是明文plist文件存储，越狱设备上可以直接读取；Keychain是iOS系统提供的安全存储机制，数据经过加密，而且可以设置访问权限。很多开发者觉得Keychain API太复杂，实际上封装起来也就几行代码的事。

刷新机制是Token设计里最容易忽略的一环。Token过期后不应该让用户重新登录，而是通过Refresh Token去换取新的Access Token。Refresh Token的权限范围更小、有效期更长，一般存放在更安全的位置。客户端收到401状态码时，自动用Refresh Token请求新Token，这个过程对用户完全透明。

吊销策略要配合服务端来做。当用户修改密码、退出登录或者账号异常时，服务端要把对应Token标记为失效。我见过一个项目因为没有做吊销，用户在网页端改了密码，iOS端继续用旧Token调用接口，整整一周时间各种投诉。后来在Token表中加了状态字段，所有涉及账号安全操作的接口都会强制清空旧Token，问题才算解决。

2.2 iOS端Token的获取与携带代码实现

以Objective-C为例，登录成功后，服务端返回的数据结构通常是这样的：

{ "code": 0, "data": { "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "refresh_token": "dGhpcyBpcyBhIHJlZnJlc2ggdG9rZW4...", "expires_in": 7200 } }

客户端拿到数据后，第一件事是计算过期时间。expires_in的单位是秒，需要加上当前时间戳存入本地：

- (void)saveToken:(NSDictionary *)tokenInfo { NSDictionary *data = tokenInfo[@"data"]; NSInteger expiresIn = [data[@"expires_in"] integerValue]; NSTimeInterval expireDate = [[NSDate date] timeIntervalSince1970] + expiresIn; NSMutableDictionary *tokenDict = [NSMutableDictionary dictionary]; tokenDict[@"access_token"] = data[@"access_token"]; tokenDict[@"refresh_token"] = data[@"refresh_token"]; tokenDict[@"expire_date"] = @(expireDate); [KeychainWrapper setDictionary:tokenDict forKey:@"user_token"]; }

注意：这里不要直接用服务端返回的expires_in作为判断依据，要以本地计算出的expire_date为准。因为网络延迟和用户手机时间偏差，直接用服务端数值容易出现误差。

发送请求时，需要统一在网络层拦截器中处理Token的自动携带。这块逻辑放在BaseNetwork类里，保证所有子类请求都能继承：

- (NSURLRequest *)addTokenToRequest:(NSURLRequest *)request { NSMutableURLRequest *mutableRequest = [request mutableCopy]; NSDictionary *tokenDict = [KeychainWrapper dictionaryForKey:@"user_token"]; NSString *accessToken = tokenDict[@"access_token"]; if (accessToken.length > 0) { [mutableRequest setValue:[NSString stringWithFormat:@"Bearer %@", accessToken] forHTTPHeaderField:@"Authorization"]; } return mutableRequest; }

对于401响应的处理，要走一个Token自动刷新流程。这里有一个并发请求需要特别注意：如果有多个请求同时收到401，不能每一个都去触发刷新，否则服务端会被刷爆。需要在网络层加一个信号量控制：

- (void)handleUnauthorized { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ // 请求刷新Token接口 [self refreshAccessTokenWithCompletion:^(BOOL success) { if (success) { // 重放原有的失败请求 } else { // 清除Token，跳转登录页 } dispatch_once(&onceToken, 0); }]; }); }

这里使用dispatch_once来控制刷新Token期间只允许一个刷新请求在执行，其他并发的401请求都等待第一个刷新完成后统一重放。如果每个401都刷新一次，服务端很快就拒绝请求了。

2.3 Token实战中容易踩的坑

Token这块的坑，我在项目里几乎都踩过一遍。第一个坑是Token过期时间的判定逻辑。我在一个项目里直接用expires_in当秒数倒计时，结果用户手机时间设置成了未来时间，请求发出去服务器一校验发现时间不对，返回401。后来统一改成服务端返回时间戳，客户端对比本地时间和服务器时间的时间差来校准，问题才解决。

第二个坑是App从后台恢复时的Token失效。用户可能几天不打开App，再打开时Token早就过期了。这种情况下不能等用户点了某个功能接口返回401才去刷新，需要在App启动或者从后台恢复时就异步刷新一次Token，让用户无感知地拿到新Token。

第三个坑是多设备登录管理。Token和设备的绑定关系要考虑清楚。如果不绑定设备，一个账号的Token在多个设备间流转，就会有安全隐患；如果绑定设备，用户换手机登录时服务端要能识别出来并给新设备签发新Token，同时让旧Token失效。我第一次做设备绑定时，忘记处理用户换机的情况，导致用户在新设备上登录成功，但旧设备的Token仍然有效，后来在Token信息里加了一个device_id字段，服务端校验时强制匹配，这个问题才算解决。

3. MD5在认证体系中的位置与实现

3.1 为什么还在用MD5

说句实在话，我不建议用MD5去存储用户密码。彩虹表攻击、碰撞攻击、加盐不当等问题都已经被研究得很透了。但在认证体系中，MD5依然有它的用武之地——参数签名。

场景是这样的：客户端要提交一个请求，包含用户ID、订单号、金额、时间戳等参数。这些数据在传输过程中有可能被中间人篡改，比如把你的订单金额从100改成10000。虽然HTTPS能防窃听，但业务参数完整性校验还是要做。做法是：客户端把所有参数按照字典序排序，拼接成一个字符串，再拼接上App端和服务端约定好的密钥（通常叫salt），对拼接结果做一次MD5，生成一个签名，放在请求的sign字段里。服务端收到请求后，用同样的规则重新计算签名，如果不同就拒绝服务。

这个方案的思路和HTTP报文里的校验和类似，核心价值是让攻击者不能随意篡改参数，因为攻击者不知道salt值，无法生成合法的MD5签名。

MD5的第二个用途是做防重放攻击。攻击者不需要篡改内容，直接把原请求原样复制再发一遍也可以造成问题，比如重复下单等。解决方案是加入时间戳参数，服务端只接受当前时间2分钟内的请求，超出时间范围的直接丢弃。MD5签名中带上时间戳后，攻击者复制旧请求也没用，因为时间戳已经过期了。

3.2 MD5签名的标准实现步骤

MD5签名的实现有一套约定俗成的流程，我直接贴代码：

+ (NSString *)md5SignWithParams:(NSDictionary *)params salt:(NSString *)salt { // 1. 取出所有key，按字典序排序 NSArray *keys = [params.allKeys sortedArrayUsingComparator:^NSComparisonResult(NSString *key1, NSString *key2) { return [key1 compare:key2]; }]; // 2. 拼接字符串 key1=value1&key2=value2 NSMutableString *contentString = [NSMutableString string]; for (NSString *key in keys) { NSString *value = params[key]; if ([value isKindOfClass:[NSNull class]] || value.length == 0) { continue; } [contentString appendFormat:@"%@=%@&", key, value]; } // 3. 拼接盐值 [contentString appendString:salt]; // 4. 计算MD5 return [self md5:contentString]; }

有几个细节在实现时要特别注意：

• 排序规则：一定要用字典序，且大小写排序规则要和服务端完全一致。我看过好几个项目的线上事故，原因就是iOS端和服务端对大小写的排序不一致，导致验签永远失败。
• 空值处理：空参数要跳过，不参与签名。这个规则很容易被忽略，但如果服务端规则里跳过了空值而客户端没有，就会出现签名不一致。
• 编码问题：拼接的字符串要统一使用UTF-8编码。中文参数的编码问题尤其容易出错，建议在拼接前做URL编码，避免特殊字符导致签名结果不一致。

服务端的校验逻辑也是一样的路数，由于服务端能拿到密钥，可以重新算一遍签名。如果客户端签名和服务端重新计算的签名不同，直接拒绝请求。整个过程不需要复杂的加密开销，性能上几乎可以忽略不计。

3.3 加盐规则与防逆向思维

MD5签名最大的弱点是密钥藏在客户端代码里。攻击者逆向App之后，可以找到这个salt，然后就能伪造签名。针对这一点，业界常用的手段有几种：

密钥分散存放。不要把salt以明文字符串形式写在一个常量里，可以把字符串拆成几段放在不同的类中，运行时再拼接。这个方法只能增加逆向成本，不能完全阻止攻击者。

动态获取盐值。App启动时，从服务端接口动态拉取salt，而不是硬编码在代码里。这样做的好处是，服务端可以定期更换salt，就算某个版本被逆向出旧的salt，也不会永远有效。我第一次做动态盐值方案时，遇到的问题是每次冷启动都要等待网络回来才能发请求，体验很差。后来改成策略：优先用本地缓存的旧salt启动，在新salt拉取成功后再切换。这样既保证了启动速度，也保证了安全性。

结合设备指纹。把设备唯一标识（IDFV）作为盐的一部分，让每个设备的签名都不一样。这个方案能有效防止攻击者用一台设备逆向出的盐去伪造其他设备的请求，但实现成本也相对较高。

这里有一个必须说清楚的认知：在客户端做任何安全措施，本质上都是在提高攻击者的成本，而不是让攻击无法进行。这个理念贯穿整个网络安全认证的设计过程。所以设计MD5签名时要明确它能防什么、不能防什么。它能防普通网络抓包者的参数篡改，但防不了专业逆向工程师对客户端代码的分析。

4. RSA加密与签名在iOS端的实现

4.1 RSA的基础认知与密钥对生成

RSA是非对称加密算法，有两个密钥：公钥和私钥。公钥可以公开、可以放在客户端；私钥只能服务器自己保存。用公钥加密的数据只能用私钥解密，反过来，用私钥签名的数据只能用公钥验签。这里有一个初学者常搞混的点：加密用公钥、解密用私钥；签名用私钥、验签用公钥。加密是为了机密性，防止别人看到内容；签名是为了防篡改和防抵赖，让对方确认数据确实来自你。

在iOS开发中，密钥对是PEM格式的base64字符串。服务器生成密钥对的命令是：

openssl genrsa -out private_key.pem 2048 openssl rsa -in private_key.pem -pubout -out public_key.pem

密钥长度选择2048位起步，992位的密钥已经被证明不够安全。密钥长度越长越安全，但加密速度越慢。在移动端场景中，2048位是当前最合适的折中方案，既能满足安全需求，又不会对性能造成太大影响。

在iOS端，公钥通常以.der格式的文件引入。PEM格式是base64编码的文本，DER格式是二进制，iOS的原生API要求使用DER格式。转换方法：

openssl rsa -in public_key.pem -outform DER -out public_key.der

生成.der文件后，拖入工程中，通过Bundle读取。我在这里踩过最大的坑就是格式问题。明明服务端给的是PEM格式的公钥，我直接塞给Security框架，结果报errSecParam参数错误。后来统一约定服务端给.der文件，或者客户端把PEM转换成DER，才好起来。

4.2 基于Security框架的RSA加密代码

先看加密的实现。iOS的Security框架提供了SecKey相关的API：

+ (SecKeyRef)publicKey { NSString *path = [[NSBundle mainBundle] pathForResource:@"public_key" ofType:@"der"]; NSData *keyData = [NSData dataWithContentsOfFile:path]; SecCertificateRef certificate = SecCertificateCreateWithData(kCFAllocatorDefault, (__bridge CFDataRef)keyData); SecPolicyRef policy = SecPolicyCreateBasicX509(); SecTrustRef trust; OSStatus status = SecTrustCreateWithCertificates(certificate, policy, &trust); if (status != errSecSuccess) { return NULL; } SecTrustResultType result; status = SecTrustEvaluate(trust, &result); return SecTrustCopyPublicKey(trust); }

拿到SecKeyRef之后，进行RSA加密。注意RSA加密对数据长度有限制，1024位的密钥只能加密117字节的数据，2048位的密钥只能加密245字节的数据。超过这个长度，就需要分段加密，或者改用混合加密方案。这里给出分段加密的实现：

+ (NSData *)rsaEncryptData:(NSData *)data publicKey:(SecKeyRef)publicKey { size_t blockSize = SecKeyGetBlockSize(publicKey) - 11; NSMutableData *encryptedData = [NSMutableData data]; NSUInteger dataLength = data.length; NSUInteger offset = 0; while (offset < dataLength) { NSUInteger currentBlockSize = MIN(blockSize, dataLength - offset); NSRange range = NSMakeRange(offset, currentBlockSize); NSData *subData = [data subdataWithRange:range]; uint8_t *encryptedBytes = malloc(blockSize + 11); size_t encryptedLength = blockSize + 11; OSStatus status = SecKeyEncrypt(publicKey, kSecPaddingPKCS1, subData.bytes, subData.length, encryptedBytes, &encryptedLength); if (status != errSecSuccess) { free(encryptedBytes); return nil; } [encryptedData appendBytes:encryptedBytes length:encryptedLength]; free(encryptedBytes); offset += currentBlockSize; } return encryptedData; }

SecKeyGetBlockSize(publicKey) - 11这个-11是PKCS1填充算法的预留空间。如果省略这个11，数据长度一旦超过限制，加密就会失败，且报错信息不明显。

RSA加密在实际业务中最典型的用途是传输密码。用户的登录密码不能明文发送，先用RSA公钥加密再传给服务器，服务器用私钥解密后校验：

NSString *password = @"user_password"; NSData *passwordData = [password dataUsingEncoding:NSUTF8StringEncoding]; NSData *encryptedData = [self rsaEncryptData:passwordData publicKey:self.publicKey]; NSString *base64Encrypted = [encryptedData base64EncodedStringWithOptions:0]; // 把base64Encrypted作为参数password传给服务端

4.3 RSA签名与验签的实现差异

RSA加密和RSA签名虽然都是基于同一个密钥对，但业务逻辑完全不同。加密是为了让别人看不到内容，签名是为了让别人无法冒充你。

服务端给客户端下发的关键数据包，通常需要做RSA签名。客户端验签的代码：

+ (BOOL)rsaSignatureVerify:(NSData *)signatureData originData:(NSData *)originData publicKey:(SecKeyRef)publicKey { OSStatus status = SecKeyVerifySignature(publicKey, kSecAlgorithmPKCS1SHA256, originData, signatureData, NULL); return (status == errSecSuccess); }

在iOS工程中，涉及RSA签名验签需要注意几个问题：

第一个是算法标识符的选择。Android和Java服务端默认用SHA256withRSA，iOS这边对应kSecAlgorithmPKCS1SHA256。跨端联调时，最容易出现的问题是算法不匹配导致验签失败。

第二个是数据格式的统一。客户端验签用的原始数据和生成签名时服务端的原始数据必须完全一致。比如服务端对“timestamp + userId + amount”这段字符串做了签名，客户端验签时也要对完全相同的拼接字符串做验签，多一个空格、多一个换行都会导致失败。

第三个是签名数据的编码。服务端生成的签名一般是base64字符串，客户端要把base64解码成NSData之后才能调用验签API，直接传字符串会失败。

4.4 非对称加密的性能问题和替代方案

RSA的加密性能远低于对称加密，这是它的硬伤。正是因为这个原因，实际项目中很少用RSA去加密大数据，而是用RSA+AES的混合加密方案。

混合加密的思路是：客户端随机生成一个AES对称密钥（key），用这个AES密钥去加密业务数据；然后用RSA公钥去加密这个AES密钥，把RSA加密后的AES密钥和AES密文一起传给服务端。服务端先用RSA私钥解出AES密钥，再用AES密钥解出业务数据。

这种方法的好处在于：AES加密速度快，适合加密大体积数据；RSA只加密一个小小的AES密钥，性能开销极小。实际项目中遇到的业务数据从几KB到几MB不等，如果全部用RSA分段加密，光加密耗时就可能超过用户可感知的范围。换成混合加密后，加密耗时基本可以忽略。

我把这个方案落地在一个聊天App的私聊消息传输中：每条消息先用AES加密，AES密钥保存在消息头里，用户设备之间通过RSA/ECDH做密钥协商。这样既保证了消息的机密性，也没有明显的性能损耗。

5. 三者的协同工作与完整认证流程

5.1 一套完整的请求认证流程设计

单独理解一种技术不难，难的是把它们组合成一个完整的认证体系。我在实际项目中沉淀了一套标准流程，分享出来供参考：

第一步，客户端启动。App启动时，从本地读取Token，如果Token不存在直接跳到登录页。

第二步，用户登录。用户输入账号密码后，客户端用内置的RSA公钥加密密码，连同时间戳一起POST到服务端。服务端解密密码、校验账号密码、校验时间戳防重放，全部通过后生成Token和Refresh Token，返回给客户端。

第三步，普通业务请求。客户端组装业务参数，计算MD5签名，把Token放在Header中，发出请求。服务端先验Token有效性，再验MD5签名，最后处理业务逻辑。

第四步，Token过期。用户Token过期后，服务端返回401。客户端捕获到401，用Refresh Token请求新Token。刷新成功后，重新发起原业务请求。如果Refresh Token也过期了，清空本地Token，强制用户重新登录。

第五步，关键敏感信息传输。涉及密码、支付信息、身份证等敏感数据时，走RSA+AES混合加密通道，而不是MD5签名。MD5只能防篡改，不能防泄露。

这个流程里的关键点是：Token负责“我是谁”，MD5负责“内容对不对”，RSA负责“内容不能给别人看到”。三者各司其职，缺一不可。如果一个接口只需要验证用户身份，Token就够了；如果一个接口只是同步一些非敏感数据，MD5签名就够了；如果一个接口涉及敏感数据，不仅要RSA加密，还要结合Token做身份验证。

5.2 令牌刷新与请求重放的时序细节

Token刷新是整个流程里最容易出bug的地方，主要涉及时序问题。我画一下当时的调优过程：

最初实现是每个请求独立处理401，Token过期后，同时发出十个业务请求，全部收到401，全部触发刷新Token的接口，导致服务端被刷新请求刷爆，而且刷新逻辑用的是同一个Refresh Token，在并发场景下无法保证幂等。

后来改成了队列模式。所有网络请求进入同一个队列，当第一个请求收到401后，暂停队列中所有后续请求，触发一次Token刷新，刷新完成后统一重放队列中所有请求。如果刷新失败，清空队列并把用户踢回登录页。

实现时有个容易忽略的细节：Refresh Token本身也有过期时间。如果刷新Token时Refresh Token也失效了，就不能再重放请求，必须强制重新登录。首次做这个逻辑时我没考虑这一点，用户密码修改后在旧设备上一直跳不出登录页，后来在刷新失败的分支里检查了错误码，专门处理Refresh Token过期的情况，才算收尾。

重放请求时也要注意：重放的是原始请求对象，而不是把业务方重新调用一遍。重新调用业务方代码可能会造成副作用，比如重复上报日志、重复写数据库。我在工程里保存了请求对象和回调Block，刷新Token后重新执行Block，同时去掉了原请求对象上的旧Token，更新为新Token。

5.3 不同接口场景下的安全级别划分

并不是所有接口都需要全套方案，一刀切反而会增加不必要的复杂度和性能损耗。我在项目中通常把接口分成三个安全级别：

这里的安全级别划分，本质上是访问控制策略的一部分。低安全级别的接口不需要MD5签名，因为数据本身不敏感，就算被篡改影响也不大。高安全级别的接口一定要做RSA加密，尤其要防止数据在传输和存储两个维度双双暴露。

我第一次实践这套分级方案时，把登录接口也放进了中等级别，结果安全性明显不够。密码可以被抓包工具直接看到（虽然是HTTPS加密传输，但如果HTTPS证书被信任或绕过再加上日志链路泄露，风险就来了）。后来增加了一层RSA加密，密码在HTTPS之上又多了一层保护，才算安心。

6. 常见问题与排查技巧实录

6.1 高发问题速查表

写实战项目的文章，光讲原理和技术音层没法让读者真正避坑。这块把我在项目中遇到的高频问题整理成一张排查表，每一条都是真实踩过的坑：

这里放到最前面的就是时间问题。Token校验如果服务端严格执行过期时间，本地时间会不会造成很大的误差吗？答案是会。iOS设备允许用户手动修改系统时间，如果用户把时间调后一小时，原本还有半小时有效的Token就只剩半小时了；如果调前半小时，失效Token还可能继续被接受。服务端负责校验的同事需要做的是：拿请求时间和服务端当前时间做比较时，允许一个合理的偏差窗口（比如5分钟）。同时客户端在登录成功时，从服务端响应头里拿服务器时间，计算并缓存一个时间偏移量，所有过期判断都用“本地时间+时间偏移量”来算。

6.2 抓包调试的正确姿势

一个不得不面对的现实是：iOS的ATS（App Transport Security）默认禁止HTTP明文请求。开发阶段如果服务端还没配好HTTPS证书，需要设置NSAppTransportSecurity的例外。这个设置在调试时可以这样写：

<key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict>

但注意，上线前一定要移除这个设置。一旦设置成NSAllowsArbitraryLoads=true，整个App的传输就都是明文了，之前做的所有加密方案形同虚设，因为攻击者可以轻易在网络层抓包获取全部内容。

调试网络安全的时候，Charles是抓包工具的常客。它的原理是中间人代理，客户端信任Charles的证书后，Charles就能解密HTTPS流量。这个能力在开发调试阶段非常有用，我经常用它来验证Token有没有正确放在Header里、签名参数算得对不对。但也要清醒认知：如果攻击者也能在你的设备上安装信任证书，理论上也能做到同样的事情。这就解释了为什么客户端安全方案里，md5的盐和RSA的私钥永远不能放在客户端。

还在调试过程中遇到过一个现象：Charles开启了SSL解密，iOS端却始终显示无法连接到服务器。排查后发现是证书信任问题。iOS端需要先安装Charles的证书到“证书信任设置”中开启完全信任，否则SSL握手就失败了。去设置里找到已安装描述文件，开启对Charcles证书的完全信任，问题才顺，这不属于代码问题，但不熟悉环境的开发者可能会在这里卡上半天。

6.3 逆向防护的实战经验

谈了这么多，很多人的下一个问题一定是：我做了MD5签名密钥、放RSA公钥在App里，攻击者逆向之后是不是全部都看得见？是的，全都能看见。这也是为什么我一直强调：客户端的代码安全从来都不是绝对安全，只有提高逆向成本一种选择。

我第一次做防御加固时，尝试了很多手段。代码混淆是基础，使用工具把类名、方法名、属性名都改成a、b、c这类无意义的标识符；字符串加密把盐值和密钥相关的字符串在运行时解密，而不是明文字节硬编码在MachO里。可以看到，所有操作都只是为了增加攻击者的时间成本。

但真正起作用的，是我后来加的一道校验：服务端风控。比如同一个账号短时间内频繁请求、请求的User-Agent异常、设备环境异常，服务端都能主动拦截。客户端的加固只是第一道防线，服务端的数据分析和异常检测是第二道防线，两道防线叠加后的威力和效果才是最实在的。

关于动态库还是静态库的问题，我提一句：如果集成了第三方统计SDK，要小心SDK中可能存在的动态库默认加载行为，它们会拖慢App启动速度。这不直接影响安全，但影响用户体验，用户不满意一样是安全模型的失败。

7. 性能细节与工程化建议

7.1 加密计算对App启动和流畅度的影响

RSA加密是CPU密集型的操作。我在一个项目中做过性能测试，2048位密钥的RSA公钥加密，单次耗时在2毫秒到10毫秒之间，根据设备性能差异波动很大。单看这个数字不吓人，但如果在主线程里同时做几十次RSA操作，App的卡顿会让用户明显感知到。

因此，所有涉及RSA加密的代码，都建议放到异步线程执行。iOS开发中要尽量让UI主线程保持流畅，因为任何超过16毫秒的主线程阻塞都会造成掉帧。在开发时我通常会做一层加密工具方法的封装，内部用dispatch_queue_create创建一个串行队列，外部调用时传入Block，加密完成后回调到主线程。这样既保证了线程安全，又避免了主线程卡顿。

MD5的计算速度远快于RSA，单次耗时几乎可以忽略不计。但当App一屏请求数量很多时，每个请求都做MD5，累积的效果还是要考虑。我给MD5签名也做了缓存策略：同一参数集合在短时间内不用重复计算签名，直接复用上一次的结果。当然，时间戳参数每次请求都会变，所以这个缓存策略只适用于时间戳参与签名但短时间内允许缓存的情况。整体来说，MD5签名加时间戳的校验对性能的影响微乎其微。

7.2 日志输出与敏感信息泄露

排查涉及安全的网络问题时，打日志是不可避免的，但也要格外小心。我在工程里见过很多人直接在请求日志里打印了完整的Token、密码甚至加密Key。如果这些日志在测试环境被上传到崩溃收集平台或者被日志工具捕获，那就等于把密钥给了别人。

建议在封装网络层日志时，对敏感字段做脱敏处理。写一个工具方法统一过滤：

- (NSString *)filterSensitiveInfo:(NSString *)logString { NSArray *sensitiveKeys = @[@"password", @"token", @"sign", @"secret"]; NSMutableString *result = [logString mutableCopy]; for (NSString *key in sensitiveKeys) { NSString *pattern = [NSString stringWithFormat:@"%@[=: ]+[\\w]+", key]; NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:pattern options:0 error:nil]; [regex replaceMatchesInString:result options:0 range:NSMakeRange(0, result.length) withTemplate:[NSString stringWithFormat:@"%@=***", key]]; } return result; }

日志脱敏这个动作在开发和测试阶段很容易被忽略，但一旦上线出问题，脱敏机制能直接降低一个级别的泄露损失。另外要说的是，不仅日志要脱敏，Bugly、友盟这类云上的错误上报，也会把用户信息打包上传。需要在初始化时配置过滤规则，避免敏感数据被默认上报到第三方云平台。

7.3 证书轮换与密钥管理的工程化

证书和密钥不是永久的，需要定期更换。大部分iOS App上线后，开发者会忘记RSA公钥什么时候过期，往往等用户反馈“登录失败”“支付失败”后才发现证书失效了。

更稳妥的做法是：在服务端开发一个密钥版本管理接口，客户端启动时向服务端查询当前密钥版本号。本地缓存的版本号和服务端返回不一致，就去拉取新公钥并替换本地旧的公钥。这个机制看起来多了一个网络请求，但换来的好处是：证书失效不用发App版本，服务端一键切换就能完成。

我实现这个功能时的数据结构是服务端返回JSON，包含version、public_key_base64、expire_time等字段。客户端对比version后决定是否更新本地公钥的缓存。更新公钥时要注意先写临时文件，再替换正式文件，避免写一半断电导致公钥数据损坏。

还要关注一点：不同服务（登录、支付、数据同步）建议使用不同的密钥对。如果所有服务共用一对密钥，其中一个服务私钥泄露了，所有数据都暴露。我曾在项目中给支付服务单独生成了一对密钥，这样即使业务接口的私钥被拿到，支付接口的加密依然是安全的，这个隔离设计值得推广。

8. 经验总结与后续扩展方向

8.1 我在项目中的使用体会

这套Token + MD5 + RSA的组合方案，我在目前的项目中已经稳定运行了接近两年，经历了几次安全事件考验。最大的体会是：安全方案的设计，功夫在代码之外。代码层面无非是加解密API、网络拦截器、Token存取这几个点，真正难的是安全意识和团队共识。

起初我把方案给团队成员讲的时候，有人觉得过度设计，有人觉得反正有HTTPS就足够了。等一次安全审计结果出来，指出客户端接口存在被重放攻击、密码明文的历史风险后，团队才真正重视起来。后来每次迭代都约定“新增接口必须明确安全级别”“敏感字段必须走加密通道”“联调前统一签名规则”，慢慢形成了项目内的一套防御规范。

我也越来越清晰地确认，单一的Token、MD5、RSA都不能解决所有问题。曾经收到过一个安全报告，指出某接口存在重放风险，原因是那个接口只验了Token没验MD5签名和时间戳。经过安全培训之后，团队开始思考的不再是“每个接口要套几个加密”，而是“这个接口最可能被谁攻击、从哪里攻击、需要防到什么程度”。这种面向场景的安全设计思维，比任何固定方案都管用。

8.2 未来可能的演进方向

这三者不是终点。随着业务发展和技术演进，目前有几条演进路径很值得探索：

第一是从RSA向椭圆曲线密码学（ECC）演进。ECC在相同安全强度下密钥更短、计算更快、带宽占用更小，越来越多的移动端方案在拥抱它。iOS系统对ECDSA、ECDH的支持也越来越完善。新一代移动App做密钥交换时，可能更倾向于采用基于证书签名、Ed25519等现代算法。

第二是全面拥抱标准的JWT（JSON Web Token）体系。JWT把用户信息和Token有效期集成在一个结构化的字符串里，天然支持信息签名和验证。如果现在从零开始设计认证体系，我更倾向于使用标准JWT方案，配合标准的Token刷新协议。文中手写的Token逻辑，更多适用于理解和自建系统的语义。

第三是引入自动化安全测试。把抓包验证、流量分析、签名校验这些动作沉淀成自动化的测试用例，每次发版本前跑一遍安全回归。传统的人工验证总是会漏，自动化能减少这种不确定性。

最后分享一个落地时的建议：如果项目是第一次做认证体系，不要追求一步到位。先把Token机制跑通，让用户能登录、能维持登录状态，第二步补上MD5签名防止参数篡改，第三步再对敏感接口做RSA加密。每一步都完成一轮完整的上线和验证，再进入下一步。如果一个项目从第一天就进入全副武装模式，开发排期会被拖得很长，反而僵硬。

这套方案只是一个合理的起点，不是银弹。真实的安全保障永远来自对威胁的持续认知和对方案的持续迭代。作为客户端开发者，我们要理解所有手段的目标本质上都是同一句话：在不可信的网络世界里，尽可能可靠地确认彼此的身份。